On 2007-05-30 02:19:48 +0200 Jon Barnett <[EMAIL PROTECTED]> wrote: > On 5/29/07, Anne van Kesteren <[EMAIL PROTECTED]> wrote: >> >> I don't care much for the semantic side of things but changing section 8.2 >> (and Acid2) to make <p><table> not become <p></p><table> as per HTML4 >> would be fine with me. We discussed this recently in #whatwg. Simon has >> some ideas about it.
Fingers x-ed. I updated my little testpage <http://www.malform.no/prov/content-model/index.html> with a version version in the «opposite mode» <http://www.malform.no/prov/content-model/html.index.html> so you e.g. can see how TABLE in IE inherits font color and font size from P when in Standards, but not so, when in Quirks. > Is there a link to any of this discussion? I imagine my searching for <p> > or "p element" might be futile. I suppose Anne referred to IRC, for which Whatwg.org points to this log <http://whatbot.charlvn.za.net/>. > Given: > <p>This is a lengthy paragraph that talks about the following table > <table>... > > Breaking scripts that depend on p.nextSibling to be the table and styles > that depend on p + table to work (and other various DOM issues) is an > obvious point, and I'm sure it's been discussed. That script would then allready be broken, cross-browser wise, I suppose? The worst case is probably not when authors uses p+table{}, because then clean IE targetted styling stands ready to pick-up. The worst is if important TABLE styles was targetted via table{} for OperaSafariFirefox, but via _table{} for IE. (But then the underscore hack is not considered good coding style either ...) THis will fix itself, when IE fix their browser (and remove the #table{} option and other hack-arounds). Allthough there are also lots - most? - of content out there, for which it is quite irrelevant whether TABLE is sibling or child of the nearest P. P and TABLE are often contained in a DIV which carries the styling that positions that container on the page. That MSIE and the others see <P><TABLE> so differently, without most of us recognising any difference on page, should be quite telling. Collapsing vertical Margins plays an important role in hiding the effects, I suppose. For instance if you have <P>text<P><TABLE><P>text, then the empty P that Opera-Safari-Firefox currently see in standards-mode, may become completely collapsed, unless you add padding-top/-bottom or border-top/-bottom to it. The reason collapsing vertical margins is such a useful default CSS behaviour, is probably simply because it is so typical to not add padding-top/padding-bottom or border-top/border-bottom. (When one do add padding/border, then the vertical margin collapsing behaviour stops working, and the author gets a whole lot more to think about, with regard to the vertical space between the elements.) -- leif
