W3C home > Mailing lists > Public > public-html@w3.org > December 2007

Re: DogFood (and inline/block constraints)

From: Henri Sivonen <hsivonen@iki.fi>
Date: Thu, 20 Dec 2007 15:07:01 +0200
Cc: simonp@opera.com, public-html@w3.org
Message-Id: <EE650848-7343-4EFB-9E65-63F0A8352A62@iki.fi>
To: David Carlisle <davidc@nag.co.uk>

On Dec 13, 2007, at 18:03, David Carlisle wrote:

>>   1. text/html is not able to express blocks in Ps.
> Yes, Ian stressed this. I wasn't aware of this in my initial  
> comments (I
> was aware that this was true in html4, but not it is a hard constraint
> for html5) This is a shame but I'm not going to argue the point.
> Although to be honest I don't understand it, how can you add any new
> features if the parser is fixed?

Generally, we cannot add new features that would conflict with how  
existing content needs to be processed. For example, we cannot say  
that <ol> doesn't imply </p> when the "p" element is on the stack when  
<ol> is seen.

We can introduce new features that do not interfere with the  
processing of existing content. For example, we could add <math>  
subtree parsing to text/html without having to close "p" elements on  
<math>, because there is no pre-existing compatibility requirement to  
close "p" elements on <math>.

Thus, the issues of display math and in-paragraph lists are different  
from the parser point of view. If we figure out how to add <math> and  
<svg> tree builder insertion modes into the text/html parser, putting  
those subtrees inside "p" elements won't be an additional problem.

For Gecko and WebKit, the issue with intra-paragraph lists could be  
hacked around by making it conforming to use intra-paragraph list if  
the list is immediately wrapped in a "span" element like this:

Unfortunately, this trick doesn't work in IE or Opera. Also, the  
discussion about this today on IRC revealed that this trick doesn't  
work with the HTML5 parsing algorithm, since the HTML5 algorithm as  
currently drafted does not even agree with the commonality of what  
Gecko, WebKit, Opera and IE do. Regardless of what we make conforming,  
the parsing algorithm should probably be fixed to follow Gecko and  
WebKit on this point (since what they do on this point is more useful  
and elegant than what Opera and IE do and given that they can get away  
with doing it suggests that doing it doesn't Break the Web).

> Yes, as I said to Ian, I'd strongly argue that the content model for  
> the
> different linearisations should be the same, I'd rather they both  
> used a
> content model that I don't like, than just xhtml was fixed.

I agree. As of today's draft, structured inline content is gone and  
the content models are text/html-serializable even for XHTML5.

>> If p is really broken in html for ever (in the sense that it can't  
>> model
> natural language paragraphs with block level inserts) then it makes it
> more important that html5 doesn't stop div being used for that  
> purpose.

As of today, <div>'s content model is back to what it was in HTML 4.01  

Henri Sivonen
Received on Thursday, 20 December 2007 13:07:22 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:29 UTC