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

Bert Bos wrote:
> 9.2.2.1 says that white space in the source doesn't generate anonymous 
> inline boxes if those spaces would be collapsed away.
...
> So I retract that we don't need a rule. We do need to say something 
> similar to 9.2.2.1 for collapseable spaces

For tables, it needs to happen for non-collapseable spaces too, as I've 
said at least 3 times in this thread now.

> And then remove rule 4½. I think that covers all cases.

Except actually being able to implement the behavior of 
<table>/<tr>/<td> in HTML with this setup, sure.  Not a use case we 
apparently want to cater, to.

> It's not valid HTML

Fine.  Put a style="white-space:pre" on the <body> and remove the <pre> 
altogether if you prefer, to make it valid.  Then observe that the way 
its currently rendered is interoperable in all browsers going back to 
about Netscape 3 and is NOT what the CSS spec requires happen.

As in, address the point, don't dodge it.

> so what UAs "should" do is not defined. (Depending 
> on circumstances, they could, e.g., close the PRE before the TABLE, do 
> as if the TABLE, TR and TD tags weren't there, or show a box that 
> says "error!" My own software does the first. The validator suggests 
> generating a BUTTON element around the TABLE. Tidy removes the <pre> 
> tag and reinserts it after the table. It's hard to tell what browsers 
> do from looking at the rendering.)

I can tell you what Gecko does: it puts the table inside the <pre>.  So 
does Opera.  So does Safari.  So does IE.  Heck, here's a testcase you 
can use to check this:

data:text/html,<body 
onload="alert(document.getElementById('p').firstChild.nodeName)"><pre 
id='p'><table><tr><td>Text</td></tr></table></pre>

> (Also the uses cases for applying 'white-space: pre' to a table seem 
> rather contrived.

It's typically applied to an ancestor, not to the table itself.

> If something reasonable falls out of the definition, 
> that would be nice, but if not, I don't think that's a problem, as long 
> as the case with 'white-space: normal' works as expected.)

Maybe I wasn't clear...  I'm not going to implement the spec text as 
written right now in the public draft, because then I couldn't ship the 
resulting browsing engine to actual users....

>     <pre>
>       <span style="display: table">
>         <span style="display: table-row">
>           <span style="display: table-cell">Some text</span>
>         </span>
>       </span>
>     </pre>
> 
> And let's also assume this is SGML (HTML), not XML. (That means, 
> concretely, that the ends of line on the 1st, 2nd, 3rd and 6th lines 
> are ignored.)

Let's not assume counterfactuals.  That's not how HTML is parsed in 
practice, nor will it be in the foreseeable future.  Browsers do NOT use 
an SGML parser, and you might as well admit that.  The end of line after 
the <pre> is ignored, indeed.  The others are not.  Not that it much 
affects your analysis, as it happens.

> Or with rules to show the structure of the table more clearly:
> 
>     11
>    +------+---------+----+
>    |2222  |         |    |
>    +------+---------+----+
>    |333333|some text|4   |
>    |      |         |4444|
>    +------+---------+----+
>    |5     |         |    |
>    |55    |         |    |
>    +------+---------+----+
> 
> It seems Opera only partially implements the SGML rule for suppressing 
> newlines, so it has more newlines than expected (it only suppresses one 
> of the four, it seems), but otherwise it appears to be correct.

Note that Opera suppresses all the newlines in an actual <table>, 
though.  At least in the display; not sure about the DOM.  Also note 
that the HTML5 spec will pin down the parsing algorithm here, for what 
it's worth.

> Konqueror and Firefox seem to implement "rule 4½".

Sort of, yes.

>> Uh, no.  First of all, having the behavior depend on the white-space
>> value is not acceptable;
> 
> Isn't that what 'white-space' is *supposed* to do?

Yes, but in practice having that happen for whitespace in <table> in 
HTML is not compatible with the web.  I'm not saying that's a _good_ 
thing, just a fact of life.

> Chapter 16 describes it in more detail. There is no lookahead involved 
> in *parsing*, but when *rendering* a line you obviously need to 
> consider a whole line at once, if not a whole paragraph.

I'm talking about lookahead in the DOM when constructing the box tree, 
not parsing or rendering.

> The rules don't apply to HTML table elements. Or rather: they apply, but 
> their if-clauses are always false. They apply when there are missing 
> elements, which is never the case in HTML tables. Section 17.2.1 even 
> mentions this fact explicitly.

HTML table elements have spaces inside them, so the rules do in fact 
apply to them.

> Also, the rendering that some browsers used before CSS is not 
> reproduceable in the CSS model.

If rendering that _all_ browsers have is not reproducible with the CSS 
model, then I view that as a bug in the CSS model.

 > But for CSS 2.1 the working group decided that the state of current 
browsers is
> such that testing TABLE elements is not worth our time.

I'm happy to write tests that will not allow this section out of CR due 
to lack of interoperable implementations if that's the goal here...

> Section 17.2 says it like this: "User agents may ignore these 'display' property 
> values for HTML table elements, since HTML tables may be rendered using 
> other algorithms intended for backwards compatible rendering. However, 
> this is not meant to discourage the use of 'display: table' on other, 
> non-table elements in HTML."

That doesn't mean that this section is allowed to not be used if the 
display values _are_ used.  It's not hard to write tests in XHTML that 
indicate that they are in fact used, and that UAs do not in fact 
implement what this section currently requires.

> So for CSS 2.1 we'll need the example with UL/LI to work, but we won't 
> test any TABLE elements.

Define "work"?  My point is that UAs _are_ in fact using this for their 
HTML tables, and _are_ in fact imposing behavior they need for HTML 
tables on their implementation of this part of the spec.  So either the 
spec needs to adjust, or UAs need to stop using this section for their 
table rendering.  In my view, the former is a much better outcome, 
because otherwise it's simpler to drop support for this section 
altogether than to have two different-but-similar codepaths...

That doesn't seem like a desirable outcome.

> A rule we applied in the design was that content should always be 
> rendered (except when it was hidden with 'display: none', of course) 
> and so any strange sequence of 'display' values should yield a useful 
> result. That's why a 'block' inside an 'inline' isn't ignored, and 
> ditto for 'inline' inside 'table'.

I agree that this is a good rule, 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.
> 
> Many things don't work yet in some browser or other. And no style works 
> at all if you use Lynx.

That has nothing to do with the point I was making; might be worth 
rereading what I said there.  In any case, the point is moot, since 
there are in fact significant in-the-wild uses of this in spite of IE's 
lack of support.

> The CSS3 Table module will contain the legacy algorithm for computing 
> table widths. Few people will be able to check if it is correct, so if 
> you can help, that would be great.

I'm talking about breaking things up into cells so far.  The layout is a 
wholly different (and much more involved) kettle of fish, I agree. 
Let's stick to getting the box tree right for now.

-Boris

Received on Friday, 23 January 2009 20:37:52 UTC