Skip to content

[css-display] Does run-in algorithm run multiple times for each run-in sequence? #1460

Closed

Description

@Loirooriol

Suppose I have this code

<span style="display: run-in">Foo</span>
<div>
  <p>Bar</p>
</div>

Then Run-In Layout says

If a run-in sequence is immediately followed by a block box that does not establish a new block formatting context, it is inserted as direct children of the block box

So the example above becomes

<div>
  <span style="display: run-in">Foo</span>
  <p>Bar</p>
</div>

But now the run-in sequence is still immediately followed by a block box that does not establish a new block formatting context.

Does the algorithm run again in order to obtain the following?

<div>
  <p><span style="display: run-in">Foo</span> Bar</p>
</div>

It think it should. But then, how to prevent the following quote from generating an infinite number of boxes?

Otherwise, an anonymous block box is generated around the run-in sequence and all immediately following inline-level content

<div>
  <p>
    <anonymous-block><span style="display: run-in">Foo</span> Bar</anonymous-block>
  </p>
</div>
<div>
  <p>
    <anonymous-block>
      <anonymous-block><span style="display: run-in">Foo</span> Bar</anonymous-block>
    </anonymous-block>
  </p>
</div>

And so on.

Activity

  1. added a commit that references this issue on Jul 6, 2017
  2. fantasai commented on Jul 11, 2017

    @fantasai
    Collaborator

    Yes, the run-in algo's first step needs to recurse. Fixed, thanks!

  3. sandstrom commented on Sep 12, 2017

    @sandstrom

    Sorry if this is the wrong place to ask, but I'm wondering why run-in is marked as at risk?

    It saddened me that run-in was removed from Chrome earlier.

    It's very useful for writing semantic html (headings/paragraphs) while being able to style the heading to be part of the subsequent block. It is also useful in single-page apps where 'widgets' are composed of custom-elements/web-components, and the element should be separate in the html source, but presented as a run-in visually.

    I really hope it can be re-introduced as part of css-display-3. The alternative to achieve similar styling is brittle and error prone (usually position:relative + top offset values).


    Please let me know if there is another place that's better for comments like this.

  4. Loirooriol commented on Sep 12, 2017

    @Loirooriol
    ContributorAuthor

    @sandstrom Probably you should ask in a new issue. As far as I know, run-in as defined in CSS 2.1 was a fiasco which Firefox never implemented and other browsers decided to remove because of its buggy and problematic behavior. So it isn't surprising for web browsers to be reticent about implementing the new run-in definition. And see https://bugzilla.mozilla.org/show_bug.cgi?id=2056#c88

  5. sandstrom commented on Sep 12, 2017

    @sandstrom

    thanks @Loirooriol for answering! 😄

    Basically I just wanted to voice my support for run-in and offer some use-cases.

    Do you think a comment in the bugzilla tracker with my use-cases would be helpful?

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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions