[Bug 9355] Obsolete presentational markup should be conforming

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9355


Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX




--- Comment #3 from Ian 'Hixie' Hickson <ian@hixie.ch>  2010-04-02 07:56:33 ---
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.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 2 April 2010 07:56:35 UTC