Skip to content

[css-display] Can run-in be inserted as child of block which establishes an inline formatting context? #1228

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
Loirooriol opened this issue Apr 16, 2017 · 7 comments

Comments

@Loirooriol
Copy link
Contributor

Loirooriol commented Apr 16, 2017

CSS Display defines Run-In Layout as

A run-in box behaves exactly as an inline-level box, except:

  • If a run-in sequence is immediately followed by a block box that does not establish a new formatting context, it is inserted as direct children of the block box [...]
  • Otherwise, an anonymous block box is generated around the run-in sequence and all immediately following inline-level content (up to, but not including, the next run-in sequence, if any).
  • A run-in box with a flow inner display type inlinifies its contents.

The following example is provided:

<dl class='dict'>
  <dt>dictionary
  <dd>a book that lists the words of a language in alphabetical
      order and gives their meaning, or that gives the equivalent
      words in a different language.
  <dt>glossary
  <dd>an alphabetical list of terms or words found in or relating
      to a specific subject, text, or dialect, with explanations; a
      brief dictionary.
</dl>
.dict > dt {
  display: run-in;
}
.dict > dt::after {
  content: ": "
}

Which is formatted as:

dictionary: a book that lists the words of a language
in alphabetical order and explains their meaning.

glossary: an alphabetical list of terms or words found
in or relating to a specific subject, text, or dialect,
with explanations; a brief dictionary.

However, the dd establishes an inline formatting context according to CSS 2.1:

A block container box either contains only block-level boxes or establishes an inline formatting context and thus contains only inline-level boxes.

So I think that either the example is wrong and the dt should not be inserted inside the dd, or that the definition should allow a run-in sequence to be inserted as direct children of a block box which establishes an inline formatting context.

@Loirooriol Loirooriol changed the title [css-display] In example 3, the run-in is inserted as child despite inline formatting context. [css-display] Can run-in be inserted as child of block which establishes an inline formatting context? Apr 16, 2017
@fantasai fantasai added the css-display-3 Current Work label Apr 18, 2017
@fantasai
Copy link
Collaborator

The latter is clearly the only reasonable interpretation. :) This is going to require some tricky wording fixes, though. :/

@Loirooriol
Copy link
Contributor Author

What about adding the word "block"?

If a run-in sequence is immediately followed by a block box that does not establish a new block formatting context [...]

@fantasai
Copy link
Collaborator

There's also flex and grid formatting contexts... so really we need to exclude inline. :)

@fantasai
Copy link
Collaborator

But there's related wording that probably also needs fixup, so we need to audit all of it.

@Loirooriol
Copy link
Contributor Author

As far as I know the only formatting contexts that can be established by a block box are block and inline ones, so flex and grid ones are already excluded.

@fantasai
Copy link
Collaborator

Oh, yeah. :) That would definitely work then.

Loirooriol pushed a commit to Loirooriol/csswg-drafts that referenced this issue Apr 20, 2017
If a block box establishes a new formatting context, it can either be a block or an inline one. Run-in sequences should be allowed to be inserted into the block box in the latter case. Fixes w3c#1228
@fantasai
Copy link
Collaborator

All fixed, thank you!

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

No branches or pull requests

2 participants