3 ms·

Link to the CSS Values 5 specification, where it describes how HTML attribute names can be referenced in CSS properties. 6.4. Attribute References: the attr()

Link to the CSS Values 5 specification, where it describes how HTML attribute names can be referenced in CSS properties. 6.4. Attribute References: the attr() function https://drafts.csswg.org/css-values-5/ https://drafts.csswg.org/css-values-5/ With the ability to specify attribute types, including dimension units, and to provide a default value - it does look like a new way to connect HTML to CSS beyond the limitations of classes. --- > The data- prefix can be a little unwieldy but it allows for the widest compatibility with tools and frameworks. Using attributes without some kind of namespace can be a little dangerous, as you risk clobbering HTML's global attributes, but as long as your attribute name has a dash it should be quite safe. I wonder if this last part is true. For custom elements, since they're required to have a dash, I imagine future HTML tags are guaranteed to not contain a dash. But for attributes.. Are all future HTML global attributes guaranteed to not include a dash? Maybe the author means, as long as your custom attribute has a name with unique prefix, it should be "quite safe".

Keithamus 2y ago
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 2y ago
  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 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#custom-elements-core-concepts 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 https://www.w3.org/TR/xml/#NT-NameStartChar
  - lioeters 2y ago
    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 2y ago
    Thank you for providing the detail I was scant on.

Keithamus 2y ago

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 2y ago
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 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#custom-elements-core-concepts 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 https://www.w3.org/TR/xml/#NT-NameStartChar
- lioeters 2y ago
  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 2y ago
  Thank you for providing the detail I was scant on.