Re: HDP: Revised "Support Existing Content" Principle

In the telecon on Thursday I was tasked with following up on this.

On Sep 26, 2007, at 23:11, Gregory J. Rosmaita wrote:

> i've waited, as you asked, to address this issue again, but i'm deeply
> concerned that unless specific markup,  which was added to HTML4x  
> for a
> very specific purpose, is explicitly mentioned in "Support Existing
> Content", it won't be supported --

The Support Existing Content principle is about continuing to support  
content that has already been deployed on the Web. Your use of the  
future tense implies that you either
  1) are concerned that user agents would remove existing features
or
  2) are actually talking about features that pre-exist in specs but  
that user agents have not implemented.

I wouldn't worry about #1. It isn't in the character of UA vendors to  
remove features if doing so would cause the UA to lose market share  
or create a disincentive for the users of the previous version to  
upgrade. If this WG tells UA vendors to remove a feature that  
existing content that users care about depends on, UA vendors are  
likely to consider the WG crazy and ignore such demands. (If an UA  
vendor can remove a feature without the adverse effects that UA  
vendors are known to avoid, it means that the feature doesn't have  
actual significance in deployed content on the Web, in which case I  
wouldn't worry about removal.)

#2 is not at all what Support Existing Content is about. Support  
Existing Content isn't about adding support for latent markup in  
existing content or for features of previous specs that have failed  
to get implemented. (In fact, sometimes supporting existing content  
requires *not* implementing support for latent markup features that  
authors in practice expect browsers to ignore. Moreover, including  
unimplemented features from previous specs, HTML 4.01 in particular,  
in an anti-principle.) Support Existing Content is about avoiding  
requirement that would (if followed) cause existing content that used  
to work in old user agents no longer work in new user agents.

> i am working on the assumption that
> eventually the "Support Existing Content" principle will be  
> expressed in
> the HTML5 draft as "UA Conformance Requirements" and "AU Conformance
> Requirements"; is this a fallacious assumption?

I don't know what AU means in this context. (It doesn't look like a  
typo of UA in this case considering the immediate earlier part of the  
sentence.)

Yes, the Support Existing Content principle constrains what kind of  
requirements the spec can place on conforming user agents.

> when exactly will specific language concerning specific markup  
> expressly
> designed for accessibility, internationalization, and device  
> independence
> be addressed?  could it not be introduced into the draft, since it  
> is a
> draft?

That question presupposes that the design principles should have  
specific language about markup expressly designed for those purposes  
as opposed to making it a principle that those purposes need to be  
addressed somehow--perhaps not with markup solely for one of those  
purposes.

Other considerations being equal, it is a better idea to have built- 
in accessibility, device-independence and internationalization in  
features instead of having add-on markup specifically for those  
purposes, which is why I wouldn't make it a principle that those  
purposes need specific markup. Of course, other consideration rarely  
are equal, so I wouldn't rule out ARIA, which is specific add-on  
markup, on the level of principles, either.

> here is my proposed text again:
>
> "Browsers should retain support for residual/legacy markup designed  
> for
> a specific purpose, such as accessibility. internationalization or  
> device
> independence.

Your formulation isn't a formulation for a principle concerning spec  
design. The formulation is a requirement on browsers.

> Simply because new technologies and superior mechanisms
> have been identified, not all of them have been implemented. Moreover,
> disabled users are more likely to be users of "legacy technology"  
> because
> it is the only technology that interacts correctly with third-party
> assistive technologies."

That suggests that your concern isn't about supporting existing  
content but about keeping authoring practices that target legacy  
assistive technology conforming. The closest principle it falls under  
is Degrade Gracefully.

In case Degrade Gracefully doesn't fully capture the concern, a new  
principle could be formulated:

| Keep Authoring for Existing Assistive Technology Conforming
|
| If the specification introduces a new way to address accessibility  
use cases so
| that the new way addresses use cases covered by an earlier  
mechanism that has already
| been implemented in assistive technology and is in active use,  
markup targeted at the
| earlier mechanism should be made conforming for the purpose of  
document conformance.

Now, this is needlessly accessibility-specific. A few days ago, I  
posted to the list about <map name='foo'> and usemap='#foo'. They  
aren't accessibility-specific, but the similar sentiment applies.  
Here's a more general formulation:

| Keep Authoring for Existing User Agents Conforming
|
| If the specification introduces a new way to address use cases so  
that the
| new way addresses use cases covered by an earlier mechanism that  
has already
| been implemented in user agents and is in active use, markup  
targeted at the
| earlier mechanism should be made conforming for the purpose of  
document
| conformance.

I expect this formulation to be controversial, because it is common  
for people to want to use the concept of document conformance as a  
platform for denouncing existing and interoperably implemented  
features that they consider bad. (Consider how often people want to  
"deprecate" something.)

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Sunday, 21 October 2007 15:02:23 UTC