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.
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
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.
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.
They key difference is that an attribute can only appear once on an element, and consequently only have one of its variants present. Classes can present multiple variants at once.
At a surface level `<div class="Card" data-size="big">` isn't really any better `<div class="Card big">`. But `<div class="Card" data-size="big" data-size="small">` is not valid HTML - the second attribute is discarded. While `<div class="Card big small">` has no such contract, and as such is valid HTML and the CSS is unlikely to account for it, perhaps doing surprising things.
This is what BEM solves. You do not have class="Card big" but class="Card Card_big". And if you care about modifier conflicts you may always define a rule .Card_big.Card_small { /* whatever makes sense */ } and not rely on a random application of attributes.
I’ve been working on https://webcomponents.guide/ with some fellow experts in order to improve the documentation side of things. Hoping to offer guidelines and best practices to limit the amount of searching and experimentation required. Please take a look and provide feedback if you can!
That’s what CSS parts and slots are for. Your component can style its own boundaries, provide parts to allow customisation, and use slots to inject components that are styled from outside (be it another ShadowDOM or the light DOM)
Yep, though what I’m getting at is that those slots/parts better give you near-infinite flexibility. Because if you encounter a scenario where the slots don’t provide what you need, then you’re screwed.
Source: I fought with Ionic code for months over this. Really soured me on native encapsulation, but I see the benefits still. I just think it has to be approved very very very carefully.
When someone from the Chrome team actually had to write the code for them. I don’t think the React team themselves cares about interoperability at all however.
I don’t recall saying old technology is bad. I was more trying to say it served its purpose at the time but as websites have gotten more complex we’re still relying on this one single primitive.
It’s true that as systems scale often templating systems are introduced to alleviate writing html, but these systems are rarely complete which means developers - meeds unmet - need to “drop down a layer” and in that should be set up for success not failure. Having a design system that use brittle underlying primitives will not set developers up for success.
Great article. Shouldn't have been flagged; I think a few folks pride was hurt.
However, there's a foot-gun in the first paragraph. In the mid-nineties practically no one was using "black and white" monitors. I remember a few ancient DOS test-only stations at a school and a single amber-monochrome hardware terminal (connected to big-iron at work) in that time period. Everything else doing real work was Win3.1 and color Mac by then. Netscape browser had already dropped and was popular; no one was using it in black and white.
This was in California. May be slightly ahead, and I'm not taking developing countries into account. But color was so compelling it was already not-uncommon by the late 80s.
For large applications with many thousands of pages, or many thousands of engineers working on the same system, name collisions happen. It’s not just throwing “random css” into the mix, it’s that many disjointed parts of the same application suddenly become connected and interdependent. Especially with “parameter names” like “size”. You really have three choices to solve this: invent elaborate tooling to catch overuse; prepend your classes in the hope that lowers conflicts; or over specify selectors and deal with the specificity issues that fall out from this.
Custom elements are very well supported today! I’d encourage you to spend more time with them!
I felt the “considered harmful” style of titles have been overused that no one would reasonably consider it anything but click bait; and so used it as ironic-click-bait.
Naming collisions are a pretty real problem when you get to building large systems. They’re a big enough problem for something like CSS Modules to exist (explained further down in the post).
I considered exploring it but css selector performance just doesn’t matter with todays engines. There are far greater issues, and far better performance wins than “optimising your selectors”.
Makes sense, I would just worry that if I built my whole stack around this, suddenly I hit a breakdown point where I have a ton of attribute selectors and now adding new DOM elements to a content view takes a millisecond.
I'm more wary about this than I used to be since someone managed to accidentally cause tsc to need multiple seconds to compile a single file by making a small change to a type definition. Big O still can bite you!
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.