Since we’re on the topic of longstanding Firefox issues: Add support for `display: run-in` already. You are the ONLY browser not to support it. http://www.quirksmode.org/css/display.html
Last I brought this up, I was told:
1. that it wasn’t completely defined, and some edge cases can arise
2. that it 'wasn't necessary' as you could 'solve' the problem by adding more (wrapping) markup
3. that `run-in` was going to be dropped from CSS2.1.
None of this is very valid.
1. So do what the other browsers do, and/or when you encounter a weird edge case, fall back to `display: block` (as suggested by the spec).
2. Adding more markup (A) because one browser is being pissy (B) goes against the fundamental philosophies of both CSS (A) and web standards (B). Clearly!
3. It’s only being dropped from the spec because they can finalize the spec if it is 100% implemented by 100% of the major browsers. So this is circular reasoning caused by your ten-year rolling decision to ignore `run-in`.
Run-in is a very useful concept (I’m always tempted to use it on /about.html). Please, reconsider.
What other browsers do is completely insane (e.g. removing a block that a run-in has run into makes the run-in just disappear altogether in WebKit), so implementing it would be actively bad for the web.
> It’s only being dropped from the spec because they can
> finalize the spec if it is 100% implemented by 100% of
> the major browsers.
They can finalize the spec as long as every feature is implemented interoperably by _two_ browsers.
There are three run-in implementations, and they're completely incompatible. The feature got dropped from the spec because the working group couldn't figure out any way to even define a restricted behavior subset that Presto, Trident, and WebKit implement the same way.
So no, Gecko's lack of implemetation here didn't block the spec in any way. The fact that all three existing implementations are completely incompatible with each other and all horribly broken had a lot more to do with it.
Last I brought this up, I was told:
1. that it wasn’t completely defined, and some edge cases can arise
2. that it 'wasn't necessary' as you could 'solve' the problem by adding more (wrapping) markup
3. that `run-in` was going to be dropped from CSS2.1.
None of this is very valid.
1. So do what the other browsers do, and/or when you encounter a weird edge case, fall back to `display: block` (as suggested by the spec).
2. Adding more markup (A) because one browser is being pissy (B) goes against the fundamental philosophies of both CSS (A) and web standards (B). Clearly!
3. It’s only being dropped from the spec because they can finalize the spec if it is 100% implemented by 100% of the major browsers. So this is circular reasoning caused by your ten-year rolling decision to ignore `run-in`.
Run-in is a very useful concept (I’m always tempted to use it on /about.html). Please, reconsider.