W3C home > Mailing lists > Public > www-style@w3.org > April 2016

Re: [css3-break] fragment selectors

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 19 Apr 2016 16:02:09 -0700
Message-ID: <CAAWBYDBhUSdfqPaxKrZuVz5izGVR797_ioEdntJxk2K8-bZK-w@mail.gmail.com>
To: Lea Verou <lea@verou.me>
Cc: Florian Rivoal <florian@rivoal.net>, Matt Haggard <haggardii@gmail.com>, www-style list <www-style@w3.org>
On Tue, Apr 19, 2016 at 12:07 PM, Lea Verou <lea@verou.me> wrote:
> 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.

Well, it works "fine".  It's not great - we do iterative layout until
the contents of the line stabilizes.

This isn't *terrible* because it's only the first line - the maximum
pain is relatively small in practice, and only triggers at the start
of a block.  Avoiding larger amounts of pain is one of the reasons
we've avoided speccing an ::nth-line pseudo, despite its usefulness
for, say, striping source-code backgrounds.

The idea presented in this thread would, unfortunately, cause large
amounts of pain.

> I don't understand why we can't have a ::nth-fragment(an+b) pseudo-element, which would either work like ::first-line, or just wouldn't affect layout. i.e. no matter what styling you applied on it, it would not affect fragmentation. If you weren't careful, it would just overflow the page. In practically all cases that would be a non-issue, because the styling one needs to apply to fragments does not actually affect fragmentation.

Something highly limited in power might work, but we'd have to be very
careful/lucky to make it still capable of solving enough use-cases to
be worth speccing and implementing.  These sorts of "hard corner-cases
with recognizable but small benefit" are great examples where Houdini
can help, tho - JS layout can just screw with the fragment tree and
apply whatever limits it wants on the feature.

Received on Tuesday, 19 April 2016 23:02:56 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:58 UTC