Re: HDP: Revised "Support Existing Content" Principle

On Oct 24, 2007, at 23:55, Gregory J. Rosmaita wrote:

> who decides what constitutes implemented?

For a given product, the implementors of the product decided. Others  
can find out pretty objectively by running test cases.

> the top 3 or 4 UA vendors?

Defining what's implemented in general and not just in a particular  
product is fuzzier. But yeah, for finding out the implementation  
status of general-purpose HTML features, you should examine the  
latest versions of the top 4 browser engines. In the case where the  
top four engines don't all implement a given feature, determining if  
the feature is necessary from the Support Existing Content point of  
view requires human judgment.

For special-purpose features, you should probably examine the top  
browsing configurations that are used for the special purpose. For  
example, when examining what non-visual accessibility features are  
implemented, you should examine the top non-visual browsing  
configurations. Or in order to determine what are the dominant  
implementation quirks for bidi, you should probably give more weight  
to browsers that hold top market share in bidi locales as opposed to  
globally.

> existing content was added for a reason

Don't Break the Web morphed into Support Existing Content. The reason  
the principle is there is definitely to say that the spec shouldn't  
ask browsers to become incompatible with published Web content that  
they were previously compatible with.

> -- simply because browsers 
> A, B, C, and D, which predominate in market share, don't support an
> element or attribute doesn't mean that it has "failed in the
> marketplace" --

If the element or attribute was designed for browsers in general, was  
specified a decade ago and the top four browsers don't support it,  
then, yes, it means that the feature has utterly failed in the  
marketplace.

> the markup was added for a reason and ample instruction
> on its proper use is contained and well-integrated in the HTML 4.01
> TR itself, as well as the Web Content Accessibility Guidelines, the
> Authoring Tool Accessibility Guidelines, and the User Agent  
> Accessibility
> Guidelines, all of which are W3C technical recommendations...

Existing W3C technical recommendations have no direct bearing on  
Support Existing Content. Support Existing Content is about what  
browser features are needed in order to maintain support for existing  
content. Even though existing specs may have had an influence of what  
that feature set is, the Support Existing Content principle depends  
entirely on the actual practice out there and not on existing specs.

It is Support Existing Content. It isn't Import Existing Specs.

> i suppose not everyone has had the opportunity to read:
>
> http://esw.w3.org/topic/HTML/AccessibilityDependencies
>
> but they should...

I see the usual boiler plate advocacy followed by a link list. The  
link list doesn't explain the accessibility relevance of each list item.

I have read and understood the advocacy many times before. But no  
advocacy changes the past. Support Existing Content is about  
compatibility with content that has already been authored.

As an off-topic comment: I think it is not useful to list e.g. XPath  
2.0 as "capable of enhancing accessibility" without briefly  
explaining the concrete relevance of that particular node selection  
mechanism on accessibility. Should Selectors be on the list as well?  
Is a huge list that just communicates that everything maybe has  
something to do with accessibility a useful link list?

> and if support for specific markup is not part of "support existing
> content", then -- in your own formulation -- how is such markup, if
> deprecated, to be supported?

If such markup is needed for actual existing content, then it is  
covered by the principle. If there is specific markup that doesn't  
need to be supported by user agents in order to support existing  
content, there's no principle requiring the inclusion of such markup  
in the spec.

If you want to propose an "Import Existing Specs" principle, I  
suggest that you propose a new principle and let it stand or fall on  
its own right instead of trying to change the meaning of existing  
content to mean existing specs.

> you are not articulating a principle of
> support existing content, you are articulating a retroactive pruning
> of the HTML 4.01 Technical Recommendation under the guise of  
> supporting
> content that exists in the wild...

HTML 4.01 features that aren't needed in the wild are eligible for  
pruning, yes.

HTML5 development started with pruning the HTML feature set to the  
empty set. Then features that are needed for supporting content in  
the wild were added. Also new features were added.

Including old spec features that aren't in actual use is an anti- 
principle as far as HTML5 development has proceeded so far.

> supporting existing content should
> not be used as a backdoor deprecation method for markup one doesn't
> approve of for whatever reason -- if it was added for a specific  
> purpose,
> the onus is upon those who would deprecate such specific markup to
> propose and develop -- as well as map to "legacy" markup -- superior
> solutions...

Supporting Existing Content is not a deprecation method. By default,  
anything in HTML 4.01 is eligible for tossing out. Support Existing  
Content is about retaining certain user agent behaviors. If this has  
the effect of giving the appearance of retaining certain HTML 4.01  
features, it is incidental. Support Existing Content is not a blanket  
HTML 4.01 retention principle.

> take ABBR and ACRONYM -- it took forever for them to be  
> implemented, and
> a fair deal of those implementations were accidental, through UI  
> decisions
> to display anything with a "title" defined for it onMouseOver, but
> eventually, support for (and visual-only indications of available
> expansions) have become widely supported...

Eh? Isn't one of them still unsupported in the browser engine with  
the greatest desktop market share?

> are end users to be punished for what UA implementors decided FOR  
> them is
> "best" and what was not worth supporting?

How do you mean punished? If a spec omits a feature that has no  
notable user impact, how are users punished? If foo were unused but  
in a spec yesterday and unused and not in a spec tomorrow, how are  
users punished?

> have you read the User Agent
> Accessibility Guidelines?
>
> http://www.w3.org/TR/UAAG10

IIRC, way back when it was published.

Keeping referring to specs does not change what behaviors shipped  
software embodies.

> AU means "Authoring Tool" in this context,

OK. Thanks.

[list of specs snipped]

Aside:
It seems that people have two very different views of what  
standardization is.

Some people view standardization as a mechanism that lets non- 
implementors force implementors to do things. When implementors don't  
do the non-implementors' bidding, the non-implementors complain.

Other people view standardization as a mechanism that lets  
implementors agree to do things they already want to do in an  
interoperable way while also considering ideas from non-implementors.

> i am NOT "opposed to making it a principle that those purposes need  
> to be
> addressed somehow" -- quite the contrary...  but no text to that  
> effect
> has been added to, or seriously considered by, the HDP editors, and  
> when
> such a principle has been requested in the past, it has either been
> ignored or denigrated...

That falls under Universal Access--not Support Existing Content.

> yes, it is best to have built-in accessibility, device-independence  
> and
> internationalization features, and what i am asking is precisely that
> those built-in features of HTML 4.01 Strict be backwardsly  
> supported by
> HTML5 compliant user agents -- please explain to me why this is an
> unreasonable request...

It is an unreasonable request because it excludes some features from  
technical scrutiny on the level of principles. Just because some  
features in HTML 4.01 were created for a stated purpose doesn't mean  
the features have been usefully implemented, achieve the stated end  
or achieve the stated end well. Accessibility features should be  
subjected to empirical scrutiny just like other features instead of  
pre-empting scrutiny by blessing certain features in the Design  
Principles.

> headers/id are "built-in", as is "summary" for table --

They aren't built-in in the same sense that the AT progress bar role  
<progress> is built-in. headers='' and summary='' are something you  
add specifically for accessibility.

> is that not "intergrading" specific markup into general markup --  
> headers/id could be used by a wide variety of users

As far as Support Existing Content goes, it isn't about "could". It  
is about "are".

> for example, having the x and y axis for a particular cell exposed  
> onFocus and/or MouseOver...  what is in HTML 4.01 Strict isn't add- 
> on markup

To make header association to be of interest for purposes other than  
accessibility, HTML5 could introduce a DOM method for getting the  
header cells associated with a given cell. However, the practical  
reality today is that headers/id is for AT.

> if you quote wouldn't make
> it a principle that those purposes need specific markup unquote how
> would you address such issues in the design principles document --
> surely, it would be unprincipled NOT to do so, especially since the  
> first
> "officially" public draft is going to raise a lot of hackles precisely
> surrounding such issues?

I wouldn't use Design Principles to pre-empt language design options  
when it comes to accessibility. I want to prefer designs that enable  
accessibility without the author having to take extra accessibility- 
enabling steps, but I also want to leave the door open for extra  
steps in cases where not taking extra steps fails.

> HenriS quote:
> 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.
> unquote
>
> that assumes that there is something to which to "degrade"...

I continued with "In case Degrade Gracefully doesn't fully capture  
the concern" immediately after:

> HenriS quote:
> In case Degrade Gracefully doesn't fully capture the concern, a new
> principle could be formulated: Keep Authoring for Existing Assistive
> Technology Conforming
> unquote
>
> this goes directly against the grain of your entire argument...

It doesn't. It's rather frustrating that you think it does.

You tried to co-opt a principle that constrains what the spec can say  
about user agent conformance. The new principle I formulated was  
about constraining what the spec can say about document conformance.

> HenriS quote:
> 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.
> unquote
>
> i THINK i agree with your sentiment, but i'm not sure -- i got lost in
> all the ambiguous "use cases" and vague terms such as "an earlier
> mechanism" and "already been implemented in user agents and is in  
> active
> use" -- again, who is to decide?

The WG participants research existing content and test existing  
implementations, bring the findings forward and the editors give this  
data due consideration.

> and who is to "blame" for the initial failure of support for such  
> mechanisms

Like I said on IRC, legacy just is. Passing the blame around doesn't  
change the legacy. Asking who is to blame for the legacy state of  
things is like asking who you can blame for gravity if you don't like  
gravity.

However, figuring out what was to blame for the non-success of a  
given feature is useful for avoiding repeating the same mistake.  
Merely blessing old specs on the level of Design Principles is just  
the opposite: refusing to examine what went wrong and assuming that  
staying the course fixes things.

> HTML is meant to be a language for all, not a popularity contest, in
> which the odds are heavily stacked by developers who provide the  
> bulk of
> authors with a pre-determined limited set of tools with which to work
> (authoring tools that don't prompt for ALT or a long description, for
> example)

That's not the point. The point is that if there's an HTML 4 feature  
that isn't working for its stated purpose, we might as well consider  
a new way of addressing the stated purpose or reassess the need to  
address the purpose. If something decade old is not working by now,  
we should allow ourselves to reassess the situation to figure out if  
something can be done to get something that would work.

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

Received on Thursday, 25 October 2007 10:28:13 UTC