Re: [CSS2.1] Yet another white-space issue with anonymous table objects

Michael Jansson wrote:
> Sorry, I was referring to SGML as the foundation for both XML and HTML. 

In practice, no reasonable HTML parser is actually based on HTML, right?

> It describes how spaces are handled in general (not just in blocks or 
> inlines). I believe a valid XML parser should handle the space before 
> any white space processing is done in accordance with section 16.6.1 of 
> CSS 2.1.

Every XML parser I've tried recently preserves whitespace (as in, it 
ends up in the DOM if a DOM is constructed).  So assume there is a 
whitespace node in the DOM here.  That's certainly behavior compliant 
with the DOM and with XML, and the de-facto behavior of common browsers 
that ship XML parsers.

>> This assumption seems to have no basis in the CSS2.1 specification.  
>> If this is the desired behavior, then it needs to be actually 
>> specified somewhere, explicitly.
> The anonymous block would not contain any elements, since the white 
> space would be removed. Without content and since margin, padding, 
> border etc are not inherited, the block would not be able to have any 
> size. Without content and size, one could argue that it should be safe 
> for a UA to remove it (or never create it in the first place). Still, it 
> would indeed be good if this was expressed in the spec.

Indeed, especially since I don't see why the same reasoning couldn't 
then apply to <div/>, which is assuredly without content, margin, 
padding, border, etc in the absence of other styles.

> There is no reason for having the absolutely positioned div between the 
> other two divs, so I guess you could argue that there is no reason for 
> supporting such constructs. From an XML point of view, the two cases 
> would be different.

I don't see how the XML point of view matter here at all.  XML gets us 
as far as having a DOM.  CSS styles the DOM.  Once we have a DOM, the 
job of XML is done; the CSS behavior doesn't depend on whether the DOM 
came from parsing XML, parsing HTML, direct DOM manipulation, something 
like Gecko's fastload service (which deserializes a DOM directly from a 
binary representation), or the tooth fairy.

So yes, consider this a formal request to actually define the terms this 
section uses.  Right now, as someone trying to implement this section, I 
find that the only reasonable way to proceed is to try to 
reverse-engineer existing implementations, since the whole thing is so 
underdefined.

-Boris

Received on Tuesday, 10 March 2009 00:51:02 UTC