- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Thu, 19 Jul 2007 22:29:06 -0400
- To: www-tag@w3.org
1. I must wish to admit a preferences for the line of reasoning that Harry has been following. a. +1 to saying that there are accessibility use cases for names that have definitions behind them. b. the breakage Mark claims to have demonstrated has no standing. (all propositions are true on the empty set; his breakage is true on an empty set of functionality) http://lists.w3.org/Archives/Public/www-tag/2007Jul/0074.html Everyone seems to be agreed that present processing matches values of @class with selectors applied in CSS or XSLT without regard to further reference to any dictionary of terms linked through @profile, locally or at the root of the document. This processing depends on a private, out-of-band communication between the writer of the HTML and the writer of the CSS. It won't break under the old or new regimes. CSS selsectors don't work across sites at present, because there is no sharing of the sense of the @class values. If we define the path for people to point to instructions on how to interpret their @class values, nothing breaks, and third parties can re-use style rules, or re-style, and re-format (see SWAP from ubaccess.com) content so as to preserve the sense and dodge device and access hurdles. The site-of-origin stylesheets will still work. But user and access-broker stylings can now be fit to the content because the 'why' of the presentation has been shared. CSS has multi-attribute selectors; so that without changing CSS, stylesheets can distinguish between <elem class="foo" profile="bar"> and <elem class="foo"> ** nothing (that works now) breaks ** alll that works now is that same-site stylesheets key off @class and allocate visual (and in theory aural) semantics. With the new extension of information regarding the sense of @class tokens, this will still work. *In addition* cross-site presentation generation will work with content from sites that use @profile and back it up with meaningful data dictionary documents at the end of the @profile references. Someone said that @class in HTML is 'defined to be meaningless.' Nothing is farther than the truth. @class tokens at present have private meanings. What is true is that the HTML spec does not tell us the meaning of these tokens in anyone's documents. Linking to definitions for these terms via @profile is an upward-compatible way to give the opportunity for authors to go public with the sense of their @class terms. That's just adding value; doesn't break anything that works today. Extending the applicability of data dictionary documents linked through @profile to governing the interpretation of @class as well as meta.name is a friendly, and compatible with current functioning, extension of the semantic depth of the web. 2. This message says nothing about whether (1) curies or (2) @profile + data dictionary documents ... are [preferable | desirable | miscible | etc ]. I am only here addressing the more narrow issue of continuity as it relates to adding semantics through data dictionaries cited in @profile that disambiguate the interpretation of @class tokens. I do conclude that (2) above is not only feasible but compatible with the extant web. [It's a way for the content author to subscribe to community sharing of reusable concepts above and beyond what is in the W3C specification.] Al
Received on Friday, 20 July 2007 02:31:08 UTC