Skip to content

[css-view-transitions-1] Should block-in-inline splitting prevent view-transition-name from being used #12217

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
mattwoodrow opened this issue May 21, 2025 · 10 comments
Open

[css-view-transitions-1] Should block-in-inline splitting prevent view-transition-name from being used #12217

mattwoodrow opened this issue May 21, 2025 · 10 comments
Labels
css-view-transitions-1 View Transitions; Bugs only

Comments

@mattwoodrow
Copy link
Contributor

The current wording says that elements that have more than one box fragment should be skipped from capturing, with the explicit exclusion of inlines being split across line boxes.

Should block-in-inline be skipped too? There's also the bidi reordering, and column-spanner-in-block cases.

The linked css-break-4 spec (linked to from css-view-transitions-1) describes all of these as creating multiple fragments - https://drafts.csswg.org/css-break-4/#box-fragment. Looks like this was the resolution that settled on that being the case - #1477 (comment).
@mattwoodrow mattwoodrow added the css-view-transitions-1 View Transitions; Bugs only label May 21, 2025
@nt1m
Copy link
Member

nt1m commented May 21, 2025

cc @noamr @vmpstr

@mattwoodrow mattwoodrow mentioned this issue May 27, 2025
Open
@mattwoodrow
Copy link
Contributor Author

@emilio might be interested in this too.

@noamr
Copy link
Collaborator

noamr commented May 29, 2025

Seems like #1477 is still open?
IAC, I am OK with adding more constraints to animating this type of element.

@emilio
Copy link
Collaborator

emilio commented May 29, 2025

Yeah I think ignoring IB-splits makes sense, it's unclear what fragment / bounding boxes to use here. I think the Gecko implementation also ignores them.

@bfgeek
Copy link

bfgeek commented May 29, 2025

Should block-in-inline be skipped too? There's also the bidi reordering, and column-spanner-in-block cases.

A block-in-inline doesn't have more than one fragment so it shouldn't be skipped right?

IMO this would be pretty bad to skip all block-in-inlines from a web-dev point of view as things like:

<my-component>
  <div></div>
</my-component>

Creates a block-in-inline by default.

The current wording is only when a box itself produces more than one fragment, e.g. if it spans a column break.

@emilio
Copy link
Collaborator

emilio commented May 29, 2025

Sorry should've clarified, so when you have <my-component><div/></my-component>, <my-component> generates two anonymous block fragments around (before and after) the <div>. In that case, I think <my-component> should be skipped. I think that's what @mattwoodrow was proposing, but maybe he can confirm? You're right that the block itself probably shouldn't be skipped tho.

@mattwoodrow
Copy link
Contributor Author

Sorry should've clarified, so when you have <my-component><div/></my-component>, <my-component> generates two anonymous block fragments around (before and after) the <div>. In that case, I think <my-component> should be skipped. I think that's what @mattwoodrow was proposing, but maybe he can confirm? You're right that the block itself probably shouldn't be skipped tho.

Yes indeed, it's the inline that gets multiple fragments and should be skipped (I believe).

Seems like #1477 is still open?

Open pending edits, but the WG resolution is in the there :)

@bfgeek
Copy link

bfgeek commented May 29, 2025

So a few things:

From: https://drafts.csswg.org/css-view-transitions-1/#capture-old-state-algorithm

Note: box fragment here does not refer to fragmentation of inline boxes across line boxes. Such inlines can participate in a transition.

If an inline gets fragmented it can still participate in a view-transition.

Sorry should've clarified, so when you have

, generates two anonymous block fragments around (before and after) the
. In that case, I think should be skipped. I think that's what @mattwoodrow was proposing, but maybe he can confirm? You're right that the block itself probably shouldn't be skipped tho.

This isn't what the resolution for 1477 was however:

RESOLVED: In a block-in-inline split, the block is inside the inline in the box tree, and is a sibling of the two fragments of the inline in the fragment tree

So the inline gets fragmented, but it doesn't say anything about if anonymous blocks are inserted. Anonymous blocks are an implementation detail. Blink doesn't insert the anonymous blocks as you've described. We follow the box-tree structure in 1477. And the block-box is a sibling on the two inline fragments per that resolution.

I'm hesitant to resolve on this as it seems to come from:
https://bugs.webkit.org/show_bug.cgi?id=290923
Which seems like a valid usecase, and there isn't any fundamental reason not to support it.

(Also note there are bugs with block-in-inlines in WebKit like: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=13823 )

<!DOCTYPE html>
<span style="opacity: 0;"><div style="background: red">hi</div></span>

@mozilla-apprentice mozilla-apprentice mentioned this issue May 29, 2025
Closed
@mattwoodrow
Copy link
Contributor Author

Note: box fragment here does not refer to fragmentation of inline boxes across line boxes. Such inlines can participate in a transition.

If an inline gets fragmented it can still participate in a view-transition.

This is what I'm seeking to clarify here. The above wording seems to be quite specific to the fragmentation of an inline across the line box, and any other cases are covered by:

If the element’s principal box is fragmented, skipped, or not rendered, this property has no effect.

Where the link for 'fragmented' specifically lists block-inside-inline.

If the intent is to allow this case, then I think the spec should be more clear as to what types of fragments are included/excluded.

As Emilio said, it's not super obvious what the bounding boxes to use would be, so it'd be nice to have some thorough tests of this so we can try to avoid more browser-specific bugs relating to IB splits.

@bfgeek
Copy link

bfgeek commented May 30, 2025

If the element’s principal box is fragmented, skipped, or not rendered, this property has no effect.

Where the link for 'fragmented' specifically lists block-inside-inline.

Two points:

  • Above refers to the "principle box", e.g. the (potential) anonymous boxes that a UA may insert aren't the "principle box".
  • The note in the "fragment" definition referring to inline-splitting is looks incorrect based on my undersanding.

As Emilio said, it's not super obvious what the bounding boxes to use would be, so it'd be nice to have some thorough tests of this so we can try to avoid more browser-specific bugs relating to IB splits.

Thats somewhat orthogonal however (and maybe requires clarification!). E.g. the geometry of the inline is no different if it has a block-in-inline present or not; and the block-in-inline should be painted by the inline.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
css-view-transitions-1 View Transitions; Bugs only
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@noamr @bfgeek @emilio @mattwoodrow @nt1m