W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > March 2010

[Bug 9355] New: Many, most, or all obsolete features should be conforming

From: <bugzilla@wiggum.w3.org>
Date: Sun, 28 Mar 2010 02:14:12 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-9355-2486@http.www.w3.org/Bugs/Public/>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9355

           Summary: Many, most, or all obsolete features should be
                    conforming
           Product: HTML WG
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: HTML5 spec proposals
        AssignedTo: dave.null@w3.org
        ReportedBy: Simetrical+w3cbug@gmail.com
         QAContact: public-html-bugzilla@w3.org
                CC: ian@hixie.ch, mike@w3.org, public-html@w3.org


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.

In many (if not most or all) cases, the feature is widely implemented and
clearly specified.  This means that there is generally no interoperability
concern.  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.  Since they are functionally equivalent, there can be
no actual user-visible effect from changing the non-conforming markup to be
conforming.

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>.  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.  All this makes some of the
non-conforming markup *more* attractive from an author standpoint.  (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.)

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

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.

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

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.

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.


-- 
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 Sunday, 28 March 2010 02:14:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 28 March 2010 02:14:26 GMT