[Bug 24605] Make the use of <table border="1"> RECOMMENDED default in polyglot/robust documents and tools

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24605

--- Comment #5 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> ---
(In reply to David Carlisle from comment #4)
> (In reply to Leif Halvard Silli from comment #3)

> > Understand what you say. At the same time, Sam has been making the argument,
> > repeatedly, that attributes directly on element are more robust than CSS.
> 
> There are places to make that argument (which actually I don't disagree with)
> but not in this spec.
> 
> > Thus, it fits with the robustness principle, I think. 
> 
> The whole addition of this "robustness" part of the polyglot spec weakens
> its purpose. The original purpose was a useful focussed specification on
> joint XML/HTML use. If you want to turn it into just 1 of 1000001 style
> guides on general HTML good practice, I really don't see the point of it
> being a REC or at the W3C.

One change that happened after the poll was that Eliot pointed out that there
were not definition of ”robust”. And so we added a definition before it went to
CR. And the ability to serve/consume a document as both XML and HTML was
included in the robustness concept of the spec.

> > > http://anorien.csc.warwick.ac.uk/mirrors/CTAN/macros/latex/contrib/booktabs/
> > > booktabs.pdf
> > > 
> > > section 2: 
> > > You will not go far wrong if you remember two simple guidelines at all times:
> > > 1. Never, ever use vertical rules.
> > 
> > How is that style guide relevant?  
> 
> It is a direct response to your statement that there is no disagreement to
> the use of borders and/or stripes. There are many style guides advising to
> keep table ornaments to a minimum, that was just one I had to hand.

I don’t disagree with keeping styling of tables to a minimum. It is just that
in some user agents (and UA ”modes”), there is only a on-or-off. Either borders
on all four borders of each cell. Or no borders at all.

W.r.t. the style guide, then it starts by displaying a table ”from the LATEX
manual (p. 64 old edition)”, where the guide identifies one cell that is
semantically unclear: ”(but is the emu stuffed or not?)“. If this had been a
HTML table, then, for a table with border="1" (and no CSS to overrule its
effect), it would have become perfectly clear whether or not that emu was
stuffed. So we can’t really compare LaTeX and HTML - they have different
problems to cope with.

I perceive the style guide to be very occupied with clarity. And that is also
my focus.

Zebra stripes probably have their problems too, but I perceive it as a variant
of what that style guide recommends: Horizontal lines.

A text only Web browser is pretty much like a print medium - thus, we are
nearing ”LaTeX land”. Except that it is impossible to fine-tune the output as
much as in LaTex - or in CSS-enabled UAS. Again, it tends to be all borders or
no borders.

>  But the
> whole area is about typographic design and web accessibility and the
> polyglot spec isn't the place to discuss either of those things.

Fair enough.

> Quite. There are multiple issues related to typography and art and
> accessibility and it is so far removed from the technicalities of
> differences between the XML and HTML parsers I can't imagine why you would
> want to put them in the same spec.

So you are not satisfied with the robust direction.

> > > Also border is classed as invalid in whatwg html
> > 
> > 1) That’s a remark about @border=1 - as opposed to “borders”. 
> > 2) Of course we can’t consider Whatwg - the players in WHATwg
> >    took part in the decision process, but Ian chose to 
> >    ignore the decision. (Still he managed to place his own
> >    interpretation of border=1 into ”our” spec - HTML5.)
> 
> Of course it is relevant if you are justifying this addition on a principle
> of "robustness" in the face of differing implementations.

If you meant «conforming whether validated as WhatWG HTML or as HTMLwg HTML”,
then of course. But that is not the definition of robustness that the spec
operates with.

> Whatever you think
> of WhatWG process, it is safe to assume that some implementations (and
> validators) will be based on that spec. So going out of your way to
> recommend to end users that they use markup that will be flagged as invalid
> in some implementations seems a less than robust approach. 

WHATWG spec supports border in that it requires GUI UAs to have CSS for it. So
there really is no robustness issue that way.

> > > and (perhaps more
> > > importantly here) it has a (slightly bizarre) interpretation in W3C HTML5

> > >  The border attribute may be specified on a table element to explicitly
> > > indicate that the table element is not being used for layout purposes. If
> > > specified, the attribute's value must either be the empty string or the
> > > value "1". The attribute is used by certain user agents as an indication
> > > that borders should be drawn around cells of the table.
> > >
> > > The polyglot spec can't change the interpretation of border given by the
> > > html spec(s). So as specified, far from being a robust way to achieve
> > > borders, it is a hint that may be used by some agents as an indication that
> > > borders should be drawn.
> > 
> > David, first, I am quite positive w.r.t. updating the HTMl5 specification
> > about @border. That being said, it is not completely clear to me what you
> > are saying. The effect of using @border is defined in the styling section of
> > HTML5 - the section that tells how desktop GUI clients should render
> > elements by default. Thus, the wording ”used by certain user agents” does
> > not meant that ”not used by all the non-certain”. Rather it means that
> > certain agents use @borders - and nothing else - to create borders.
> 
> I don't see any way it can be read as meaning that. It means what it says.
> (If you don't think it should say that you should raise a bug on the HTML5
> spec).

Whether I fully I agree, I guess I will file that bug.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 11 February 2014 23:23:02 UTC