It’s unfortunate that this name was used. There is a W3C community group called OpenUI (https://open-ui.org/) which has been around for close to a decade, working on improving UI standards for the web.
Right. The average score is under different test conditions. Obviously this game is a little silly version with very little accuracy to the lab testing, but hopefully it gets people thinking about this stuff a bit more! Which given your investigations into this, I would say it has succeeded.
JND is an average. A lot of people will do a lot worse. The measure, as I understand it, is also under different test conditions, while this is a game where people are on their own and able to - for example - tilt their head trying to find the exact angle to see the difference.
It’s not executing JS. The names map to JS methods but both the HTML and JS call into C++ (or rust or swift whatever the browser is written in). Arbitrary JS code execution cannot occur. Of course if you’re ingesting user generated content you should not allow these attributes on buttons (but for proper security you should already have an allow-list of tags and attributes on any user generated content).
Author here. I am not affiliated with Google. My current employer is GitHub, and this was incubated in the OpenUI working group. Open source & the open Web are still very much alive!
BroadcastChannel is a better solution for a couple of reasons. Service Workers are better at intercepting network requests and returning items from a cache, there’s some amount of additional effort to do work outside of that. The other thing is they’re a little more difficult to set up. A broadcast channel can be handled in a couple lines of code, easily debuggable as they run on the main thread, and they’re more suited to the purpose.
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.
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.
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)
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.
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).