Author of the app here. This was quickly thrown together, and something we'd like to improve on next year. Any & all feedback is welcome.
We've already been looking at the results, and it has influenced the direction of multiple vendors in the process, but of course it isn't the only thing we look at.
We're going to continue to look at this throughout the process, so it's still worth getting a list together.
Whether we can release the raw results of this (and to what degree), will involve discussion between browser vendors, so it isn't something we can commit to right now. I know that's not… great… but it's a delicate process (one that I'm still personally getting used to - it's my first year 'on the inside').
Not an expert on how this will affect the results but since the list is so long, would it be better to show visitors two random-ish features at a time and have them pick the one they care more about? Or at least offer that kind of UI as an option or the default, and the current list for those who want more control.
I know this isn't quite what you mean, but when you first hit the page, the list is in a random order, but it's then stable across reloads.
I considered the 'vs' approach, but I worried that there might be a lot of iterations where one or two of the options would be things that the person didn't understand, or didn't care about.
How do you feel about something like this: The user goes through the long list, picking what they understand and don't dislike, then the 'vs' system is there for helping determine the order of those items. Then the user gets the ranking which they can tweak.
> I worried that there might be a lot of iterations where one or two of the options would be things that the person didn't understand, or didn't care about.
I won't disagree here, it would be tedious.
> picking what they understand and don't dislike, then the 'vs' system is there for helping determine the order of those items
Browsers don't want to add new ways of running script. That said, I wonder if `<?xml-stylesheet type="text/javascript" href="script.js"?>` could work. It's kinda weird, but `xml-stylesheet` can already run script via XSLT, so it isn't a new way to run script.
Alpha channel support in x265 is very interesting, as this was only previously possible with paid-for Apple software (and the resulting file sizes were high). Some details from when I last looked at it https://jakearchibald.com/2024/video-with-transparency/#enco...
`position-anchor` is a high-level simple way of doing it, and it comes with the restrictions you mention. However, the `anchor()` function, which is also mentioned in the article, gives you the kind of flexibility you want.
I guess you're being downvoted as a general nay-sayer, but you're right. I tried this feature last month and a bunch of browser bugs and design issues got in the way. I reported them, and they're being worked on https://github.com/w3c/csswg-drafts/issues/12466
The `margin:0` issue was particularly frustrating & imo should have been covered in the article, as it's a real gotcha when trying to use popover & anchor positioning in combination.
Yeah I could have mentioned the actual issues I had.
My first attempt was to anchor an element to another one that occurred later in the document order, and it didn’t work. The anchor must be placed before any of its dependents. It kind of makes sense, but doesn’t jump out as intuitive.
