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

Re: [css-snappoints][css-scroll-snap] Does scroll-snap-align applies to pseudo-elements?

From: Florian Rivoal <florian@rivoal.net>
Date: Tue, 26 Jan 2016 11:08:32 +0900
Cc: CSS public list <www-style@w3.org>
Message-Id: <C65090CE-632C-4606-93A9-80F358A15510@rivoal.net>
To: "Tab Atkins Jr." <jackalmage@gmail.com>

> On Jan 26, 2016, at 04:20, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> On Sun, Jan 24, 2016 at 4:59 AM, Florian Rivoal <florian@rivoal.net> wrote:
>> The spec(s) do not explicitly allow scroll-snap-align and related properties on pseudo-elements, but I see no particular difficulty in allowing them, and it seems useful.
>> 
>> I think they should at least work on the generated content ::before and ::after pseudos,
> 
> Yes, ::before/::after automatically work with all properties unless
> explicitly specified otherwise.  (Pseudo should make this clearer.)

css-pseudo does indeed say it ("can be styled exactly like any normal document-sourced element in the document tree"), however, various specs have made the explicit claim that their properties do apply to ::before and ::after (see for example: https://drafts.csswg.org/css-transitions/#propdef-transition-property).

When some specs say it applies and others don't, it's not far fetched for the reader to assume that when the spec doesn't say, then it doesn't apply, so we should be consistent to avoid confusion.

I'd err on the side of being explicit everywhere ("All elements including generated content pseudo elements"), but as long as we're consistent, I'm probably OK.

>> but I'd also be in favor of making it apply to all pseudo elements. As long as something has a box, we should have all we need to make things work.
> 
> Yeah, but it has to be tree-abiding, or else it's unpredictable *how
> many* snap-points it generates.  This rules out ::first-letter and
> ::first-line, as well as all the highlight pseudos like
> ::spelling-error.  This is the same reasoning that rules out
> background-image and friends - it's unpredictable how many boxes the
> pseudo-element will generate, as it depends intimately on the markup
> it's applying to, and so we avoid any property that depends on or
> visually exposes the number of boxes.

I'm not sure I follow. While these pseudos do weird things to the tree
(making it no longer a tree), how do they create more than one box? Or do
you mean the boxes generated by their children? Why would that matter
for a snappoint?

Also we do apply background image to non tree-abiding pseudos:
http://jsbin.com/nowose/edit?html,css,output

I mean, yes, the non tree abiding pseudos are weird in general, and
there's all sorts of issues with them, but could you clarify a bit
what causes problems with regards to snap-points?

 - Florian
Received on Tuesday, 26 January 2016 02:09:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:34 UTC