W3C home > Mailing lists > Public > www-style@w3.org > January 2008

Re: Time to drop "almost standards mode"?

From: L. David Baron <dbaron@dbaron.org>
Date: Mon, 28 Jan 2008 14:14:01 -0800
To: www-style@w3.org
Message-ID: <20080128221401.GA16280@ridley.dbaron.org>

On Monday 2008-01-28 19:12 +0100, Anne van Kesteren wrote:
> The amounts of duplicates in 
> https://bugzilla.mozilla.org/show_bug.cgi?id=22274 seems to keep growing. 
> Now with bugs about SVG inside table cells instead of spacer gifs. Maybe it 
> is time to reconsider and specify the behavior of "almost standards mode" 
> (which Internet Explorer exhibits in "standards mode" as I understand it) 
> in CSS 2.1 thereby effectively obsoleting the need for "almost standards 
> mode".
> http://developer.mozilla.org/en/docs/Images%2C_Tables%2C_and_Mysterious_Gaps 
> is the old article on this subject (though it was previously located on 
> developer.netscape.com).

I agree that this was a mistake, for two reasons:

 1. breaking compatibility with too much existing content

 2. it pushed authors away from using table-based layouts to doing
    things that are even worse, such as absolute positioning and
    very fragile uses of floats.  This was actually one of my
    initial reasons for pushing hard to keep the behavior CSS2
    specified rather than changing it, but I failed to realize what
    would replace it given the lack of a good user-interface layout
    model in CSS.  I was also less concerned about breaking
    compatibility then than I am now.

> To potential ways we can solve this:
> * Introduce a CSS new property to toggle between the different behaviours 
> defaulting to the "almost standards mode" one for HTML table elements.

I don't like mode properties very much because they don't cascade
well, but I suppose it's probably not too much of a problem in this
case because line-heights aren't that big a deal in terms of
cascading (although they might be a little bit in enforcing a
minimum-font-size preference).  I'd note that I've had a proposal
for such a mode property called line-box-contain:


I have an action to edit it into css3-linebox which turned out
to be more difficult than I expected; I should probably get back to
it sometime, though.  The draft (above) says:

# Note that the CSS2 model is equivalent to 'block inline replaced'
# but the backwards-compatible HTML model is similar to (but not
# exactly) 'font replaced' [1]
# [1] I believe the differences are restricted to the first line of
# LI elements, the last line of LI, DD, and DT elements, and issues
# concerning whitespace around images. [DB] 

(I think there's actually an error here, and the backwards-
compatible model is "font inline replaced"; I think the line-height
of inline elements does affect the line in quirks mode.)

I'd also note that if I were designing from scratch I'd make the
default be more like "block font inline-box replaced".

> * Change the CSS model to behave like "almost standards mode" does now. And 
> maybe going forward introduce a new property to get the behavior described 
> now if that's desirable.

There are actually other reasons for wanting a mode-switching
property, since almost-standards-mode behavior isn't really ideal.
By ideal, I mean the thing that best satisfies the two goals:

 1) Ensure inter-line spacing is the same over lines (i.e., even
 spacing of baselines), which makes the text look better and ensures
 that text in different parts of the page (e.g., different columns)
 lines up properly.

 2) Ensure that objects don't overlap (unintentionally).

Note that some people have argued that we should only do (1) and
leave (2) entirely to the author.  However, this is rather dangerous
on the Web because many things that could cause overlap vary with
changes in device characteristics and user preferences, and authors
can't possibly test to ensure no overlap in all situations.


L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/
Received on Monday, 28 January 2008 22:14:11 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:33 UTC