Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Let’s start off with a simple example - detecting if a pixel is pure black, and using it to turn another filter on or off.

I'm so lost, or at least, struggling. Why is modern HTML/CSS like this?

So there's apparently a hidden <checkbox>, and then a <label> "for" the checkbox that contains no text, but takes up space due to CSS properties. And also apparently clicking on the label toggles the checkbox because, it just works that way by default? And then the CSS properties can vary depending on the checkbox state, without JavaScript, because that's just built into CSS for some reason? And then in the second box, it's using another label for the same checkbox, so it shares that state.

Then the actual SVG... just defines filters, and doesn't actually draw anything. But the various demos get to pull filter definitions out of the SVG?

And two separate <feTile> tags define a filter in conjunction, one describing the region to take as a tile and the second describing where to tile it? Whereas all the other filters are just transforms on a common region? Why is it like that (as opposed to, say, having separate source and destination coordinates in the attributes for a single <feTile> tag)?

And what even are these <fake-frame> and <art-frame> elements?





> I'm so lost, or at least, struggling. Why is modern HTML/CSS like this?

I think it's pretty neat. It allows me to build cool interactive stuff such as the post in question without having to use JavaScript.

> And also apparently clicking on the label toggles the checkbox because, it just works that way by default?

Yes, that's how semantic HTML forms work.

> And then the CSS properties can vary depending on the checkbox state, without JavaScript, because that's just built into CSS for some reason?

Yes, it makes sense to be able to style an unchecked checkbox differently from a checked one. And I'm just using CSS's `:has()` to check for the state: html:has(#foo:checked) label[for=foo] { ... }

> And two separate <feTile> tags define a filter in conjunction, one describing the region to take as a tile and the second describing where to tile it?

<feTile> is a single element filter just like all the other ones. It just tiles the current image to the desired size. If the input is bigger than the output, it functions as a crop instead. So I use two of them to achieve a crop + tile.

> And what even are these <fake-frame> and <art-frame> elements?

They're autonomous custom elements, you can just make them up instead of using div-soup.

I touched on it in this post: https://lyra.horse/blog/2025/08/you-dont-need-js/


> <feTile> is a single element filter just like all the other ones. It just tiles the current image to the desired size. If the input is bigger than the output, it functions as a crop instead. So I use two of them to achieve a crop + tile.

Aha.

> I touched on it in this post: https://lyra.horse/blog/2025/08/you-dont-need-js/

I coincidentally was given that link elsewhere since posting and have been reading it and clarified much of the rest as well. Amazing work on the blog overall.


> I'm so lost, or at least, struggling. Why is modern HTML/CSS like this?

Most of the things you mention are not "modern"

> And also apparently clicking on the label toggles the checkbox because, it just works that way by default?

This goes back to the 90s. Clicking on a form widget label causes the widget to be focused.

I believe the original rationale is that is how desktop UIs do it. Also for checkboxes and radio buttons the hitbox would otherwise be quite small.

> And then the CSS properties can vary depending on the checkbox state, without JavaScript, because that's just built into CSS for some reason?

Well yes, if you want to customize the way checkboxes look you need to apply different styles depending on their state. Support for this literally goes back to version 1 of firefox.

> But the various demos get to pull filter definitions out of the SVG?

That's kind of a natural consequence of being able to embed SVG namespace elements directly in html. CSS supports it via the filter property, but i think even before that property existed you could probably do it via direct embedding svg in html or vice versa.

Anyways, my point is this isn't a situation of, what has modern html wrought. Most of this is very old features. I bet you probably could have done the same attack a decade ago.


> Well yes, if you want to customize the way checkboxes look you need to apply different styles depending on their state. Support for this literally goes back to version 1 of firefox.

It doesn't surprise me that this is possible for the checkbox, but it does surprise me that the label responds to the corresponding checkbox's state. (I take it that the styling is being applied to the labels, simply so that multiple labels can share state by all being "for" the same hidden checkbox.)

> That's kind of a natural consequence of being able to embed SVG namespace elements directly in html. CSS supports it via the filter property, but i think even before that property existed you could probably do it via direct embedding svg in html or vice versa.

I've only ever used SVG for... scalable vector graphics. I don't understand why CSS needs access. I get that SVG uses tags so that individual elements of the drawing can be in the DOM and then e.g. get animated by JavaScript. But I would have expected that to require JavaScript.


I think CSS just wanted to be able to apply filters (blur() is a very common use case). Since a filtering language already existed for svgs, and web browsers had already implemented it, it made sense to connect the two. SVGs can also be styled via css, so there needed to be a syntax to mark in document filters as applying to specific svg elements.

I dont really think css filter is neccesary here though. I suspect the exploit could be implemented without that part just by embedding svg on the page.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: