(In reply to Leif Halvard Silli from comment #0)

> 1) However, with @border=1 present, there is a better fallback & survival
> story in UAs. Without @border=1, if the CSS to highlight columns and rows
> were to disappear or, if the UA did not support CSS, usability would become
> worse than necessary.

Related to fallback & survival is WYSIWYG authoring in Web-based editors such as CKEditor and TinyMCE. For some reason, some editors of that kind default to not render borders. In that case, it is often too complicated for users of these editors (which are often tied up in a CMS) to add border via CSS. Adding a @border attribute is a simple workaround.

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.

However also in this case I don't think that the spec should be recommending border.

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


Also border is classed as invalid in whatwg html 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.

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

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

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

(In reply to David Carlisle from comment #4)
> (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.

I don't recognize the argument that is being attributed to me, but in any case, I agree that this is not the place to make recommendations that go beyond the scope of making documents that work equally as well in both XML and HTML contexts.

HTML5 and HTML 5.1 should take a position on whether the border attribute is recommended, valid, or invalid, and polyglot should follow.  Either that or there should be a separate extension specification for the boarder attribute.

I recoginize that Mike is trying to overturn a previous WG decision -- I'll stay out of that discussion until the editors have proposed a resolution:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24591

> So you are not satisfied with the robust direction.

A _very_ limited amount in that direction is just about acceptable to justify adding  few things that go beyond the theoretical minimum needed for XHTML/XML parsing compatibility, but any such additions severely weaken the justification for having this specification, and certainly if this recommendation of using border attribute were added then that would be strong reason for voting _not_ to progress this draft to REC status.



There are many toolchains for which it is very convenient (if not absolutely required) to use an xml parser on an "html" document, and for such situations the original polyglot spec was a potentially useful resource.

As it is becoming (and would definitely become if the proposed change were made) it is just becoming a personal hodgepodge "best practice" advice completely unrelated to the issue at hand.

Reasonable people may disagree on whether table/@border is a good idea, but why should they even be discussing it in the context of XML parser behaviour? If I (reasonably) want a document that parses as xml or html but doesn't have table borders, why put obstacles in the way by introducing these irrelevant constraints on what is or is not considered valid polyglot markup?

(In reply to David Carlisle from comment #7)
> > So you are not satisfied with the robust direction.
> 
> A _very_ limited amount in that direction is just about acceptable to
> justify adding  few things that go beyond the theoretical minimum needed for
> XHTML/XML parsing compatibility, but any such additions severely weaken the
> justification for having this specification, and certainly if this
> recommendation of using border attribute were added then that would be
> strong reason for voting _not_ to progress this draft to REC status.
   ....
> As it is becoming (and would definitely become if the proposed change were
> made) it is just becoming a personal hodgepodge "best practice" advice
> completely unrelated to the issue at hand.

Dawit, 

I understand the problem you are taking up. And of course I have been having similar thougths. It is even expressed in this bug.

If there are other places were you see ”hodgepode”, please tell.

David, sorry for the misspelling of your name - I have a friend whose variant of your name is spelt like that ...