-
Notifications
You must be signed in to change notification settings - Fork 672
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
[css-break] Is an inline-block monolithic or may-be? #1111
Comments
I'm pretty sure this is just clumsy 2119 usage. It should be |
This patch implements the initial support for atomic inlines in LayoutNGInline. Atomic inlines are the first type of objects in LayoutNGInline that needs be laid out to compute in-flow inline size. NGLineBuilder now keeps NGLayoutResult for atomic inlines while it builds a line box. Some tests turned from false-passes to real-failures. Because atomic inlines were not rendered before this patch, tests using images and inline-blocks passed by comparing blank result with blank reference. Some work are not included in this patch and will follow, such as: * Keep NGBlockNode for atomic inlines in NGLayoutInlineItem. * Use NGLayoutResult not only for layout but also for fragment generation. * Margin, padding, borders. * BreakToken if we support breaking atomic inlines[1]. * ...and obviously more. [1] w3c/csswg-drafts#1111 BUG=636993 Review-Url: https://codereview.chromium.org/2745973002 Cr-Commit-Position: refs/heads/master@{#457673}
I think we made this a MAY case so that an implementation could fragment an inline block, if it wanted to--didn't want to forbid it, since that can be a better result than what the spec requirs. The alternatives are to clip the line box it's in or to graphically slice said line box and all its contents. |
I added some text to clarify this case. @kojiishi can you let me know whether the intention is clear enough now? |
…xes as fragmentable or monolithic. #1111
Looks great, thank you. |
Recently I happened to be in a discussion whether the 4.1. Possible Break Points section in CSS Fragmentation Module defines an inline-block must be monolithic or may be monolithic. I could read both ways, clarification is appreciated.
There are two paragraphs that may be read differently.
First it says:
IIUC this paragraph doesn't define inline-block yet since inline-block is not text content, but I could read it differently, considering inline-block is abstracted as an object replacement character.
Then it says:
The last part clearly defines inline-block may be monolithic. However, this paragraph also says "line boxes contain no possible break points", I could read this as "inline-block appearing in a line box must not be broken." An inline-block cannot live outside of a line box, so this paragraph maybe self contradicting depends on how you read.
@fantasai could you help to clarify?
Note, from our brief testing, in case this helps:
The text was updated successfully, but these errors were encountered: