CSS for replaced-content pseudo elements

[jakearchibald]

Our pseudo elements ::page-transition-incoming-image(tag) and ::page-transition-outgoing-image(tag) are replaced content. But should that be represented somehow in the CSS we generate for the transition?

Option 1 - a function

::page-transition-outgoing-image(foo) {
  content: page-transition-outgoing-image(foo);
}

::page-transition-incoming-image(foo) {
  content: element(some-link-back-to-the-element);
}

page-transition-outgoing-image(foo) - this references the captured texture from the no-longer-existing element. Developers could take this function and use it on other elements, which raises questions around the lifetime of the image. Eg, does it become an invalid/empty image once the transition is complete?

element(some-link-back-to-the-element) - in this case we have something kinda like element() but not quite. We'd need to extend the API somehow so it behaves less like element() and more like we need it to for the page transition API (eg, not capturing the whole texture in some cases). This feels like a lot of work for little benefit.

Option 1.5 - as above, but without extending element()

::page-transition-incoming-image(foo) {
  content: page-transition-incoming-image(foo);
}

page-transition-incoming-image(foo) works similarly to page-transition-outgoing-image(foo) - it's specific to page transitions, and the link between foo and the actual texture is handled behind the scenes.

Option 2 - a magic value

::page-transition-outgoing-image(foo) {
  content: page-transition-image;
}

::page-transition-incoming-image(foo) {
  content: page-transition-image;
}

Here page-transition-image refers to the image associated with the pseudo element. Only the page transition system can set and unset this association. It's a little magic, but it explains how the element becomes replaced content, and doesn't have lifetime concerns.

Option 3 - full magic

How the pseudo element becomes a replaced element is not defined in the CSS at all. This makes it similar in spirit to an <img>, which is also a replaced element without CSS defining the replacement.

With this option, we might be able to move to one of the other options later.

[vmpstr]

As an implementor, I like option 3 here. In other words, I'd prefer not to deal with either populating the content style or responding to changes if developer decides to change content from even the magic page-transition-image to something else.

It's unclear whether there are good use-cases for this, but exposing this will definitely introduce edge cases that we need to support

[jakearchibald]

Yeah, my preferences are options 2 & 3. Option 3 lets us switch to something else later which kinda wins the tie-break.

[khushalsagar]

I'd be okay with option 2 if we can say the UA stylesheet adds "!important" so it's clear developers can not override this property. If we go with option 3 then a content value for these transition pseudo elements would simply be ignored?

But overall it sounds like we're all in agreement that we want to spec the snapshot mechanism (live and cached) independently for SET as opposed to a independent web feature that SET builds on top of. @chrishtr @tabatkins, do you see any concerns with this?

[chrishtr]

I don't have any particular concerns as long as the behavior is clearly specified in terms of CSS box concepts that are not hard for all browsers to follow. At first glance, option 2 seems easier than option 3 in the sense that it wouldn't require specifying that content is ignored, and also allows a name for the thing that will be interoperably specified.

If we do select a name, we should choose one that is as general as possible while matching the desired semantics precisely. This allows the name to be reused elsewhere in the future.

[jakearchibald]

@khushalsagar

I'd be okay with option 2 if we can say the UA stylesheet adds "!important" so it's clear developers can not override this property

I'd rather go for option 3 in that case. It seems to only make sense if it can be overridden.

@chrishtr

If we do select a name, we should choose one that is as general as possible while matching the desired semantics precisely. This allows the name to be reused elsewhere in the future.

Huh, my gut feeling was to do the opposite.

The outgoing texture is associated to the element in some page-transition-specific way, and given an identifier using the page-transition-tag, and has a lifecycle dictated by the page transition. It feels like the name should be specific to page transitions.

I guess a middle ground is something like custom properties where there value can only be set by the UA. I was proposing something similar in #117 but I don't think folks were interested.

[khushalsagar]

We discussed this today and the conclusion was that going with option 3 sounds reasonable for now. As long as the implementation for these snapshots (live and cached) is well defined using existing CSS concepts.

Not defining the syntax would also leave the door open to thinking through what it should look like if the functionality is exposed as an independent feature going forward.

Based on the comments, everyone is in agreement for option 3 so I'm closing the issue. Please re-open if not.