[whatwg] P element's content model restrictions

[Leif Halvard Silli]

On 2007-05-30 02:19:48 +0200 Jon Barnett <jonbarnett at gmail.com> wrote:

> On 5/29/07, Anne van Kesteren <annevk at opera.com> 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