Proposed requirement: don't break the Web

[ Although Dan's message asking for requirements [1] didn't
explicitly ask for requirements for things that already work, I'm
going to send a few (along with a few others).  I think there's
value in agreeing on what we want to keep working so that we
understand why we're not doing certain things. ]


Proposed requirement:
  New versions of HTML must not break significant numbers of Web
  pages.

This requirement may seem obvious, but it actually requires some
explanation.

Technically, any new feature will break some existing pages.  If we
add a new element called <datepicker>, we will change the
appearance, behavior, and semantics of existing pages on the Web
that have the string "<datepicker>" within them, which was
previously ignored.  This might seem silly, but with the number of
pages out there on the Web there is probably one somewhere that has
"<datepicker>" within it.  That alone shouldn't be enough to stop us
from adding the feature.

On the other hand, making the spec say that <h6> is a top-level
heading, <h5> goes under it, and <h1> is the lowest level heading,
because we think the most important headings should have bigger
numbers, is pretty clearly something that we shouldn't do.  It would
break Web pages all over the place that have worked interoperably
across many browsers for many years.

(These examples are both hypothetical; I don't intend to express any
opinions for or against anything about them.)

The interesting issues are not these; they're the ones in the
middle.  We need to judge whether the value of the new feature is
worth breaking what it will break.  Erring on the side of breaking
content will cause implementors not to implement the specification,
or at least not to be the first to implement the specification,
because they will fear losing users to implementations in which
fewer pages are broken.  (When users try switching Web browsers or
upgrade Web browsers, they really do switch back or switch to a
different browser because a page that's important to them doesn't
work right.  Sometimes even one broken page that they need to
complete financial transactions or to do their job is sufficient.)

This last part might be the most controversial.  When we consider
how seriously a new feature breaks existing content, I believe that:

 * We should take more seriously problems that are (or would be)
   reported by users than by authors, since the cost (to users, and
   thus to implementations, and in many cases also to authors) of
   breaking Web pages with many users is significantly higher than
   the cost of breaking Web pages with few users.

 * We should take more seriously breaking public Web pages than ones
   hidden on private networks, since we as a group have a better
   ability to understand problems that we can see than problems that
   are hidden from us.

 * We should take more seriously breaking Web pages that work on
   multiple browsers than Web pages that are browser-specific, since 
   our primary goal should be to design HTML as an interoperable
   document format for the Web, and browser-specific Web pages are
   not within that goal.

-David

[1] http://www.w3.org/mid/45F73583.4020508@w3.org

-- 
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation