[Keithamus]

While it hasn't been expressly resolved by the HTML working group to not propose new attributes with dashes, and while I don't speak for everyone in the HTML working group, I would assert that many members would object to a proposed attribute that included a dash (including myself).

There is also a proposal in the works to allow web developers to define custom attributes - much like custom elements - which would likely follow the same or similar rules around dashes, at which point I imagine the HTML spec would guarantee that no dashes would be used in "built in" attributes.

New attributes have been proposed that reasonably _could_ have had a dash, for example `popovertargetaction`, but instead they were compounded to one word precisely to cave out this path.

[lioeters]

Very interesting to know, thank you.

There are template languages that extend the HTML syntax but render to valid HTML, and I imagine this kind of guarantee of future naming scheme is important to ensure the extended syntax does not have the potential to conflict with new attributes added to the HTML specs.

> proposal in the works to allow web developers to define custom attributes

Looks like this is it:

Proposal: Custom attributes for all elements, enhancements for more complex use cases

https://github.com/WICG/webcomponents/issues/1029

Searching for "dash" does bring up a thread of discussion around whether to require dashes or not.

---

I wonder if starting the custom attribute with a dash is allowed or not. Searching around, I see colon ":" and underscore "_" are OK, but dash "-" or period "." is only allowed after the first character.

> Any namespace-less attribute that is relevant to the element's functioning, as determined by the element's author, may be specified on an autonomous custom element, so long as the attribute name is XML-compatible and contains no ASCII upper alphas.

https://html.spec.whatwg.org/multipage/custom-elements.html#...

XML-compatible attribute name:

  NameStartChar ::= ":" | [A-Z] | "_" | [a-z] | [#xC0-#xD6] | [#xD8-#xF6] | [#xF8-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF]
  NameChar ::= NameStartChar | "-" | "." | [0-9] | #xB7 | [#x0300-#x036F] | [#x203F-#x2040]
  Name ::= NameStartChar (NameChar)*

https://www.w3.org/TR/xml/#NT-NameStartChar

[lioeters]

Oh I didn't realize I was speaking to the author of the article! I enjoyed it very much, it was thought-provoking, educational, and made me wonder about new ways of integrating HTML and CSS beyond classes.

One aspect of Tailwind that I'm not satisfied with is editor integration, in particular linting, hints, autocomplete. There are editor extensions for this, but it feels too cramped working inside the `class` value, a single space-separated string.

Custom elements and attributes could enable a better editing experience, for example autocomplete suggestions can be specific to attribute name; or if the attribute is known to have a color as value, the editor can provide a color picker to fill in the value.

[Keithamus]

Thank you for providing the detail I was scant on.