RE: "non-zero top border" in 8.3.1

On Thu, 6 Sep 2007, Alex Mogilevsky wrote:
> 
> Now that I understand the spec, can you explain why this behavior is 
> preferable to what Firefox and Safari are doing?

It's preferable mostly just because it's defined, whereas what Firefox and 
Safari do isn't. While we could keep on changing the spec every other 
month, Web browser vendors are unlikely to enjoy having to code to such a 
moving target, especially when the area is as complex as margin collapsing.

There is no guarentee that if we tried to spec what Firefox and Safari do 
today that we'd get the spec to match exactly what they do. We'd probably 
just move the bugs from one area to another area, except that we wouldn't 
necessarily find out what the new bugs were for months or years. At least 
now we have a good handle on it, as well as a huge number of tests.


> They put any empty element exactly at the same position where it would 
> be if it wasn't empty (as long as adding content doesn't prevent its top 
> margin from collapsing with any children). That has continuity, and it 
> is more intuitive (at least for me). If the spec says otherwise there 
> must be a strong reason - what is it?

The strongest reason is that this was what we agreed to. If we change 
these rules it could have very subtle effects that might not be understood 
for years, at which point we'd be back to the same position as we are in 
now: thinking the rules are unintuitive and wanting to change them in 
another subtle way.

The only reason that I would consider valid for changing margin collapsing 
rules at this point is if implementing the rules results in serious 
incompatibilities with existing content on major sites.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 6 September 2007 20:48:10 UTC