2056 - display: run-in not implemented

Status: RESOLVED WONTFIX

(Core :: Layout: Block and Inline, defect, P3)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I can't tell if part of this is related to bug 1345...

Style isn't applied properly to run-in headings -- see the bold in the first
example in the above URL.

Furthermore, I think (but I'm not sure) that anonymous block boxes count, so
run-in headings can run in like the second in the above URL.

And where did the third example go?  Floated off to infinity???

Comment 1

[kipp]

we probably won't support run-in for our first release, since run-in is a css2
feature and all we are promising is css1. However, I'll leave on the bug list
and just lower its priority and severity.

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The problem is, you already do support it.  Except there are three big problems
(at least).  First, when a header is run-in, it gets the style of the paragraph
of which it becomes part, rather than using its own style.  Second, run-in
headers don't run-in to anonymous boxes.  Third, separation of the header and
the block box by a float should prevent run-in.

Either you should fix the bugs or remove the support... this is a bug, so I'm
setting the priority/severity back where they were.

Comment 3

[leger]

Setting all current Open/Normal to M4.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

display: run-in has now completely stopped working.  I was hoping you would support it. - It's a very useful feature, because it allows logical structures to be used (DLs), and then displayed as wanted.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

display: run-in has now completely stopped working.  I was hoping you would support it. - It's a very useful feature, because it allows logical structures to be used (DLs), and then displayed as wanted.

Comment 6

[Paul MacQuiddy]

per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Comment 7

[kipp]

The bug is now later'd again; I've stripped any layout consequences of "run-in"
- they are now treated just like "block".

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

There are other fans of this feature:

http://www.webreference.com/html/gecko/7.html

Comment 9

[Hixie (not reading bugmail)]

FWIW, when this feature *is* implemented, here is a test page:
   http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/display-runin.html

Comment 10

[Hixie (not reading bugmail)]

FWIW, when this feature *is* implemented, here is a test page:
   http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/display-runin.html

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

What's happenning is that run-in is being treated as block.

For final release, this should not happen.  Rather than treat it as block, you
should ignore it.  This means that the style system should treat it as an
invalid keyword, so

p {
  display: block;
  display: run-in;
  }

will yield block display

and

span {
  display: inline;
  display: run-in;
  }

will yield inline display.

I'm tempted to reopen the bug on the basis that you should do one or the other
(support or completely ignore).  You really need to do this for any properties
where you have implemented only some of the values.

Comment 12

[Hixie (not reading bugmail)]

This last issue is now covered by bug 15432. I am marking that bug dependent on
this one, but technically it is an either|or situation.

Comment 13

[Hixie (not reading bugmail)]

Migrating from {css2} to css2 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...

Comment 14

[Hixie (not reading bugmail)]

Reopening and moving to Future...

Comment 15

[Andrew Thompson]

add self to cc

Comment 16

[Kevin McCluskey (gone)]

Build reassigning Buster's bugs to Marc.

Comment 17

[Madhur Bhatia]

any progress with this bug?

Comment 18

[rubydoo123]

just ran Ian's evil test case and we still fail on this issue

reduced priority to P4

Comment 19

[Boris Zbarsky [:bzbarsky]]

.

Comment 20

[raulitosena]

..

Comment 21

[Max Kanat-Alexander]

I can get either URL (Ian's [comment 9] or dbaron's [the original]) up -- I get
404s. Is there a valid testcase? Especially one that could be attached to the bug?

-M

Comment 22

[Hixie (not reading bugmail)]

The URI in comment 9 still works for me.

Comment 23

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

http://dbaron.org/css/test/sec090204 is the current version of the original URL.

Comment 24

[Myles Catchpole]

Useful link to have on this page

http://www.w3.org/TR/REC-CSS2/visuren.html#run-in

gives the test case I used to realize this was a bug before I found this site.

Sorry if I formatted this incorrectly, first time posting in bugzilla.

Comment 25

[Sebastian Redl]

I want this fixed, and I'm ready to do it myself. Can anyone give me hints as to
how I would implement this?

Comment 26

[José Jeria]

*** Bug 280039 has been marked as a duplicate of this bug. ***

Comment 27

[daneel]

This is implemented already in KHTML and Presto. C'mon! Don't make me feed Gecko 
same styles as IE!

Comment 28

[Anne (:annevk)]

Please don't add useless advocacy comments to bugs. Raise your opinions in the
forums.

Comment 29

[Mildred Ki'Lya]

Attachment: test

source: http://www.quirksmode.org/css/display.html

Comment 30

[Anne (:annevk)]

*** Bug 291016 has been marked as a duplicate of this bug. ***

Comment 31

[David Latapie]

Attachment: A more eloquent reason to support run-in

I attached an XHTML example showing how display run-in with a definition list is a semantic (and sometimes also coding) improvement on usual punctuation-separated lists. The example provided is the January 2006 timeline from Wikipedia.

Opera is required to see it accurately; Webkit will not display the generated content.

Comment 32

[David Latapie]

(In reply to comment #31)
> Opera is required to see it accurately; Webkit will not display the generated
> content.
Actually, Safari 2.0.4 doesn’t render it accurately but Omniweb 5.5’s version of Webkit does.

Comment 33

[David Latapie]

Attachment: A more eloquent incentive for support run-in support (update)

Updated version, with styled ul for ease of comparison. I spared you the various <span style="font-weight:bold"> around every date in the ul version.

Comment 34

[Daniel.S]

I've seen that currently some brainstorming is going on, people think about what to work on for the next few months.

I'd like to mention display: run-in, which seems to be a nice feature. Currently Opera and Safari have implemented run-in boxes, and from what the first beta looks like, IE8 will implement this feature as well.

This is a CSS 2.1 item, but seems horribly underspecified (the definition doesn't look much different to CSS2.0). How else can Opera, Safari and IE8b1 completely disagree in certain cases?

I think this feature is important, because it's a CSS 2.1 item and working on it should improve the feature specification so run-in can be implemented interoperable. By the way, wasn't the refloe branch intended to make the implementation of features like this easier as well?

Comment 35

[Zack Weinberg (:zwol)]

this is either going to be easy or intractable...

Comment 36

[gabe]

this works in ie8 it seems

Comment 37

[Daniel.S]

Attachment: run-in as implemented in Opera and IE8 (per current spec)

Comment 38

[Boris Zbarsky [:bzbarsky]]

Doing this for the static case should not be too bad, I think.  At least using frame construction item lists.  The dynamic situation is a lot more complicated.  I'm not sure how well IE8 and Opera handle it.  On the static cases they're mostly compatible (with the obvious exception of run-ins containing inline-block or inline-table kids).  Webkit's implementation is pretty much completely broken; it doesn't make run-ins that don't run in into blocks.

I might try to write up the static case in the next several days.  I'll have to make some assumptions, since the spec is (as usual) pretty vague.  See http://lists.w3.org/Archives/Public/www-style/2009Jul/0025.html for the comments I just sent in.

Comment 39

[Boris Zbarsky [:bzbarsky]]

Found a few more vaguenesses in the spec; depending on how those are resolved it might be easier or harder to do this in frame construction instead of reflow...

I admit my gut instinct is that this should all be handled in frame construction; DOM mutations around run-ins will be slower, but that should be rare anyway.  But maybe I'm just seeing frame construction everywhere I look. ;)

I do think handling this during reflow would be a lot more complex than just setting up the frame tree so things Just Work.

Comment 40

[Boris Zbarsky [:bzbarsky]]

Attachment: Some notes to self in code form

Non-code note to self: in addition to the tests I included in my www-style post, need tests at least for:

1) replaced elements with display:run-in
2) dynamic mutations
3) "overflow: scroll" on run-ins
4) sizing of run-ins (replaces and not)
5) float and positioned kids of a run-in (esp when the following block
   has a left margin, in the case of float).  This depends on a spec
   clarification.

Comment 41

[Boris Zbarsky [:bzbarsky]]

6) Line-breaking on a run-in that has run in (including effect on border, etc).
7) Behavior where rtl stuff is concerned (on both the run-in and the block it
   runs into).

Comment 42

[Boris Zbarsky [:bzbarsky]]

Some notes on handling dynamic changes (all of these also need tests).  In all cases when talking about siblings I mean frame siblings, not content siblings.

REMOVALS:
1) Removing a block that a run-in has run into should should either run the
   run-in into a different block or make it into a block.  (Need both cases
   tested in various variants).
2) Removing a node whose following sibling (skipping ignorable whitespace) is a
   block without a run-in running into it and whose previous sibling (skipping
   ignorable whitespace) is a run-in with no block kids should run the run-in
   into the block.
3) Removing the only block child (whatever that means; test various variants)
   of a run-in that is followed by a block should run the run-in into the block.
4) Removing a run-in that has run into a block whose previous sibling (skipping
   ignorable whitespace) is a run-in with no block kids should run that
   previous sibling run-in into the block.

INSERTS:
1) Inserting a run-in before a block (skipping ignorable whitespace) should run
   the run-in into the block unless the run-in has a block child or the block
   already has a run-in _and_ that run-in's content node comes after the new
   run-in's content node.  Test all the cases here, including the new run-in
   running in and an old one running out if needed.
2) Inserting a frame that is not ignorable whitespace such that its next
   sibling (skipping ignorable whitespace) is a block that a run-in has run
   into should possibly make the run-in into a separate block.  Whether it does
   should depend on whether the new frame would come between the resulting
   block and the existing block or not.
3) Inserting a block after a run-in (skipping ignorable whitespace) should run
   the run-in into the block unless the run-in has a block child.
4) Inserting a block descendant of a run-in that has only inline ancestors
   between itself and the run-in should make the run-in run out it if had run
   in before.

RESTYLES: These are all represented in terms of removes/inserts already, but worth testing display changes on:
1) run-ins (to and from that display type)
2) blocks following run-ins (to and from that display type)
3) kids of run-ins (to and from being blocks).

Any other obvious things to test?

Someone want to write the several dozen reftests we need here?  ;)

Comment 43

[Boris Zbarsky [:bzbarsky]]

roc, it would be really nice if all the "skipping ignorable whitespace" stuff in those comments didn't have to be there.  It's especially a pain when inserting a block, since we have to walk backwards across whitespace to check whether we have a block run-in there already.  Which would block on having those prevsibling pointers in frames, if we have to do it...  At the same time, if the previous run-in is a block and if our whitespace optimizations were exact we wouldn't have whitespace there to start with.  Is that more work than making prevsibling happen, do you think?

Comment 44

[Boris Zbarsky [:bzbarsky]]

As far as comment 40 item 5 goes, also need to test {ib} splits inside a run-in, table-internal display types as kids of the run-in, table-internal kids of inline kids of the run-in, and positioned/floated kids of inline kids of the run-in.

Comment 45

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Making whitespace optimization exact would require, among other things, making it work correctly in dynamic situations involving XBL. That scares me a lot.

Comment 46

[Boris Zbarsky [:bzbarsky]]

Ah, very true.  OK.  So we should just do prevsibling stuff, then this.

Comment 47

[Boris Zbarsky [:bzbarsky]]

More notes to self:

1)  Need to fix ReResolveStyleContext (or GetParentStyleContextFrame), possibly,
    depending on what the decision is on how run-ins should inherit style.
2)  Probably need to fix the code in nsLayoutUtils that looks for the ::before
    frame.

Comment 48

[Boris Zbarsky [:bzbarsky]]

And make sure to test on this testcase:


<!DOCTYPE html>
<html>
<body>
  <div style="padding-top: 100px; border: 1px solid green; position: relative">
    <span style="display:run-in"><div style="position: absolute; top: 0; left: 0">aaa</div>bbb</span>
    <div style="position: relative; border: 1px solid black">
    </div>
  </div>
</body>
</html>

Comment 49

[Paul Piskorz]

Why test invalid HTML? (you cannot insert div into span)

Comment 50

[Boris Zbarsky [:bzbarsky]]

You can replace the <span> with <div> in this case.  It doesn't change the thing being tested.

Comment 51

[Boris Zbarsky [:bzbarsky]]

Another test; one that Webkit fails:

            window.onload = function() {
              var text = document.getElementById("x").nextSibling;
              text.data = "";
            };
      <div style="display: run-in" id="x">aaa</div>
      bbb
      <div>ccc</div>

Comment 52

[Boris Zbarsky [:bzbarsky]]

Attachment: reftests for run-in

Should make implementing this at least testable.  Apart from the obvious (spec changes), Webkit fails pretty much every dynamic test (including the one that simulates an HTTP packet boundary!); Opera does somewhat better.

I have no idea how to implement the clearance behavior the spec calls for, and neither Opera nor Webkit implement it.  Maybe it'll go away.

Comment 53

[Daniel.S]

Boris, did you write these tests before or after the spec got cleared up on run-ins? If before, do you think there are tests that are no longer valid?

I'd like to use these tests for IE9 triage, so I can report the obvious failures (that should be there considering IE8).

Also, could you please give a short insight in what you refer to as "the clearance behavior the spec calls for". Thank you.

And thanks for your work on run-in so far :)

Comment 54

[Boris Zbarsky [:bzbarsky]]

The tests were written after the www-style discussion on run-ins.  They were clearly written before actual updates to the spec, since those updates haven't happened yet.  I have no idea when or whether they will happen, nor what the text will say after they happen, of course, though it would be nice if they reflected what was decided on the mailing list.

> what you refer to as "the clearance behavior the spec calls for"

The "clear" property applied to a run-in that runs in is supposed to instead apply to the block it ran into.

Comment 55

[Daniel.S]

I noticed a few bugs in these tests:

 * run-in-contains-table-column-group-001.xht
   does not actually test 'table-column-group' but 'table-column' which is
   already covered by run-in-contains-table-column-001.xht
 * run-in-fixedpos-between-run-in-and-block-001.html
   The class is named 'fixedpos' but the element it should apply to is only
   named 'fixed'.
 * The display: none tests include a colon in the file name, which is
   not allowed on Windows OS's.

And there are points unclear to me:

 * run-in-contains-table-caption-001.xht
   Maybe I oversee something but, sice tables and blocks prohibit run-in,
   shouldn't table-captions prohibit run-it as well?
 * run-in-contains-inline-004.xht
   Without run-in applied "Run-" renders vertically offset in Fx and IE.
   IE keeps the offset when running-in, so this probably needs
   another reference (though Opera and Safari have no vertical offset).

If my observations are correct, IE9 (preview 3) passes all but two tests:

 * The dynamic test of clearance only passes if the text is selected.
 * The line-breaking test in right-to-left situation fails, because
   of "IE's implementatio of rtl" (?).
   However, it looks closer to the reference than Opera and Safari do.
 
> ...nor what the text will say after they happen, of course, though it
> would be nice if they reflected what was decided on the mailing list.

What exactly did the mailing list decide on? The latest information I can find are clarifications about 'float in run-in that clears' which IE9 correctly implements (floats inside run-in that runs-into a clearing element are not cleared).

Very interesting; However, I can't find desicions made after/on top of the new spec text that's in the errata now.

run-in is a haunting display type. High price when you just want to dt {display: run-in} /sigh

Comment 56

[Boris Zbarsky [:bzbarsky]]

> * run-in-contains-table-column-group-001.xht
> * run-in-fixedpos-between-run-in-and-block-001.html

Excellent catch, thanks!

> which is not allowed on Windows OS's.

Bah.  This actually came up in the CSS test suite stuff too; it's been fixed there and locally.

> sice tables and blocks prohibit run-in, shouldn't table-captions prohibit
> run-it as well

Why?  Table-captions are neither tables nor blocks....  In any case, this just tests what was discussed on the mailing list.  The decision was that internal table elements do not prevent running in.

> Without run-in applied "Run-" renders vertically offset in Fx and IE.

I believe that rendering is a bug, whether the run-in has run in or not.  If that turns out to not be the case, the test will need changing, of course.

> If my observations are correct, IE9 (preview 3) passes all but two tests:

Quite possible. They had a much better implementation of run-in in IE8 than Opera and Webkit did.

> What exactly did the mailing list decide on?

Um... quite a number of changes and clarifications, no?  I can dig up the archives, but you can do that as well as I can, I'd think.

> However, I can't find desicions made after/on top of the new spec text that's
> in the errata now.

Link to the text you're talking about here?

> run-in is a haunting display type.

It's a stupid idea is what it is.  But oh, well...

Comment 57

[Daniel.S]

> Why?  Table-captions are neither tables nor blocks....  In any case, this just
> tests what was discussed on the mailing list.  The decision was that internal
> table elements do not prevent running in.

Well CSS 2.1, 17.4 'Tables in the visual formatting model' states:
> The caption boxes are block-level boxes [...] and are rendered as normal
> blocks ...
See http://www.w3.org/TR/CSS2/tables.html#model

As I see it, 'table-caption' comes closer to 'block' than any other display type.

But if there were desicions made concerning anonymous table boxes after the text referenced below was written, I have to dig and research that more thoroughly.

> I believe that rendering is a bug, whether the run-in has run in or not.  If
> that turns out to not be the case, the test will need changing, of course.

Yeah, I was talking about rendering w/o run-in. I can't tell whether it's a bug or not.

> Um... quite a number of changes and clarifications, no?  I can dig up the
> archives, but you can do that as well as I can, I'd think.

Sure, I just thought you might've notes at hand.

> Link to the text you're talking about here?

http://www.w3.org/Style/css2-updates/CR-CSS2-20090908-errata.html#t.9.2.3a

I think that's what we both are aware of; apparently there are some newer desicions that I have not dug up yet.

The only desicion I dug up is
http://lists.w3.org/Archives/Public/www-style/2010Jan/0386.html
which - after repeated reading - is not that clear either.

> It's a stupid idea is what it is.  But oh, well...

It probably should've been dropped together with compact.

But since Opera and IE do quite ok, it would be nice to have it in Gecko as well. However, I understand that there are more important areas to work on. As I said, I just passed by to test IE (found at least one bug, what more can I wish for?).
Next time I will tease David or roc with some margin-collapsing again.

Comment 58

[Boris Zbarsky [:bzbarsky]]

> Sure, I just thought you might've notes at hand.

Yeah, sorry.  I'd assumed people would update the spec in the year+ it would take me to get to working on this.  Clearly I overestimated how likely that was...

> http://www.w3.org/Style/css2-updates/CR-CSS2-20090908-errata.html#t.9.2.3a

That sums up a lot of the changes.  There was the further discussion on floats you found.

But the clear thing in question is actually in the existing draft, now that I went looking for it.  See http://www.w3.org/TR/2009/CR-CSS2-20090908/visuren.html#flow-control the part starting "For run-in boxes" in the second paragraph of the section.

> It probably should've been dropped together with compact.

That might well still happen, since we have nothing resembling two interoperable implementations.  We'll see.

> But since Opera and IE do quite ok

They do?  Last I tested, Opera loses bits of the run-ins text all over the place.  Not as bad as webkit, but pretty bad.

But yeah.  If we can do it, it's nice to have.  It's not a high priority.

Comment 59

[Daniel.S]

(In reply to comment #58)
> Yeah, sorry.  I'd assumed people would update the spec in the year+ it would
> take me to get to working on this.  Clearly I overestimated how likely that
> was...

I think I found the missing pieces, there are discussions about run-in and table boxes from August/September 2009.

> That sums up a lot of the changes.  There was the further discussion on floats
> you found.

There is at least another discussion that talks about tables and anonymous table boxes. But I think I found them in the discussions mentioned above.

> But the clear thing in question is actually in the existing draft, now that I
> went looking for it.  See
> http://www.w3.org/TR/2009/CR-CSS2-20090908/visuren.html#flow-control the part
> starting "For run-in boxes" in the second paragraph of the section.

Yes, I'm sorry, I should have found that line by myself.

> That might well still happen, since we have nothing resembling two
> interoperable implementations.  We'll see.

I think authors have an interest in this display type, so it should only be pushed back to CSS 3, clearing the way for CSS 2.1 REC.

> They do?  Last I tested, Opera loses bits of the run-ins text all over the
> place.  Not as bad as webkit, but pretty bad.

Opera has indeed issues (like it has them all over the place) but they are improving and no comparison to WebKit which is simply broken and non-improving.

Comment 60

[Mardeg]

Well done bz, you outlasted it :)
http://lists.w3.org/Archives/Public/www-style/2011Jan/0542.html
Will this bug be WONTFIXED then?

Comment 61

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Not at all, the main reason it was dropped from CSS2 is to finally finish that specification. display:run-in will come back in CSS3, and we still want to implement it. On a technical level, this decision doesn't change anything.

Comment 62

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm not sure who the "we" is, but I really don't think it's worth implementing compared to the other things that could be done with the same amount of work.

Comment 64

[Alan{H}]

Copying from duplicate bug.

CSS 2.1 defines `display: run-in`.[^1] Firefox 4 does not support this yet,
despite supporting virtually every other part of the CSS standard.

Furthermore, it is the only major browser to completely lack such support. Even IE8
supports the `run-in` property correctly, as does Safari (which has supported
it for a while, and added fully correct support in Safari 5.) [^2]

`run-in` is certainly an unusual `display` property, but not without its uses.

For example, consider this snippet:

<h3>Fred C.</h3>
<div class="bio-title">Co-Founder</div>

With CSS like this:

h3 { display: run-in; font-size: 1em; }
h3:after {content: ", ";}

then this could be rendered as:

"Fred C., Co- Founder" on one line.

This use-case has workarounds, but I hope to convince you they are notwithout
downsides (implying unique advantages to proper run-in support):

1. First work-around: Include the co-founder bit as a <span> in the <h3>.
   Downside: This pollutes the H3, for example, slowing down users of assistive
technologies. In VoiceOver’s “Rotor” feature, for example, a list of all
heading-level elements is generated. Now it includes the title as well as the
name. The document author should be able to make this decision.

2. Second work-around: Wrap both elements in an extra div, and render its
contents with display: inline.
   Downside: Extra markup, which is not always desirable (this isn’t semantic)
or possible (e.g. user stylesheets, either in a browser or to modify a social
networking profile page on a site which allows users to specify stylesheets).

3. Third workaround: Modify the DOM using JS to simulate work-arounds #1 or #2
   Downsides: requires javascript, which is not always possible or desirable,
as well as incurring the downsides of options #1 or #2.

Note that if no work-around is used, then Firefox becomes the only browser to incorrectly display the test-case above as:

Fred C.,
Co-Founder

Which is obviously undesirable and frankly embarrassing.

[^1]: http://www.w3.org/TR/CSS21/visuren.html#display-prop
[^2]: http://www.quirksmode.org/css/display.html

Comment 65

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to comment #64)
> CSS 2.1 defines `display: run-in`.[^1] 

Wrong, see the link in comment #60.

> IE8
> supports the `run-in` property correctly, as does Safari (which has supported
> it for a while, and added fully correct support in Safari 5.) [^2]

Also wrong, see the link in comment #60.

Comment 66

[Daniel.S]

(In reply to comment #64)
> Even IE8 supports the `run-in` property correctly, as does Safari (which has
> supported it for a while, and added fully correct support in Safari 5.) [^2]

run-in is currently not defined well enough for one to claim correct support.
I wouldn't say WebKit had even decent support for it either.

The CSS WG has its focus on finishing CSS 2.1, so run-in has been moved to CSS3. Because the W3C does not have enough specification writers, many ideas are there but not actively worked on. One such feature is run-in. The CSS WG will continue to work on more fancy features.

> `run-in` is certainly an unusual `display` property, but not without its uses.

It's only unusual to the web, because neither Microsoft (until IE8) nor Mozilla cared to implement it in the past. Some devs told me that authors regularly ask about it, though.

If you want it implemented, write a apecification and a patch. There's no other way at the moment.

Comment 67

[Patrick Dark]

@Comment 64: I believe your use case is covered by HTML5; it has specific elements tailored to this purpose:

<hgroup>
  <h3>Fred <abbr>C.</abbr></h3>
  <h4 class="bio-title">Co‐Founder</h4>
</hgroup>

Comment 68

[Alan{H}]

@Comment 67: That would certainly work, but it changes the meaning of the co-founder line — as the author, I do not believe that the job title deserves to be labled as if it were a section title. Understood that hgroup redefines that h4 to be a sub-title of the section, but still, it doesn’t seem to accurately describe the intention.

Regardless, the biggest problem is this requires changes to the markup.

@Comment 65: Understood, but it isn’t "wrong" to say CSS2.1 defined `display: run-in`. It did 11.3 years ago when this ticket was opened, and may yet (has that recent resolution taken effect yet?).

Comment 69

[sjw]

Because it's not possible to add more than one URL, here is the old one:
http://dbaron.org/css/test/sec090204

I think the spec matches better.

Comment 70

[Boris Zbarsky [:bzbarsky]]

The "spec" you just linked to is a complete fiction that no one is planning to implement and hasn't been updated in 6 years.  Please just don't mess with the URL field...

Comment 71

[David Bruant]

display: run-in has been removed from Blink. 

https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/display$20run-in/blink-dev/_tHSX0IYXhQ/49p6u3yl-6oJ
"The use counter reports that the feature is only used on 0.008% of page views." (no idea how they do the measurement, but it's been convincing enough for them to drop it)

https://codereview.chromium.org/53373003

Effective in Chrome 32 as can be noticed in http://css-tricks.com/examples/Runin/

WONTFIX?

Comment 72

[Anne (:annevk)]

The last email in that thread suggests it will still be part of the standard (which would not be compatible with what Blink had). We could have a different bug for that, but we might as well keep this one.

Comment 73

[David Bruant]

(In reply to Anne (:annevk) from comment #72)
> The last email in that thread suggests it will still be part of the standard
> (which would not be compatible with what Blink had).
Tab ends with "in the future when we have a definition for it" which seems far in the future.
display:run-in is typically the kind of features the Webkit-only web could have jumped on. The fact that they apparently didn't (not enough for Chrome to care at least) suggests that authors don't really care.

Comment 74

[Vincent Lefevre]

Authors don't use it mainly because it is not implemented, not because they don't care. I wanted to use it in the past, but it didn't work with Mozilla, so that I decided not to use it.

Comment 75

[Julian Reschke]

(In reply to Vincent Lefevre from comment #74)
> Authors don't use it mainly because it is not implemented, not because they
> don't care. I wanted to use it in the past, but it didn't work with Mozilla,
> so that I decided not to use it.

Indeed. Same here.

Comment 76

[Jared Jacobs]

My story is similar, except that I did use it for a few months, and then I received a user complaint about the layout in Firefox, so I removed my use of display: run-in. I didn’t initially test that particular layout in Firefox because I couldn’t imagine modern Firefox not supporting a CSS2 feature.

I mention this in an attempt to combat the apparent mindset among some of the Firefox team that if they drag their feet long enough, they can eventually “win” and never have to implement standards (W3C, WHATWG, or de facto) that they don’t like. (e.g. see 13-year-old bug 63895)

I don’t mean to be critical. I understand that there are a lot of competing demands in a large project like a modern browser. If there are valid concerns at play (e.g. performance), please let them be known. I’m afraid at present it looks like laziness.

Comment 77

[Boris Zbarsky [:bzbarsky]]

> If there are valid concerns at play (e.g. performance), please let them be known.

They are discussed at length in this bug, if you had cared to read it.  But allow me to summarize for you:

1)  There is no specification for how this should actually behave.
2)  The existing implementations disagree wildly on the behavior.
3)  The CSS working group is not sure what they want the behavior to be, but will try to
    get it sorted out sometime.
4)  Whatever they decide on is going to end up very complicated and fragile, by the very
    nature of this feature, requiring a lot of complex code to actually get it right.

Given all that, implementing something "non-broken" (read: complicated) right now would be a complete waste of time, because chances are the working group will decide on some other behavior.  Implementing something broken quickly (e.g. the WebKit approach for this feature) means people will start using it, be horrified by how broken it is (justifiably!)... and we don't particularly want to go down that route.

Bug 63895 is an entirely different situation, with a clear spec.  The issue there is "just" that it requires a large refactoring of complicated code that no one has understood in about a decade.

Comment 78

[Jared Jacobs]

Thanks for the summary, and sorry for the unmerited criticism.

Personally, I’d have chosen to support the simplest, common use of display: run-in, like the example initially given in the CSS 2 spec:
http://www.w3.org/TR/2008/REC-CSS2-20080411/visuren.html#run-in

...and treat display: run-in as display: block whenever any complications arose, since that would likely meet the needs of most authors, then iterate on the implementation as the specification matured and the other browsers’ behavior converged, but I can understand your desire for a more complete specification and perfect implementation from Day 1.

I’ll be patient and never complain about display: run-in again.

Comment 79

[Boris Zbarsky [:bzbarsky]]

> and treat display: run-in as display: block whenever any complications arose

"complications" in this case unfortunately includes "any DOM mutations in the future around the run-in".  So it's not possible to detect them arising.  :(

Comment 80

[Boris Zbarsky [:bzbarsky]]

For one example of such a complication, last I tested a simple removal of the block following the run-in from the DOM made the run-in disappear entirely from the rendering in WebKit...  I'm really hoping they've at least fixed _that_ since then.

Comment 81

[philippe (part-time)]

Fwiw, WebKit plans to remove support for display:run-in from their tree (following the same action by Blink, see comment 71 above).
https://bugs.webkit.org/show_bug.cgi?id=127874

Comment 82

[yisibl]

Don't know that servo has a plan to implement this feature?

Comment 83

[Thomas Wisniewski]

Given that Chrome dropped display:run-in in version 32, Safari around version 8, and Edge decided to not support it, is there a reason to leave this bug open instead of just closing it as WONTFIX?

Comment 84

[Alan H]

It’s been dropped from CSS as a result of Gecko never implementing it, so a WONTFIX does seem appropriate

Comment 85

[j.j.]

(In reply to Alan H from comment #84)
> It’s been dropped from CSS as a result of ...

It's in CSS Display Module Level 3
https://drafts.csswg.org/css-display/#run-in-layout

Comment 86

[Thomas Wisniewski]

Good to know, thanks j.j.

Comment 87

[Jen Simmons [:jensimmons]]

I've been researching `display: run-in;` over the past couple days. 

It seems the CSS 2 spec was not a good one, and the resulting implementations were not good, and thus were removed from browsers. There is a new spec for `display: run-in;` defined in CSS Display Module Level 3, as linked to above. (https://drafts.csswg.org/css-display/#run-in-layout)

In talking to several authors, there is great interest in having this CSS. Usecases quickly came to mind. I believe this should be implemented. Perhaps the spec is now ready, or will be shortly. 

While this issue is 19 years old, and seems to have died, I think we should consider this an issue with new life.

Comment 88

[Boris Zbarsky [:bzbarsky]]

Unfortunately, the new spec is not very good either.  It has all sorts of undefined or underdefined behavior with other parts of CSS and adds a great amount of complexity, especially to dynamic change handling.  And there is continuing resistance on the part of the working group to improving the spec, or even acknowledging problems with it.  :(

Are we sure that the use cases this allows are worth the costs in spec and implementation complexity?  If we are, we should probably spend the time to actually make the spec make sense as a start; this is probably multiple person-months worth of work.

My personal suspicion is that the use cases this allows are not worth the complexity and performance complications that will ensue...

Comment 89

[Andy Edmonds]

I can understand hesitation around supporting the usage outlined in the spec. It seems to me that adoption would be limited. 

However, this spec could be very useful for responsive implementations. Specifically, being able to tuck content into collapsed or closed elements for mobile.

A paragraph of copy that would become obtrusive on a mobile screen could run-in to a paragraph that is a collapsed accordion for instance. For this page: https://www.quill.com/resource-center/cbi/72.cshtml I had to write 20 lines of javascript to accomplish a task that a simple media query would be able to handle if this spec was supported.

Comment 90

[Boris Zbarsky [:bzbarsky]]

Andy, thank you, that is very useful information on use cases!  Can you point me to the part of that quill.com page that is doing the run-in behavior you describe?  It's not being obvious to me...

Comment 91

[Andy Edmonds]

(In reply to Boris Zbarsky [:bz] (if a patch has no decent message, automatic r-) from comment #90)
> Andy, thank you, that is very useful information on use cases!  Can you
> point me to the part of that quill.com page that is doing the run-in
> behavior you describe?  It's not being obvious to me...

Thanks for the quick reply!

On https://www.quill.com/resource-center/cbi/72.cshtml the paragraph element beginning with "For all of your work-related questions.." gets tucked into the following paragraph, beginning with "Your job extends far beyond..", when the view port is < 567px.

Comment 92

[Boris Zbarsky [:bzbarsky]]

I see, thank you.

Unfortunately, implementing the run-in spec as it currently exists would not address this use case.  The basic structure of the page here is like so (relevant styles from the stylesheets inlined):

  <div class="intro">Stuff</div>
  <div class="accordion" style="overflow: hidden">
     More stuff
  </div>

with the idea that the intro div moves inside the accordion div at small widths, and the accordion can hide or show it by switchiing its height from 0 to auto.  But the run-in spec 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 ...

and "overflow: hidden" establishes a new block formatting context (see https://www.w3.org/TR/CSS2/visuren.html#block-formatting first paragraph), so if the intro div were display:run-in it would still not run into the accordion div.

Comment 93

[Andy Edmonds]

got it(In reply to Boris Zbarsky [:bz] (if a patch has no decent message, automatic r-) from comment #92)
> I see, thank you.
> 
> Unfortunately, implementing the run-in spec as it currently exists would not
> address this use case.  The basic structure of the page here is like so
> (relevant styles from the stylesheets inlined):
> 
>   <div class="intro">Stuff</div>
>   <div class="accordion" style="overflow: hidden">
>      More stuff
>   </div>
> 
> with the idea that the intro div moves inside the accordion div at small
> widths, and the accordion can hide or show it by switchiing its height from
> 0 to auto.  But the run-in spec 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 ...
> 
> and "overflow: hidden" establishes a new block formatting context (see
> https://www.w3.org/TR/CSS2/visuren.html#block-formatting first paragraph),
> so if the intro div were display:run-in it would still not run into the
> accordion div.

Got it. Thanks!

Comment 94

[Jonathan Watt [:jwatt]]

Webkit and Blink no longer have run-in, and it seems it doesn't work in IE either.

Comment 95

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates, 116 votes and 86 CCs.
:jfkthame, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 96

[Jonathan Kew [:jfkthame]]

I don't think this rates a higher severity at the moment, given lack of support in any other modern browser (comment 94), and it sounds like the spec may not really be ready anyhow (e.g. comment 88, comment 92).

Comment 97

[Joe Walker [:jwalker]]

Partial support for display:run-in was removed from WebKit and Blink many years ago. IE11 (pre-Blink) had (some) support, however as IE11 is not actively maintained, there are zero modern browser engines with support for this feature and we are unaware of any interest in reviving it as specified.

We believe that display:run-in should be removed from any CSS specs being maintained. If there is web developer/author interest in this sort of "run-in" styling functionality we should redesign a new feature that is based on the host language having a definition/concept of "paragraph" as noted for example in https://html.spec.whatwg.org/multipage/dom.html#paragraph.