I didn't know about <http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#conformance-requirements-for-authors> when I wrote this bug.  I don't have time to read it this second, but I will do so and amend this bug when I can.  For the time being, Ian can ignore this bug or mark it NEEDSINFO or something, if he gets to it before I can update it.

After discussing with Maciej on IRC, I changed this bug to only request that presentational markup be made conforming.  I believe that comment #0 applies more or less verbatim, if you interpret it as applying only to presentational markup.

There are three points given to justify the prohibition of presentational markup: <http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#presentational-markup>.  However, all three apply equally well or better to inline style="":

* "The use of presentational elements leads to poorer accessibility": It would be more correct to say "The use of non-semantic markup leads to poorer accessibility."  This is absolutely true -- however, it applies just as much to style="" as to other presentational markup.
* "Higher cost of maintenance": Inline style costs just as much to maintain as other presentational markup.  Indeed, in some cases it costs a lot more.  A style=""-based equivalent to <table cellpadding=n> would be much more cumbersome, since you'd have to add style to every cell.  (<style scoped> is not yet widely supported, so cannot be used here, but doesn't interact well with nested tables, etc.)
* "Higher document sizes": style="" is usually longer than equivalent non-style="" presentational markup.  E.g., compare <u> to <span style=text-decoration:underline>.

I cannot find any actual reason given in the spec for why nearly all presentational markup is banned when style="" is not.  I can think of reasons, like encouraging a uniform/consistent/easier-to-learn language, but they seem weak compared to the large cost of converting and maintaining documents that use such markup.  As I argue in comment #0, this will mostly serve to make validators less useful to authors, and will be a net loss according to the priority of constituencies.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: 

The reason for not having any presentational markup at all (modulo style="" and <style>, for which see below) is simple: it is significantly easier to teach an absolute rule than a complicated one.

This is analogous to how wearing a car seat belt is required in many jurisdictions regardless of the speed of the vehicles involved. One is far more likely to be wearing one's seat belt when going at 60kph if one always has to wear one's seat belt, than if one only has to wear it when going faster than 30kph.

Similarly, with presentational markup, if we say "you can't use <font face=Courier> when it would be for marking up what is computer code and what isn't, because that would leave speech browsers in the cold, but you can use <font face=Times> or <font face=Helvetica> to decide on the style of the paragraphs because that doesn't have any semantic value", then people are far more likely to get really confused.

This would argue for removing style="" and <style> as well, as well as <div>, which is more or less only useful for styling. And indeed, an earlier version of the draft had neither style="" nor <div>. Unfortunately, the world is not a perfect place, and there are some use cases for which one needs an escape hatch. Sometimes one needs <div> to hang some styles on, sometimes one needs style="" to experiment with a solution when doing rapid application development. Similarly, <style> is sometimes needed to have a self-contained spec, because having people use data:text/css,... instead simply leads to harder-to-maintain documents. So we have them in the spec, but discourage authors from using them, but we can still pretend that there's a line, because they're CSS, and CSS is not HTML, and so hopefully it authors will do the right thing.

(If we had the "subdued errors" concept still, I would argue for having style="" and <div> flagged as such, but we no longer have that.)


Here are some replied to specific points made:

> The spec lists a lot of obsolete features:
> 
> <http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html#obsolete>
> 
> Some of them are singled out to be obsolete but conforming, but the large
> majority of them are non-conforming.  I have seen no clear reason for the
> distinction.

The ones that are obsolete but conforming are the ones that are extremely common in legacy pages but have no effect, and so are harmless.


> Moreover, in many cases -- e.g., most of the obsolete presentational
> markup -- the non-conforming markup is defined to be canonically equivalent to
> some conforming markup.

I don't think there are any cases where a canonical equivalent is provided; the spec is just giving suggestions of alternatives that might be more appropriate.


> In fact, in a lot of cases the non-conforming markup is significantly simpler
> or shorter than the conforming markup.  For instance, compare <u> to <span
> style=text-decoration:underline>.

Both would be inappropriate. Neither convey any useful semantic. How should the span be rendered on a braille display or in speech synthesis or on a text display with no underline capability?


> There can be other benefits too -- once when
> I changed <table border="x"> to use CSS, a user complained that this degraded
> display in his text-based non-CSS browser.

That's presumably a bug in the text-based non-CSS browser, though it's hard to tell without specifics.


> All this makes some of the
> non-conforming markup *more* attractive from an author standpoint.

I think that's rather a stretch. "All this" is just two arguments ("it's shorter than using something equally bad" and "it can be more compatible with text browsers"), neither of which are at all compelling.


> (In some
> cases, using stylesheets rather than inline markup would be easier; but if this
> is a reason to ban presentational markup entirely, we need to ban style=""
> too.)

We more or less do — the spec says "Documents that use style attributes on any of their elements must still be comprehensible and usable if those attributes were removed" and "using the style attribute to ... convey meaning that is otherwise not included in the document, is non-conforming". I'd love to go further, but it's not realistic to do so.


> In all cases, presumably there are a significant number of pages/apps using the
> feature (else it wouldn't need to be specced).  If the maintainers of these
> pages/apps would like their markup to be conforming, they would have to expend
> significant effort to convert the markup, which would provide literally zero
> user-visible benefit (see previous two paragraphs).

If it's conforming today, then they need do nothing.


> Many authors will be unwilling to do this.  They will feel that they're being
> asked to make arbitrary changes to their page markup, which will make the HTML
> source uglier and less maintainable, and risk introducing bugs, for no
> user-visible benefit.

There is ample user-visible benefit to having a page use CSS and semantic markup rather than presentational markup, tables for layout, and so forth. Pages are more accessible in media not tested by the author, such as speech synthesis, ATs, handheld devices, braille displays, etc. Pages get smaller and load faster. Pages are likely to be more consistent throughout a site. Pages are easier to remix.


> Validators that ban features merely because they're superseded (rather than
> because they're actually harmful) will be less practically useful due to a
> lower signal-to-noise ratio. 

Agreed, but that's not what's going on with presentational markup.


> This will make authors less likely to actually
> use them, so they'll miss out on practically relevant error messages, which
> highlight things like author mistakes or potential interoperability problems.

HTML5 has made huge strides in making pointless errors not be errors, for example extending the syntax to allow /> on void elements, allowing IDs to start with numbers, allowing <embed>, etc.


> In short, the current total ban on obsolete features places theoretical purity
> above the real-world interests of authors, and therefore violates the priority
> of constituencies. I would suggest that all obsolete features be made obsolete
> but conforming, except if they're completely useless for all practical purposes
> (e.g., <html version="">), or if there are other good reasons for authors to
> *never* or virtually never want to use them.

All the non-conforming features have good reasons for authors to never use them. Some are clear (e.g. don't use <table> for layout purposes because that leads to a poor accessibility experience), some are less obvious (e.g. don't use <u> because it implies a semantic meaning that is not conveyed in a fashion that users of non-visual UAs can easily determine), some are quite obscure (e.g. don't use standby="" on <object>, because it encourages using resources that don't have incremental loading and thus results in a worse experience for users).


> On a real-world note, MediaWiki/Wikipedia are among the apps/sites that are
> unlikely to ever be consistently conformant HTML5 if features are banned merely
> because they're obsolete.

MediaWiki's use of a presentational wiki language also leads to a poorer experience in non-visual media. It will always be difficult to convert from a mostly non-semantic language to a mostly semantic language, but I don't know what we can do about that. Making HTML into a non-semantic language isn't a solution, it's just propagating the problem further.

Okay, after our discussion last night in #whatwg, I'll call this CLOSED.  If it were up to me, I'd make it only warnings, but my opinion is now weak enough that I don't feel the need to pursue it.