* I recommend the editors that they close this bug as invalid.

* I recommend Mike to open separate bug where we can discuss whether @border is presentational markup. 

(In reply to Michael[tm] Smith from comment #0)

The related bug 24559 has been reopened because Mike currently has NU validator issue a warning. I would like to cite why I reopeed, as it goes directly on Mike’s claim that having @border is presentational markup.

(Citing Leif Halvard Silli in comment number eight in <https://www.w3.org/Bugs/Public/show_bug.cgi?id=24559#c8>:)

> I am sorry, but I have to reopen the bug. This because of the following:
> 
> The fix apparently is that NU validator instead issues a warning claiming
> that @border=1 is presentational markup. I don’t see that this is acceptable
> from the point of view of the change proposol that prevailed w.r.t to
> table=border=1. And I had already indicated that such a fix would not be
> acceptable:
> 
> (In reply to Leif Halvard Silli from comment #2)
> 
> > It must also be a vialotion of the spec to recommend authors to use CSS if
> > that implies to delete the border=1. 
> 
> By the way: I note that in the thread in www-validator@ you cited HTML5’s
> claim that all presentational markup has been removed as justification.
> However, from where I stand - and this was also put forward together with
> the change proposal - the <table> element has *two* defaults: One default
> when border is not present, and another default when border is present.
> Thus, I consider table@border=1 to be compatible with HTML5’s claim that it
> has removed all presentational markup.
> 
> If you disagree with this, then I expect you to file a bug against HTML5’s
> claim that all presentational markup has been removed.
> 
> You should also consider that the chairs, when the CP prevailed, said that
> it would also be possible to (re)consider the *other* table attributes -
> frame,rules,cellspacing,cellpadding. Personally I would have liked to see in
> particular @rules being conforming, as it is such a simple and poweverful
> way of - literally - highilighing the semantic lines of a table. Som from my
> standpoint, it was also a compromise - something I chose to live with - that
> I never has raised the issue of the other attributes. If you are adding this
> warning, then at least for myself, the compromise is no longer in balance.

To further fuel the editors with reason to dismiss this bug, I cite the following:

1) There was a change proposal to instantitate table@border=1
   Where is the new info that Mike provides?
2) This bug is just about theoretical purity.
3) The bug would open a can of worms:
   - What about type attribute on <ol>?
   - What about tables for presentational purposes?
     (”layout tables”). 

In fact, if we would like to avoid layout tables as much as possible, then should make @border a *required* attribute, since then, authors would have to take extra steps in order to make the borders disappaer. (Making @border required should have no effect on the permission to to use table@role=presentation.)

In fact, one could claim that the failure to make @border required is *the opposite* of what Mike claims! Namely, it represents a defacto ”caving in” to those who misuse HTML tables for presentational layout purposes. And in fact, that is exactly my view. As such, I consder Mike’s proposal a fallacy.

In conclusion, there logical and reasonable reasons, perfectly in line with the claim that HTML5 has removed presentational markup, to go in the opposite direction of what Mike claims, something I am quite ready to do. And there are practical reasons (think: consensus and compromise) to put the issue to rest.

For Polyglot Markup, I have filed a bug to make use of border="1" the recommended default, for authors and tools, see bug 24605.

I think Mike raises valid points here, and that we should go ahead with his proposal.

My only question is: can we just go ahead and make the change? There is a WG decision, but it seems at odds with what's actually in the spec so I am tempted to simply move ahead.

(In reply to Robin Berjon from comment #4)
> I think Mike raises valid points here, and that we should go ahead with his
> proposal.
> 
> My only question is: can we just go ahead and make the change? There is a WG
> decision, but it seems at odds with what's actually in the spec so I am
> tempted to simply move ahead.

"at odds with what's actually in the spec" can also mean that the specification does not correctly implement the decision.

Alternately, there may now be new information that should cause the decision to be revisited.  If so, I encourage that information to be presented as such.  For best results, the new information should address the use cases that motivated the decision and/or presents new information that validates the claim that "rendering table borders by default is compatible with the Web" and/or identifies changes in user agent behavior since the decision was made that materially affects the decision.

I ask, per bug 24636, that the border attribute is put back on the list of content attributes for <table> *immediately*. 

NOTE: @border is listed in the attribute index - <http://www.w3.org/html/wg/drafts/html/master/index.html#attributes-1> and the prose <http://www.w3.org/html/wg/drafts/html/master/tabular-data.html#attr-table-border>, but it fails to be listed amongst the content attribute - <http://www.w3.org/html/wg/drafts/html/master/tabular-data.html#the-table-element>.

The fact that Mike and Robin wanna discuss @border cannot justify that @border has fallen out of the list of the normative list of attributes that may be specified on the element.

Putting border back on the content attribute list immediately, as per the currently prevailing decision, would not affect Mike and Robin’s ability to provide the documentation that could eventually justify the change Mike asks for in this bug (bug 24591).

The same can be said about the NU validator (bug 24559). The NU validator is not allowed to issue even a warning (as it currently does) for content attributes.

I therefore expect that bug 24636 and bug 24559 can be solved quickly.

(In reply to Robin Berjon from comment #4)
> I think Mike raises valid points here, and that we should go ahead with his
> proposal.

Which valid points? Mike’s points starts with a untrue premise: 

«There's currently a bug in the W3C HTML5 spec which causes it to give the impression to Web authors that the table border attribute is valid when in fact it's not.»

It is the opposite that is the case: HTML5 evidently gave Mike the impression that border is unvalid, when it is in fact is valid.

Apparently, you are *dying* to comply with the WHATwg spec.

(In reply to Leif Halvard Silli from comment #7)
> 
> Apparently, you are *dying* to comply with the WHATwg spec.

Please tone down the rhetoric.

- Sam Ruby

The first report of the validator not accepting @border apparently came on the 5th of february: http://lists.w3.org/Archives/Public/www-validator/2014Feb/0005.html

At the very least per the 13th of January, @border was still listed as a content attribute: http://web.archive.org/web/20140113194820/http://www.w3.org/TR/html5/tabular-data.html

Since then it was silently removed from that list on both HTML5 and HTML51 - I don’t know in which commit.

But it places Mike’s first statement, that the spec ”give the impression to Web authors that the table border attribute is valid when in fact it's not”, in perspective.

Actually, for ”the trunk” - HTML 5.1 - it was Hixie that made table@border disappear. ANd it appears to have happened in his “giant clean-up of 2013“ on Nov 07, 2013: <https://github.com/w3c/html/commit/5f540174f5fde713e45b72c81e530fb5d964d2df>

Before that date, @border is in, starting with that date, @border is out.

Hixie stated in his commit message this: ”No normative changes.”
Thus, evidently, the omission of @border - a normative change - was an error.

The dog might be burried in the following commit message:
”W3C editorial note: Added several missing FORK markers, [...]”
So Hixie may have blundered w.r.t. to where he placed his new FORK markers.

So, I would once more expect the editors to fix Hixie’s mishap.
And to not use his mishap as pretext or evidence for anything.

(For HTML5.0, this error only appeared in mid-January.)

(In reply to Michael[tm] Smith from comment #0)

> "presentational markup has been removed from HTML in this version. This
> change should not come as a surprise; HTML4 deprecated presentational markup
> many years ago and provided a mode (HTML4 Transitional) to help authors move
> away from presentational markup; later, XHTML 1.1 went further and obsoleted
> those features altogether.
> 
> http://www.w3.org/html/wg/drafts/html/master/introduction.
> html#presentational-markup

Mike, having calmed down a little so that I can better read, two things:

1) Perhaps I should not trust my recollection of events in 2011 [yeah, I am really dragging my feet with regard to reopen this issue mentally and otherwise], but I have a very vivid memory that both Ian and Tab contributed rebuttals against table@border and that “just say no to presentational markup” was a central point in each rebutall. On their behalf, I a feel insulted that you think they did not bring this up.

2) Above you quote the Introduction section to HTML5. But not very accurately. Here are some details regarding ”1.10.1 Presentational markup” - emphasis is mine:
  a) Quote: ”This section is non-normative.”
  b) Quote: ”The __majority___ of presentational features from 
             previous versions of HTML are no longer allowed. ”

As for your quote, namely ”presentational markup has been removed from HTML in this version”, then this is not a description of a principle that has been followed but a description of an action that has been carried out. The *full* sentence goes: ”__For those reasons,__ presentational markup has been removed from HTML in this version.” This is of course a sentence I agree 100% with since, regardless of whether table@border is presentational or not, as the sentence does not say that __all__ presentational markup has been removed.

And what were ”those reaons” which lead HTML5 to remove presentational markup? Those were, says same section, these:

”The use of presentational elements leads to poorer accessibility”
”Higher cost of maintenance”
”Larger document sizes”

You tell me which of those apply for table@border.

The last sentence of this section of the spec is clearly compatible with table@border too - if you like, feel free to add table@border there:

”It is also worth noting that some elements that were previously presentational have been redefined in this specification to be media-independent: b, i, hr, s, small, and u.”

As https://www.w3.org/Bugs/Public/show_bug.cgi?id=24705 tracks what needs to be done for HTML 5.0, I'll comment here on what I feel should be done for HTML 5.1 and beyond.

Chair hat: OFF

For more than a decade, there has been an attempt to identify "presentational" markup and deprecate it in favor of CSS.  As near as I can tell, the reasons for this are that pages intended to be accessed by a browser are typically part of a site, and factoring the presentation to a separate file is good design.  Fair enough.

But browsers aren't the only user agents that consume HTML.  Syndication, e-books, and e-mail are other examples.  Even if these ultimately use the same rendering engine, the use cases are different.  After all, the deprecation being proposed here isn't due to the markup in question not being implemented interoperably -- in fact the HTML 5 specification requires that it be implemented.

Even on the web, use cases vary.  While google.com doesn't use @border, if you attempt to validate that page, you will find a bunch of related errors: http://validator.w3.org/check?uri=http%3A%2F%2Fwww.google.com%2F&charset=%28detect+automatically%29&doctype=Inline&group=0

My take is that the people who crafted that page understand their use case very very well.  My understanding is that they want that page to be self contained, and to be expressed in a minimum number of packets when compressed, and they have made their choices accordingly.

If you accept my premise that these authors know their use case very well, and despite this endorse that the W3C HTML specification disallow these usages, then the inevitable result is that the validators that match the spec are off less utility.

The validation results for google.com are a good example of this.  Amongst the 23 "errors" I see four clear problems: elements such as <p> and <div> being used as children of span, and <nobr> being used as a child of <div>.

It is a shame that this signal is lost in the noise.

