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

Open
kojiishi opened this Issue Mar 16, 2017 · 4 comments

Comments

Projects
None yet
3 participants
@kojiishi
Contributor

kojiishi commented Mar 16, 2017

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 changed the title from [css-break] Is an inline-block monolithic or not? to [css-break] Is an inline-block monolithic or may-be? Mar 16, 2017

@tabatkins

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Mar 17, 2017

Member

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

Member

tabatkins commented Mar 17, 2017

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

[LayoutNG] Implement atomic inlines for LayoutNGInline
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

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Mar 20, 2017

Contributor

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.

Contributor

fantasai commented Mar 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Aug 20, 2018

Contributor

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

Contributor

fantasai commented Aug 20, 2018

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

@kojiishi

This comment has been minimized.

Show comment
Hide comment
@kojiishi

kojiishi Sep 12, 2018

Contributor

Looks great, thank you.

Contributor

kojiishi commented Sep 12, 2018

Looks great, thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment