Last Comment Bug 2056 - display: run-in not implemented
: display: run-in not implemented
Status: NEW
[bae:20011119] hit during nsbeta2 sta...
: css3, dev-doc-needed, testcase
Product: Core
Classification: Components
Component: Layout: Block and Inline (show other bugs)
: Trunk
: All All
: P2 normal with 116 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://dbaron.org/css/test/sec090204
: 280039 291016 635637 (view as bug list)
Depends on:
Blocks: 15432
  Show dependency treegraph
 
Reported: 1998-12-24 11:08 PST by David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
Modified: 2016-07-23 13:03 PDT (History)
84 users (show)
roc: blocking1.9.2-
roc: wanted1.9.2-
roc: blocking1.9.1-
roc: wanted1.9.1-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
test (10.00 KB, text/html)
2005-04-10 07:05 PDT, Mildred Ki'Lya
no flags Details
A more eloquent reason to support run-in (6.01 KB, application/xhtml+xml)
2006-10-24 06:47 PDT, David Latapie
no flags Details
A more eloquent incentive for support run-in support (update) (6.10 KB, application/xhtml+xml)
2006-10-24 08:00 PDT, David Latapie
no flags Details
run-in as implemented in Opera and IE8 (per current spec) (1.31 KB, text/html)
2009-03-20 09:14 PDT, Daniel.S
no flags Details
Some notes to self in code form (13.33 KB, patch)
2009-07-11 01:02 PDT, Boris Zbarsky [:bz]
no flags Details | Diff | Splinter Review
reftests for run-in (199.33 KB, patch)
2010-01-15 19:42 PST, Boris Zbarsky [:bz]
no flags Details | Diff | Splinter Review

Description David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 1998-12-24 11:08:16 PST
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 1999-01-06 18:08:59 PST
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-7 (review requests must explain patch) 1999-01-06 18:24:59 PST
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 1999-02-03 08:07:59 PST
Setting all current Open/Normal to M4.
Comment 4 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 1999-03-05 17:20:59 PST
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-7 (review requests must explain patch) 1999-03-05 17:20:59 PST
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 1999-03-05 22:38:59 PST
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 1999-03-18 13:13:59 PST
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-7 (review requests must explain patch) 1999-04-23 12:52:59 PDT
There are other fans of this feature:

http://www.webreference.com/html/gecko/7.html
Comment 9 Hixie (not reading bugmail) 1999-05-14 11:25:59 PDT
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) 1999-05-14 11:26:59 PDT
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-7 (review requests must explain patch) 1999-05-14 20:00:59 PDT
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) 1999-10-03 15:26:59 PDT
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) 2000-01-13 16:06:59 PST
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) 2000-07-28 19:49:56 PDT
Reopening and moving to Future...
Comment 15 Andrew Thompson 2000-09-09 14:23:30 PDT
add self to cc
Comment 16 Kevin McCluskey (gone) 2001-10-04 16:28:31 PDT
Build reassigning Buster's bugs to Marc.
Comment 17 Madhur Bhatia 2001-10-22 12:57:40 PDT
any progress with this bug?
Comment 18 rubydoo123 2001-11-20 16:31:27 PST
just ran Ian's evil test case and we still fail on this issue

reduced priority to P4
Comment 19 Boris Zbarsky [:bz] 2003-05-01 22:50:25 PDT
.
Comment 20 raulitosena 2003-06-13 11:30:25 PDT
..
Comment 21 Max Kanat-Alexander 2003-07-18 00:01:24 PDT
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) 2003-07-18 06:29:06 PDT
The URI in comment 9 still works for me.
Comment 23 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-07-18 14:27:31 PDT
http://dbaron.org/css/test/sec090204 is the current version of the original URL.
Comment 24 Myles Catchpole 2003-08-28 00:24:20 PDT
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 2004-09-15 08:59:08 PDT
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 2005-01-27 07:15:07 PST
*** Bug 280039 has been marked as a duplicate of this bug. ***
Comment 27 daneel 2005-03-27 06:25:38 PST
This is implemented already in KHTML and Presto. C'mon! Don't make me feed Gecko 
same styles as IE!
Comment 28 Anne (:annevk) 2005-03-27 06:30:04 PST
Please don't add useless advocacy comments to bugs. Raise your opinions in the
forums.
Comment 29 Mildred Ki'Lya 2005-04-10 07:05:30 PDT
Created attachment 180274 [details]
test

source: http://www.quirksmode.org/css/display.html
Comment 30 Anne (:annevk) 2005-04-19 12:32:20 PDT
*** Bug 291016 has been marked as a duplicate of this bug. ***
Comment 31 David Latapie 2006-10-24 06:47:20 PDT
Created attachment 243347 [details]
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 2006-10-24 06:56:51 PDT
(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 2006-10-24 08:00:50 PDT
Created attachment 243356 [details]
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 2008-05-16 08:01:08 PDT
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) 2008-06-04 14:40:32 PDT
this is either going to be easy or intractable...
Comment 36 gabe 2009-01-31 14:10:07 PST
this works in ie8 it seems
Comment 37 Daniel.S 2009-03-20 09:14:34 PDT
Created attachment 368534 [details]
run-in as implemented in Opera and IE8 (per current spec)
Comment 38 Boris Zbarsky [:bz] 2009-07-10 16:19:17 PDT
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 [:bz] 2009-07-11 00:59:34 PDT
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 [:bz] 2009-07-11 01:02:47 PDT
Created attachment 388040 [details] [diff] [review]
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 [:bz] 2009-07-11 20:21:25 PDT
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 [:bz] 2009-07-12 10:53:35 PDT
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 [:bz] 2009-07-12 10:56:36 PDT
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 [:bz] 2009-07-12 12:55:30 PDT
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) (Exited; email my personal email if necessary) 2009-07-12 15:39:39 PDT
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 [:bz] 2009-07-12 16:16:25 PDT
Ah, very true.  OK.  So we should just do prevsibling stuff, then this.
Comment 47 Boris Zbarsky [:bz] 2009-09-02 08:47:03 PDT
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 [:bz] 2009-09-04 13:18:43 PDT
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 2009-09-05 12:00:04 PDT
Why test invalid HTML? (you cannot insert div into span)
Comment 50 Boris Zbarsky [:bz] 2009-09-06 07:55:08 PDT
You can replace the <span> with <div> in this case.  It doesn't change the thing being tested.
Comment 51 Boris Zbarsky [:bz] 2009-10-28 09:22:18 PDT
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 [:bz] 2010-01-15 19:42:18 PST
Created attachment 421975 [details] [diff] [review]
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 2010-07-18 10:48:12 PDT
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 [:bz] 2010-07-18 13:31:55 PDT
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 2010-07-22 12:23:53 PDT
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 [:bz] 2010-07-22 12:43:51 PDT
> * 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 2010-07-22 13:32:49 PDT
> 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 [:bz] 2010-07-22 13:46:38 PDT
> 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 2010-07-25 07:02:31 PDT
(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 2011-01-28 00:50:32 PST
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 (⌚ UTC+1/+2) 2011-01-28 03:18:11 PST
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-7 (review requests must explain patch) 2011-01-28 09:32:37 PST
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 63 José Jeria 2011-02-20 14:29:38 PST
*** Bug 635637 has been marked as a duplicate of this bug. ***
Comment 64 Alan{H} 2011-02-20 15:27:05 PST
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) (Exited; email my personal email if necessary) 2011-02-20 15:44:12 PST
(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 2011-02-21 10:37:24 PST
(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 2011-02-21 22:28:18 PST
@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} 2011-02-22 17:10:50 PST
@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 2013-12-01 13:55:54 PST
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 [:bz] 2013-12-01 14:05:04 PST
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 2014-01-15 06:05:02 PST
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) 2014-01-15 06:13:41 PST
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 2014-01-15 06:20:49 PST
(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 2014-01-15 07:59:48 PST
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 2014-01-30 07:39:57 PST
(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 2014-01-30 09:18:48 PST
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 [:bz] 2014-01-30 09:31:47 PST
> 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 2014-01-30 10:11:04 PST
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 [:bz] 2014-01-30 10:24:11 PST
> 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 [:bz] 2014-01-30 10:25:35 PST
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) 2014-01-30 14:50:07 PST
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 percyley 2016-05-25 10:24:52 PDT
Don't know that servo has a plan to implement this feature?
Comment 83 Thomas Wisniewski 2016-07-19 11:48:44 PDT
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 2016-07-19 13:01:39 PDT
It’s been dropped from CSS as a result of Gecko never implementing it, so a WONTFIX does seem appropriate
Comment 85 j.j. 2016-07-19 14:53:17 PDT
(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 2016-07-19 15:05:51 PDT
Good to know, thanks j.j.

Note You need to log in before you can comment on or make changes to this bug.