[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 #4 from David Carlisle <davidc@nag.co.uk> ---
(In reply to Leif Halvard Silli from comment #3)
> (In reply to David Carlisle from comment #2)
> > I think that this is far too far from the main aim of the polyglot spec of
> > XML/HTML compatibility, so I would argue that it should not be recommended
> > in this spec, even if I agreed with the recommendation.
> 
> 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 argument against
> *that* point could be that the Polyglot markup is not consequent enough. For
> instance, why not also recommend type="foo" of <ol> and stuff like that. To
> answer myself: May be we could simply have section discussing that very
> issue - “directly attached attributes”.
> 
> > However also in this case I don't think that the spec should be recommending
> > border.
> 
> Guess this equals to ”but I don’t agree with the recommendation”.
> 
> > > Any disagreement that that such highlighting often is beneficial has not been recorded. 
> >
> > There are many publishing guidelines which advise against vertical rules,
> > see for example 
> > 
> > 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.  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.

> 
> After all, it fails to discuss fallback styling and also fails to discuss
> whether whether vertical rules, after all, is better than dropping
> everything on the floor = no borders/rules at all, which is the alternative
> *you* eventually recommend.
> 
> Btw, that style guide also advices against double rules - which is the
> default border style in HTML, regardless of whether you use @border=1 or not.
> 

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.

> Border=1 only represents a default styling. Via CSS, you can create the
> styling the LaTeX guide suggests.
> 
> But please knock on my door if you think we should get back @rules= and
> @frame in HTML5 - then we can *really* very simple create tables that are
> more or less exactly as that LaTeX guide wants them, see:
> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2806
> 
> > 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. 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. 

> 
> > and (perhaps more
> > importantly here) it has a (slightly bizarre) interpretation in W3C HTML5
> 
> That’s the fingerprints of Ian:

The text is what it is, it's not relevant here where it came from.

> 
> >  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).

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

Received on Tuesday, 11 February 2014 21:03:25 UTC