[css-break] Is an inline-block monolithic or may-be? · Issue #1111 · w3c/csswg-drafts · GitHub
Skip to content
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

Closed
kojiishi opened this issue Mar 16, 2017 · 4 comments
Closed

[css-break] Is an inline-block monolithic or may-be? #1111

kojiishi opened this issue Mar 16, 2017 · 4 comments
Assignees
Labels
Closed Accepted as Editorial Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. css-break-3 Current Work

Comments

@kojiishi
Copy link
Contributor

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:

Some content is not fragmentable, for example ... or a single line of text content. Such content is considered monolithic

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:

Since line boxes contain no possible break points, inline-block and inline-table boxes (and other inline-level display types that establish a new formatting context) may also be considered monolithic.

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:

  • Gecko does not break an inline-block.
  • Edge/Trident can break an inline-block, normally between line boxes in the inline-block.
  • WebKit/Blink can break an inline-block at arbitrary points.
@kojiishi kojiishi added the css-break-3 Current Work label Mar 16, 2017
@kojiishi kojiishi changed the title [css-break] Is an inline-block monolithic or not? [css-break] Is an inline-block monolithic or may-be? Mar 16, 2017
@tabatkins
Copy link
Member

I'm pretty sure this is just clumsy 2119 usage. It should be s/may also be/are/.

MXEBot pushed a commit to mirror/chromium that referenced this issue Mar 18, 2017
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}
@fantasai
Copy link
Collaborator

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.

@fantasai
Copy link
Collaborator

I added some text to clarify this case. @kojiishi can you let me know whether the intention is clear enough now?

@kojiishi
Copy link
Contributor Author

Looks great, thank you.

@fantasai fantasai added Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. and removed Commenter Response Pending labels Sep 19, 2018
@fantasai fantasai closed this as completed Oct 4, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Closed Accepted as Editorial Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. css-break-3 Current Work
Projects
None yet
Development

No branches or pull requests

3 participants