[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 #3 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> ---
(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. Thus,
it fits with the robustness principle, I think. 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? 

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.

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

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

That’s the fingerprints of Ian:

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

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

Received on Tuesday, 11 February 2014 19:25:56 UTC