Re: HDP: Revised "Support Existing Content" Principle

HenriS wrote, quote:
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.
unquote

who decides what constitutes implemented?  the top 3 or 4 UA vendors?

existing content was added for a reason -- 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" -- 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...

i suppose not everyone has had the opportunity to read:

http://esw.w3.org/topic/HTML/AccessibilityDependencies

but they should...

HenriS quote
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.
unquote

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

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

are end users to be punished for what UA implementors decided FOR them is
"best" and what was not worth supporting?  have you read the User Agent 
Accessibility Guidelines?

http://www.w3.org/TR/UAAG10


HenriS quote:
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.)
unquote

AU means "Authoring Tool" in this context, as in the "Authoring Tool 
Accessibility Guidelines Working Group" - http://www.w3.org/WAI/AU)
which promulgated:

Authoring Tool Accessibility Guidelines, version 1.0: 
http://www.w3.org/TR/ATAG10

Authoring Tool Accessibility Guidelines, Wombat Edition: 
http://www.w3.org/TR/ATAG-wombat

Authoring Tool Accessibility Guidelines, 2.0 (Working Draft): 
http://www.w3.org/TR/ATAG20

i have posted often to the list about this group -- surely, AU conformance
should treat the ATAG documents as dependencies, and if not, why not? -- 
especially the principle of supporting markup precisely intended to 
increase accessibility, interoperability, device independence, and 
internationalization...

HenriS quote:
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.
unquote

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

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

when you write, quote:
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.
unquote

headers/id are "built-in", as is "summary" for table -- is that not 
"intergrading" specific markup into general markup -- headers/id could 
be used by a wide variety of users -- 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, and 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?


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

it is a principle of UA conformance -- what is to be expected of UAs when
rendering "legacy" technology

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"...  
degrading gracefully has been a long-term topic of discussion in the 
W3C and is well-addressed in:

http://www.w3.org/WAI/GL/Glossary/printable.html

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

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?  and who is to "blame" for the initial 
failure of support for such mechanisms -- it isn't those who benefit from 
them, it's those who chose to ignore them and those who assume that 
magical assistive technologies will make up for deficiencies in 
"mainstream" implementations...

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)

one cannot simply wash one's hands of responsibility -- again, the bar 
hasn't been set too high -- it has been kept artificially low by those who
control the means of production...

and, yes, i do want the same verbiage explicitly added to the HTML5 
draft's of UA and AU conformance statements for all HTML5-
compliant tools...

these are issues that it is incumbent upon this working group to address 
in our design principles document -- generalities, in this case, do NOT
suffice -- are not accessibility, internationalization and device 
independence cornerstones of W3C technologies?

gregory.
--------------------------------------------------------------
You cannot depend on your eyes when your imagination is out of
focus.                                           -- Mark Twain
--------------------------------------------------------------
Gregory J. Rosmaita: oedipus@hicom.net
   Camera Obscura: http://www.hicom.net/~oedipus/
          Oedipus' Online Complex: http://my.opera.com/oedipus
--------------------------------------------------------------

Received on Wednesday, 24 October 2007 20:55:15 UTC