im not sure how you counted that as 145, but here's 137 for the css

<style>p{--n:counter(n);counter-increment:n;&:before{content:var(--n)};&:nth-child(5n){--n:"";&:after{content:"Buzz"}}&:nth-child(3n){--n:"Fizz"</style><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p>

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

it's not all solved because some applications require framing (eg google docs), and you can run this attack against a non-frame target, such a website with html injection, but strict CSP

not as much as you would think, the if statements don't really affect the css crimes scene because pretty much everything was already possible before

But then why was it added?

Because it's silly to rely on hard to read hacks when you could just add an if() function.

Yup. It's the same reason nested CSS was added. It doesn't really add any new functionality. Just makes your CSS neater (or way messier when misused). it's syntactic sugar really

I don't think clickjacking is overrated, it's usually the opposite with it being not even accepted by many bug bounty programs.

I've been able to make realistic attacks against multiple targets. Many services, such as Google Docs, need to enable cross-origin framing for their functionality.

And beyond that, even if you restrict the framing, it might still be possible to clickjack as a part of a more complex attack chain, see: https://lyra.horse/blog/2024/09/using-youtube-to-steal-your-...

And the attack in OP does not require iframes, so it can also be applied to injection attacks where CSP prevents javascript for example.

(disclaimer: author of story)

I hope im not coming off dismissive, this really is cool research.

> it's usually the opposite with it being not even accepted by many bug bounty programs.

As someone who has been on the other end of bug bounty's, its because clickjacking reports are a massive spam magnet. 99% of reported are not really vulns (e.g. no xfo header on a static website with no user auth, is not a vuln), and its just not worth sorting through.

> I've been able to make realistic attacks against multiple targets. Many services, such as Google Docs, need to enable cross-origin framing for their functionality.

The google docs thing is really cool. However i think services that need authenticated frames are few and far between. Now that cookies on frames tend to be opt in, i think the number of vulnerable services is going to go way down. Its not going to be 0, but its going to be pretty limited.

I don't think invalid spam reports mean something is overrated. Spam reports are spam reports. That'd be like saying buffer overflows are overrated because there are a bunch of AI-generated invalid spam reports with them.

A valid report needs to demonstrate a realistic attack scenario, and I think that's the approach bug bounties should take.

I think a good example is Google with its stance on open redirects[0]. They won't accept a report just pointing one out, but they will accept one that "can demonstrate that its impact goes beyond phishing".

[0] https://bughunters.google.com/learn/invalid-reports/web-plat...

I agree in the ideal scenario. However i think lots of bug bounties are understaffed and sometimes people make the pragmatic choice.

> Many services, such as Google Docs, need to enable cross-origin framing for their functionality.

What specifically does Google Docs do that requires it?

> And the attack in OP does not require iframes

How do you frame the victim site without iframes?

> What specifically does Google Docs do that requires it?

Google wants documents to be embeddable on external sites.

> How do you frame the victim site without iframes?

You don't, you use it in a different scenario. For example if you have HTML injection, but its fairly limited due to strict CSP.

As a user: Browsers let you manually disable JS, but you can also use an extension such as NoScript (I do).

As a web developer: You can use Content Security Policy to limit or disable JS, as well as other resources such as CSS and images.

on android and browser i get that behavior, on ios it just says "something went wrong" after the email confirm part

Same on iOS, with the fun bonus of the "something went wrong" modal looping as well! (Without retrying, you're just stuck in modal hell)

Which part are you referring to? What browser/version are you using?

Could you point out ARIA APG patterns the blogpost and its examples are not hitting due to no JS?

I'm good. Try Claude research.

I do care about accessibility, so seeing comments implying I'm doing something wrong without telling me what's wrong just kind of sucks.

Which ones? What browser/version are you running?

Safari

What version? I tested my blogpost on Safari and added stuff specifically to accommodate it - the only known broken thing is the color picker, and I mention it in the post.