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???

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.

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.

Setting all current Open/Normal to M4.

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.

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.

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

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

There are other fans of this feature: http://www.webreference.com/html/gecko/7.html

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

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

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.

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.

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...

Reopening and moving to Future...

add self to cc

Build reassigning Buster's bugs to Marc.

any progress with this bug?

just ran Ian's evil test case and we still fail on this issue reduced priority to P4

.

..

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

The URI in comment 9 still works for me.

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

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.

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

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

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

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

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

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

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.

(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.

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.

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?

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

this works in ie8 it seems

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.

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.

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.

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).

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? ;)

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?

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.

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

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

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.

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>

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

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

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>

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.

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 :)

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.

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

> * 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...

> 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.

> 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.

(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.

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

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.

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.

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

(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.

(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 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 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?).

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.

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...

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?

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.

(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.

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.

(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.

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.

> 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.

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.

> 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. :(

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.

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

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

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?

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

(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

Good to know, thanks j.j.

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.

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...

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.

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...

(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.

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(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!

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