Re: [css3-break] fragment selectors

> On Apr 20, 2016, at 12:13, Lea Verou <lea@verou.me> wrote:
> 
> 
>> 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.

Interop issues with first line are not hit all that often because first line isn't used all that often. This is a problem I want to solve, but it's going to take a while to sort out in the more general case than ::first-line.

But even when we do, I don't see how it lets us solve this use case.

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

How do you make this not affect fragmentation?

If you just treat each fragment as unbreakable independent boxes, whose content doesn't flow from one to the other, then you're going to have overflow / undefiled problems all the time as soon as you try and use them, making them mostly unusable.

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

I wasn't whitelisting properties here. I was introducing new properties that affect the appearance of the border next to a break. I may or may not be a good idea, but I don't understand how your comment relates to my suggestion.

As for white-listing/blacklisting in general, on pseudo classes it is a hack to deal with security problems, and admittedly it is a fragile hack. On pseudo elements however, it is no different from saying saying what kind of things a property applies to in its "Applies to" line in the prop def table.

 - Florian

Received on Wednesday, 20 April 2016 03:32:51 UTC