Re: [css3-break] fragment selectors

> On 19Apr, 2016, at 21:35, Florian Rivoal <florian@rivoal.net> wrote:
> 
> 
> On Apr 20, 2016, at 04:07, Lea Verou <lea@verou.me> wrote:
>>> This is inherent to the way pseudo classes work, so we cannot have a pseudo class which matches or not depending on the result of layout.
>> 
>> Yes we can, and we do: ::first-line.
>> I can almost imagine the CSS WG discussion about cycles if ::first-line was proposed now, yet it's implemented everywhere and works just fine.
> 
> First, as Tab pointed out, while we have ::first-line, it is a mess of difficult interop issues that we have yet to sort out. I am confident we eventually will, but we're not there yet and it is far from an easy one.

Interop issues on edge cases most authors do not run into. If you ask the average CSS author what they think of ::first-line, I guarantee you, interop issues will not be on their list of things to say. I'm not trying to trivialize interop, but let's not lose sight of the bigger picture.

> Can we solve the use case with ::nth-fragment then? Actually I don't think so, because to do so, we'd need to select the first and the last fragments, to style the first top border and the last bottom border differently from the other borders. Selecting the first fragment is doable, but selecting the last one isn't, for a variant of the same reason as above: the properties applied by a ::last-fragment (or ::nth-last-fragment) cannot change whether there is a last fragment, but they can change which fragment is the last, which is just as bad. Just try to think of what font-size:50em or border-top-width:80vh or width:5px etc would mean if applied through such a pseudo element. You've just hit an infinite loop again.

I assumed we'd get the entire suite of nth stuff, including ::nth-last-fragment.

And like I suggested, styling on ::nth-*-fragment() would not affect fragmentation, which alleviates all of these concerns.

> Alright. I think of it as a clever hack rather than a terrible one, but I'll agree it's a hack, and that in fragmented media it is a decently common use case, so we may want to solve it in a non hacky way.

My point was that it's a hack. Most terrible hacks are also clever :)

> A (set of) properties that could let you change the appearance (but not the size, otherwise we're looping again) of the border-before-a-break and of the border-after-a-break might just work.

Whitelisting properties is recipe for disaster. We've seen it fail in tons of cases, for no real reason, just developers and spec authors forgetting to include new properties (e.g. look at the allowed styles for :visited, which don't even include box-shadow). I really hope we don't go down that path.

~Lea

Received on Wednesday, 20 April 2016 03:13:24 UTC