Keithamus

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.

I will get around to fixing this. An oversight. Apologies.

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.

Thank you for providing the detail I was scant on.

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.

React 19 is likely to ship with Web Components support. https://github.com/facebook/react/issues/11347

Thanks for the feedback! If you have the time, I'd love for you to contribute and improve the marketing copy: https://github.com/WebComponentsGuide/webcomponents.guide

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)

There's hope for React yet: https://github.com/facebook/react/issues/11347

Was a poor attempt at a joke that perhaps didn’t carry :p

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).

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”.

Just to update everyone: the domain has been renewed and is being transferred over to my account (as the current lead maintainer). We’ll use some funds to ensure it stays active for a long time and this won’t happen again.

Failed expectations always throw an AssertionError, and they always have a stack. It might be the test runner you have which is breaking or hiding the stack?

Sorry to hear that Andrew. If you'd like to point me to issues or PRs where you've contributed and don't feel like you had a good response, I'd be happy to follow up on them.

Hi, I'm the current lead maintainer of Chai.

We don't own the domain name, the previous maintainer/author does. It seems to have lapsed. There's not much I can do about that other than attempt to contact the previous maintainer, which I've done.

Deno uses uint8array (pretty much Nodes Buffers (Node Buffers subclass UInt8Array these days)) for almost all methods. For example Deno comes with `Deno.readFile` which returns a Promise<UInt8Array>, but they include the special case Deno.readTextFile because of how common it is to convert the contents to a string.