Skip to content

Clarification on block box with mixed level boxes #8772

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.

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

Closed
TKDev7 opened this issue Apr 26, 2023 · 9 comments
Closed

Clarification on block box with mixed level boxes #8772

TKDev7 opened this issue Apr 26, 2023 · 9 comments
Labels
Closed as Question Answered Used when the issue is more of a question than a problem, and it's been answered.

Comments

@TKDev7
Copy link
Contributor

TKDev7 commented Apr 26, 2023

Given a markup like this:

<body>
  Some
  <div>Text</div>
</body>

Now since block containers can only have block-level or inline-level boxes, I assume the box tree would look like this:

block box
  anonymous block box
     anonymous inline box
  block box

Is my assumption correct?

@bfgeek
Copy link

bfgeek commented Apr 26, 2023

It depends. There are a few different ways of implementing this.

Blink previously did what you describe but now we do:

block box
  line box
    Some
  line box
    anonymous block box
      Text

(there are other approaches as well).

The reason for this is you may have DOM structure like:

<!DOCTYPE html>
<div>
Text <span style="filter:blur(2px)">text
  <div>
    block
  </div>
</span>
</div>

https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=11591

Making sure the filter applies to the block-in-inline is non-trivial with the first approach.

Ian

@TKDev7
Copy link
Contributor Author

TKDev7 commented Apr 27, 2023

@bfgeek do you think the specs should be changed to reflect this? I believe that what you just described doesn't sound spec-conformant to me.

@bfgeek
Copy link

bfgeek commented Apr 27, 2023

Yeah that section of the css2 spec is bad/over-perscriptive - and lacks experience of these things in practice (esp. that paint affects on inline elements, and how positioning works, etc). Likely that section should have a warning surrounding it.

We've found that the approach described above is significantly simpler, and all the side-effects are exactly the same is the first approach.

Ian

@TKDev7
Copy link
Contributor Author

TKDev7 commented Apr 27, 2023

I wonder if Gecko and WebKit do the same as well.

@bfgeek
Copy link

bfgeek commented Apr 27, 2023

Blink's old code was exactly the same as WebKit. Gecko also does the first apporach. EdgeHTML I believe had a similar approach to what we do now.

@TKDev7
Copy link
Contributor Author

TKDev7 commented Apr 28, 2023

So it seems only Blink is non spec compliant. I am not sure if this is an issue or are browsers allowed to implement this however they want.

@Loirooriol
Copy link
Contributor

Browsers can do whatever they want as long as the result looks like the specified behavior.

@TKDev7
Copy link
Contributor Author

TKDev7 commented Apr 28, 2023

@Loirooriol So I believe I got my answer, which is yes my assumption is indeed correct. Should I close this or leave it open because of Blink’s behavior?

@Loirooriol
Copy link
Contributor

I guess this can be closed as question answered. To be more explicit, yes, your description in the 1st comment matches https://www.w3.org/TR/CSS22/visuren.html#anonymous-block-level and https://drafts.csswg.org/css-display-3/#block-container

But once we have a CSS Flow spec, I guess it can be reconsidered whether to follow CSS2 or something like Blink.

@Loirooriol Loirooriol added the Closed as Question Answered Used when the issue is more of a question than a problem, and it's been answered. label Apr 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Closed as Question Answered Used when the issue is more of a question than a problem, and it's been answered.
Projects
None yet
Development

No branches or pull requests

3 participants