(In reply to Sam Ruby from comment #12)

> The validation results for google.com are a good example of this.  Amongst
> the 23 "errors" I see four clear problems: elements such as <p> and <div>
> being used as children of span, and <nobr> being used as a child of <div>.

 PS: What Google serves validators & text browsers
     differs from what Web browsers get. 
PPS: Both versions contains some of the same, illegal
     features - such as <center>.

> For more than a decade, there has been an attempt to identify
> "presentational" markup and deprecate it in favor of CSS.  As near as I can
> tell, the reasons for this are that pages intended to be accessed by a
> browser are typically part of a site, and factoring the presentation to a
> separate file is good design.  Fair enough.

If we focus on table@border: 

Sam, if you propose to do what the spec has already done in order incorporate e.g. <u> (namely to add semantics to the feature), then HTML 5.1 has *already* done that: Per what HTML 5.1 (so far still) says, the table@border is not free of non-presentational semantics.

For example, per its specified semantics (and despite validator’s lack of signal a warning), it seems like an author error to use table@border if the table is *not* a data table. (Thus, the validator could perhaps whine if it saw <table role="presentation" border="1" >.)

> But browsers aren't the only user agents that consume HTML. 

Even if we limit the HTML5 for Web browsers versus other browsers, then at least Firefox, Blink and Webkit do send the signal to AT that any table that displays borders is a data table, see bug 24679 and bug 24678.

If we focus on the wide issue:

When it comes to the wider issue, and thus to other features, such as e.g. <center>, block elements as child of <span> and - relevant to table@border - table@rules and table@frame, then I believe I am very much on the side of making ”presentational” features conforming. However, what would that mean in practice? Would it mean to seek to narrow down their use cases and define their semantics as ”for this and that use case”? The alternative of permitting them without any usage rules, seems out of question to me.

(In reply to Leif Halvard Silli from comment #13)
> If we focus on the wide issue:
> 
> When it comes to the wider issue, and thus to other features, such as e.g.
> <center>, block elements as child of <span> and - relevant to table@border -
> table@rules and table@frame, then I believe I am very much on the side of
> making ”presentational” features conforming. However, what would that mean
> in practice? Would it mean to seek to narrow down their use cases and define
> their semantics as ”for this and that use case”? The alternative of
> permitting them without any usage rules, seems out of question to me.

I don't believe that rules should be created in a vacuum.  Instead we should start with a list of representative and/or high traffic sites and identify what markup is being intentionally used in ways that don't produce unexpected results and work to recognize such uses as valid.

<center> may no longer be in vogue, but it still works as advertised.  And clearly is still being actively used by companies that understand deeply what the web is and what their use case is.

By contrast, block elements expressed as if they were a child of of a <span> element don't end up that way in the DOM.

>>>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24705#c3
--- Revert deletion of table@border in commit 5f540174f5fde713e45b72c81e530fb5d964d2df ---

Status: Accepted
Change Description: Corrected a partial accidental deletion of the border definition caused by some recent editorial spec refactoring [1], and cherry-picked it into the CR branch.

    master: https://github.com/w3c/html/commit/ba951a06fd8eacad106afb24de35098d1a25b6c3
    CR: https://github.com/w3c/html/commit/ef86132cb20d5826db9708763bc32d95dc53785a

Rationale: 
Even if the border attribute becomes obsolete/invalid for 5.1 (per Bug 24591), this change at least keeps the spec internally consistent for the time being, and honors the current WG decision for 5.0.
<<<

As it is, this bug is formally invalid. What it suggests does not make sense, as in HTML5 <table@border> WAS conforming and IS considered conforming again.
It means that authors, i.e. those who implement and therefore test features in the REAL LIFE, decided that <table@border> is conforming NOT because of theoretical purity, but because it is *useful*(see what has been said as of now).
Problem: what has been achieved is only the first part of the task. Up until October 12th, 2013, @border was conforming according to W3 HTML5.1 WD too. I don't know when it dropped out of the permitted attributes in the Working Draft, but I have some hints:
 - It is still conforming for the latest Nightly Build
 - The prose in the Working Draft is exactly the same of the one for WHATWG HTML5 CR for <table>, so I suppose it was meant with the idea that @border were conforming. It must have been ""inadvertently"" changed together with HTML5, so after mid January.

@border has nothing to prove. Ever. It's exactly like other old and new elements and attributes that, though born as presentational, now fulfill a new and more logical purpose, that of readability. The fact is, even other elements/attributes from HTML4.01 and from the practice could have a purpose, but it has been decided that their scope wasn't that important to deserve a mention in the markup and could therefore be delegated to the presentational (i.e. CSS) layer. As Mr Silli said once, it was a matter of compromise.
<table@border> is in the compromise. Whoever wants it to be definitely deleted must not talk about abstract points like "conflict with other points of the spec", "origin as presentational feature and so on".
It's their turn now to demonstrate both:
 - that @border with its current syntax and meaning is not so widely implemented, and so that its obsolescence does not damage many authors.
 - that it doesn't fulfill any other purpose but presentation, in particular that it is not an aid to readability of ANY table (with particular regard to data tables and complex tables).
 - that all user agents/web clients can implement the VERY SAME level of readability/usability achieved by @border solely thanks to the CSS layer.
 - that no user agents DO, DID, PLAN TO or MAY use this feature in their internal heuristics in order to tell away data tables and non-data tables
 - that the addition of @border is therefore NOT ONLY unnecessary but also harmful, because it diminishes interoperability/maintainability of Web pages.
If anybody can demonstrate ALL these things TOGETHER, then they can raise a formal question to abolish it. As of now, @border is already child of a repeated positive choice and has nothing more to prove.

(In reply to Leif Halvard Silli from comment #10)
> Actually, for ”the trunk” - HTML 5.1 - it was Hixie that made table@border
> disappear. ANd it appears to have happened in his “giant clean-up of 2013“
> on Nov 07, 2013:
> <https://github.com/w3c/html/commit/5f540174f5fde713e45b72c81e530fb5d964d2df>
> 
> Before that date, @border is in, starting with that date, @border is out.
> 
> Hixie stated in his commit message this: ”No normative changes.”
> Thus, evidently, the omission of @border - a normative change - was an error.
> 
> The dog might be burried in the following commit message:
> ”W3C editorial note: Added several missing FORK markers, [...]”
> So Hixie may have blundered w.r.t. to where he placed his new FORK markers.
> 
> So, I would once more expect the editors to fix Hixie’s mishap.
> And to not use his mishap as pretext or evidence for anything.
> 
> (For HTML5.0, this error only appeared in mid-January.)

point of clarification.
Hixie does not commit to the w3c HTML spec. We have a WHATWG branch that is updated as hixie makes changes to his spec. The w3c editors cherry pick from those commits to apply to html 5.1/html5. Where the w3c.whatg specs differ we generally have markers to indicate a divergence to avoid overwriting intentional differences. What occurred was that during the cherry pick of a large commit the 'border text of the w3c spec got overwritten, a mistake on the w3c editors part. I believe this has now been corrected.

(In reply to steve faulkner from comment #16)

> point of clarification.
> Hixie does not commit to the w3c HTML spec. 
  [ ... snip ... ]  
> mistake on
> the w3c editors part. I believe this has now been corrected.

Thanks for background info. Can verify that the HTML 5.0 is correct now.

(In reply to Leif Halvard Silli from comment #17)
> (In reply to steve faulkner from comment #16)


> [...] Can verify that the HTML 5.0 is correct now.

Ah, 5.1 is also fixed. Super. Did not realize that ... Thanks for making me reread, Steve ...

(In reply to Sam Ruby from comment #14)
> (In reply to Leif Halvard Silli from comment #13)
> > If we focus on the wide issue:

> By contrast, block elements expressed as if they were a child of of a <span>
> element don't end up that way in the DOM.

Not so fast. That is true *only* when <p> is not the parent *and* the page is *not* in quirks-mode.

  True: <!DOCTYPE HTML>
        <p><span><div>
           The div gets spit out of the p element
        </div></span></p>

  False: <!--<!DOCTYPE HTML>-->
        <p><span><div>
           The div gets spit out of the p element
        </div></span></p>

  False: <!DOCTYPE HTML>
        <div><span><div>
          The div does *not* get spit out of the p element
        </div></span></div>

  False: <!DOCTYPE HTML>
        <p><object><div>
          The div does *not* get spit out of the p element
        </div></object></p>

So, basically, it is only for <p> that what you say about ”block being spit out of span in the DOM” is (mostly) true. In fact, I remember Hixie providing the tip sometime that one could wrap block element sin span ...  (Must have been in 2007.)

(In reply to Leif Halvard Silli from comment #19)
> (In reply to Sam Ruby from comment #14)
> > (In reply to Leif Halvard Silli from comment #13)
> > > If we focus on the wide issue:
> 
> > By contrast, block elements expressed as if they were a child of of a <span>
> > element don't end up that way in the DOM.
> 
> Not so fast. That is true *only* when <p> is not the parent *and* the page
> is *not* in quirks-mode.
> 
>   [snip]
> 
> So, basically, it is only for <p> that what you say about ”block being spit
> out of span in the DOM” is (mostly) true. In fact, I remember Hixie
> providing the tip sometime that one could wrap block element sin span ... 
> (Must have been in 2007.)

Fair enough.  While that changes my specific recommendation, that actually strengthens my overall recommendation, namely that if people are en-mass ignoring restrictions in the specification, but are doing so in ways that are effective and interoperable, then the restrictions should be lifted.  To do otherwise reduces the utility of both the specification and any validators based on the specification.

See also:  http://www.w3.org/TR/html-design-principles/ (specifically: Support Existing Content, Pave the Cowpaths, and Priority of Constituencies).

(In reply to Sam Ruby from comment #20)
> (In reply to Leif Halvard Silli from comment #19)

> Fair enough.

(I made an error: <p> in quirks only accepts <table> - and not any block element. Could be I made other errors too.)

Will study what Google.com uses div-inside-span for. Probably for browsers without enough CSS support.

Another Google example of ”wrong” use is how Google Docs exports documents as quirks-mode HTML pages (without DOCTYPE) and with both cellpadding="0", cellspacing="0", and probably other things.

>  While that changes my specific recommendation, that actually
> strengthens my overall recommendation, namely that if people are en-mass
> ignoring restrictions in the specification, but are doing so in ways that
> are effective and interoperable, then the restrictions should be lifted.  To
> do otherwise reduces the utility of both the specification and any
> validators based on the specification.
> 
> See also:  http://www.w3.org/TR/html-design-principles/ (specifically:
> Support Existing Content, Pave the Cowpaths, and Priority of Constituencies).

Some would probably place Google in the category of ”über authors” and say that authors should not be bothered with all those options that the “über authors” can identify. 

May be, as a first step, the spec could start with, somehow, acknowledging the different uses of HTML - that there exists cases where authors would like to solve things different from how things are usually solved in a typical Web page that is part of a typical Web site.

The problem with this could be that the spec, somehow, can be seen as ”versioned”, again.

The alternative to that approach (and one would perhaps have to do this, anyhow), would be to try to go the route of ”semantisizing” those features that one like to see as conforming. Thus, to define when and how they can be used. Again, this is the approach the spec has followed, till now, I think. May be there should the be a project for the whole thing, a kind of ”papa bug” for the project. And the name of the project should probably be something like ”project to allow as many obsolete and illegal features as possible, provided they are actually used and make sense, at least in some contexts”. For such a papa project, I already have some babies ...

I would like to add that I do disagree with Mike’s outset for this bug - namely the message about CSS:

 1) We ought to be past that point were we need to ”drive home” the message about using CSS rather than formatting directly on the element.

  a) Because everyone and their cat have gotten that message - e.g.
     those that ”sin” by using e.g. border=1 (if you view that as a
     presentational feature) also use lots of CSS. Google does,
     as well, both in google.com and Google Docs.
  b) Because the presence of the @style attribute is a conforming
     loop hole that allows you to specify things on the very element
     anyhow (except that using @style often is often more cumbersome
      - e.g. try to replicate table@border=1 by the use of @style!)
     And, in fact, I have seen some HTML5-capable WYSIWYG editors/generators
     which places inside @style what they used to place in attributes - 
     the result is the same, the method is (slightly) different, with 
     the negative effect - sometimes - that semantical info is removed.

 2) To look squarely at a HTML feature with the aim of removing ”presentational hints”, without regard for whether the HTML feature is complex or simple, is flawed logic. Claim: Complex HTML features require attributes. For SVG, there is no proposal, I think, to replace attributes with CSS. SVG is of course often complex, so it might be easy to accept. But even HTML features can be complex. And so, when the use of complex HTML features can be simplified by replacing CSS with a feature that is (both) a presentational (*and* sometimes also a semantic) hint, then why discourage its use.

I am the reporter for this bug but it's not important enough to me to keep open any longer.