W3C home > Mailing lists > Public > public-html@w3.org > September 2007

Re: HDP: Revised "Support Existing Content" Principle

From: Sander Tekelenburg <st@isoc.nl>
Date: Sat, 22 Sep 2007 03:20:35 +0200
Message-Id: <p06240608c31a0bca31ec@[]>
To: <public-html@w3.org>

At 18:58 -0700 UTC, on 2007-09-17, Maciej Stachowiak wrote:

> On Sep 17, 2007, at 6:21 PM, Marghanita da Cruz wrote:
>> To me, handling of poor markup by browsers is an example of
>> the "Degrade Gracefully" Principle rather than the
>> support existing content principle.
> That's not the intent of the principle.

If I could get a penny for every time someone said "that's not the intent of
that Design Principle"... I'd have at least a dollar by now ;)

> "Degrade Gracefully" says
> nothing about the interaction of existing markup with either new or
> old browsers. It's all about new documents authored to conform to
> HTML5 being able to work reasonably in pre-HTML5 browsers.

Indeed, the first sentence says "This principle applies primarily to the
conforming language." But it's the name of a Design Principle that sticks, so
it needs to be descriptive. Might not "Aim to be backwards compatible" ("as
in "HTML5 aims to be as backwards compatible with HTML 4 as possible") be a
more descriptive name for this principle?

Btw, the <canvas>, <video>,<audio> example at the end of
says that HTML5 UAs "*will* show the multimedia content" [emphasis mine].
Surely "may present the multimedia content" is more appropriate? (A HTML5 UA
may allow users to ignore such content, or may not be capable of "showing"

That same exampe also strongly suggests that the content of those elements
are not multimedia -- while the current version of the spec, and most
proponents' comments so far, suggest that these elements represent a
multimedia object, period; that their content is to be a pre-HTML5 method to
represent the same multimedia. (In other words "<video><embed></video>", good
-- "<video><div>extensive textual equivalent</div></video>" -- bad.)

If I misunderstand something here, please set me straight. Otherwise,
although it may be useful to have examples in the Design Principles, let's be
very careful that they don't get us 'stuck' further along the road. (I
believe Robert Burns said somethingsimilar recently.) They should remain
Design *Principles*, not suggest that any decision on any specific thing in
the current HTML5 spec has been made. (Yes, I do realise that WHATWG members
have been working on the current spec for a couple of years and that in their
minds, understandably, some decisions have been made. Still, that's just not
a station the HTML WG has arrived at yet. Let the Principles be principles.)


>> As I see it, Support existing content refers to features that may have
>> been in HTML3.2 or 4.01 or XHTML etc. specifications but
>> have been dropped in later ones.
> The intent of "Support Existing Content" is that it's about actual
> existing *content*, not existing specifications.

Yeah, this seems pretty clear to me. A language feature is not content.
Content is what is 'out there' on the World Wilde West. However, there, the
first sentence, "This principle applies primarily to the supported
language.", points exactly in the direction it takes Marghanita. It speaks
about "language", not "content". I think it's safe to remove the sentence.
The rest of the text seems pretty clear, to me.

Btw, I actually take issue with "Does the dependent content currently work as
intended in multiple popular user agents, rather than explicitly targeting
only one particular user agent, or only very old or otherwise unpopular
ones?" IMO this really needs to be removed. When people author @lang, @type,
@hreflang, @alt, @longdesc, <link>, <label>, @rel, <q>, @headers, <fieldset>,
<legend> etc. as intended by a previous spec, then they're not targeting any
particular UA, old or non-popular. They're targeting *users*.

If this is meant to refer to non-HTML (as in "proprietary stuff"), it should
say so. In that case I'd probably agree with it.


Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>
Received on Saturday, 22 September 2007 01:20:52 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:22 UTC