Re: [CSS21] Concern about anonymous table objects and whitespace

Bert Bos wrote:
> On looking at it it again, I think we made the wrong decision by adding 
> this rule. We actually don't need it. If 'white-space' is 'pre', you 
> don't wan't the space to disappear; and if space is being collapsed, 
> you still need to keep the spaces between words, as the example below 
> shows.

OK, but then what happens with this HTML markup?

   <pre>
     <table>
       <tr>
         <td>Some text</td>
       </tr>
     </table>
   </pre>

Without this rule, the required rendering would be equivalent to this 
markup:

   <pre>
     <table><tbody><tr><td>
       </td></tr><tr><td>
         </td><td>Some text</td><td>
       </td></tr><tr><td>
     </tr></tr></tbody></table>
   </pre>

which is NOT what any UA actually does, nor what any UA wants to do.


>> Is there a space between the "AAA" and "BBB" or not?
> 
> We certainly *want* there to be a space...

Perhaps so.  There is one in Opera but not in Safari or Firefox, for 
what it's worth...

> The way I would process this example is as follows:
> 
> We see the DIV and open a table row box.
> 
> Next we see some white space. We are not preserving white space, so it 
> is not contributing any content; it's just mark-up to separate words 
> and as we haven't seen any words yet, we can simply ignore it.

Uh, no.  First of all, having the behavior depend on the white-space 
value is not acceptable; see above and earlier in this thread.  Second, 
I don't think we need English-centric concepts like "separate words" 
here.  I carefully wrote the text in such a way that the whitespace is 
between tags, not words.  If the language were Chinese, it would be 
separating nothing, but simply providing a way to organize the markup 
for better readability inthe file.

In any case, the current rules do in fact require that the box the text 
generates, if any, be wrapped in some other boxes as specified in this 
algorithm.  The question is whether the text generates a box at all.

> The SPAN itself poses no particular problem, but at the end we encounter 
> white space again. We are still not preserving spaces, but we did just 
> see some inline stuff, so this white space marks the end of a word.

See above.  This argument doesn't hold, in my opinion.

> We don't know yet if it adds a word space to the rendering; that depends 
> on whether there is anything more.

This introduces issues with lookahead similar to what I just posted 
about, no?

> If, as in the original example at the start of this thread, you 
> set 'white-space: pre' on the DIV or an ancestor, then white space in 
> the source doesn't serve as mark-up to separate words, but constitutes 
> text of its own. In that case there will still be one anonymous table 
> cell in the table row, but it will contain some additional, anonymous, 
> inline elements before, after and in between the two SPANs.

Not acceptable.  See above.

> The rules are meant to allow
> 
>     <ul style="display: table; width: 100%">
>       <li style="display: table-cell">item 1
>       <li style="display: table-cell">item 2
>       <li style="display: table-cell">item 3
>     </ul>
> 
> to render as
> 
>     +----------------+----------------+----------------+
>     | item 1         | item 2         | item 3         |
>     +----------------+----------------+----------------+

Yes, I know what the rules are meant to allow.  Unfortunately, they are 
not, as written, compatible with the way tables work in HTML.  That 
needs to be a higher priority than allowing the above.

Given the constraint of compatibility with HTML, the question is how 
much complexity the rules are willing to admit before we decide that 
this use case is not worth it.

> because, especially in XML, there are often not enough real elements and 
> you need anonymous ones to make tables. (This doesn't handle all cases 
> that you might want to turn into tables, you'll also need XSLT or the 
> Template Layout module, but it's still useful.)

I'm not saying it's not.  I'm questioning the ratio of usefulness to 
complexity.

Let me put numbers to this.  Nearly half of the code that constructs the 
box tree and manages dynamic updates of various sorts in Gecko exists 
solely to implement this one section of the specification.  It doesn't 
even do so correctly (e.g. it's disastrous at handling dynamic 
mutations).  Making it do that correctly will involve not just more 
complexity but additional performance penalties in some cases.  The code 
is ugly and sin and could probably be shorter and simpler, but this 
section is a _huge_ source of complexity in box tree construction.  And 
the spec isn't even correct; see above.

Is the use case really worth it?  Or would the other approaches you 
describe be better suited?  How common is the use case?

It seems to me that the feature was added as a "that would be cool" 
thing without really thinking through the implications (heck, the fact 
that it's not compatible with HTML shows that), and that no one ever di 
the sort of use case analysis that's nowadays part of, say, the HTML 
working group process...

> If I understand you correctly, you want the above to not render at all!

As a simple option, yes.

> We should no doubt have an easier way to center things vertically in 
> CSS3 ('block-foo-align: middle' or 'margin: stretch', see 
> http://www.w3.org/Style/CSS/Tracker/actions/18), but meanwhile people 
> use table cells.

Except table cell display types are not interoperably implemented in UAs 
(e.g. IE before IE8 last I checked), so they can't use them anyway.

>> Interoperability on this section is already quite poor, so making
>> this change might actually get us to CR faster.
> 
> The examples above actually work fine.

Yes, any simple example works fine.  Want me to write you some slightly 
more complicated ones that don't?  My very first attempt over here with 
"white-space:pre" wasn't interoperable between Opera, Gecko, and Webkit 
(Opera did one thing, the others did something else), to say nothing of IE.

In any case, I'm happy if the spec spells out exactly what simple cases 
we do want to support and EXACTLY how they should work, as long as this 
is compatible with how tables work in HTML.  But the current state of 
things is not acceptable.

-Boris

Received on Thursday, 22 January 2009 18:49:36 UTC