Re: [csswg-drafts] [css-shadow-parts] What's the purpose of multiple idents in ::part()? (#4412)

> The current model is the moral equivalent of using divs for markup and differentiating them purely by classes. It works (and many people do it), but it breaks the semantic model of HTML and has second-order costs.

Can you explain a little more why you think the tagname is valuable?

In HTML, tagname is worth something because there's a lot of other stuff, DOM and interactivity and a11y and semantics, that keys off of it automatically, and it would be confusing/impossible to apply multiple sets of those things (something can't be both a textarea and a video). Classes have none of that and are purely for author extensibility.

In parts, both "class-like" names and a "tagname-like" name are exactly identical in behavior: they're author-defined and meant for author-level extensibility, with zero UA-defined difference. The only inherent difference is that an element would have 0-Infinity "class-like" names, and exactly 1 "tagname-like" name.

What's the significant difference between an ident denoted as "class-like" and an ident denoted as "tagname-like" that justifies adding more syntax and concepts to the model, versus just sticking with a single concept and leaning on convention when necessary?

If it's purely a (custom to the page) semantic distinction, note that I've had several occasions in my webdev life when I've wanted to give an element multiple IDs, so I could address it differently in different contexts. The fact that DOM happens to impose a "0 or 1" semantic on IDs is a relic of the model; there's nothing semantically wrong with having multiple of them. As a result, I've moved something from being an ID to being a class just so I can give it multiple "names".

In other words, I think the "exactly 1" or even "0 or 1" name restriction ends up at best neutral and at worst harmful to usability, when it's not backed by actual behavior requiring such a distinction.

GitHub Notification of comment by tabatkins
Please view or discuss this issue at using your GitHub account

Received on Monday, 14 October 2019 22:58:23 UTC