- From: Charles McCathieNevile <charles@w3.org>
- Date: Thu, 6 May 1999 10:40:22 -0400 (EDT)
- To: Jon Gunderson <jongund@staff.uiuc.edu>
- cc: Harvey Bingham <hbingham@ACM.org>, w3c-wai-ua@w3.org
There are two things at work here. The first is to allow access to the attributes (propoerties) of a given element. The second is to search for an element with a given property (attribute value). I think both are of value, and if available together would satisfy the 'allow a user to find the next thing like this' checkpoint. I am using 'properties' here as information pertaining to an object, rather than the more restricted definition used in the document, which only refers to style properties. I suggest that the definition in general be expanded, and the term 'style properties' be used when that is what is meant. Charles McCN On Thu, 6 May 1999, Jon Gunderson wrote: Thanks for the quick posting Harvey. Could we change the name of the checkpoint to: Checkpoint: Allow the user to search for an element by its attribute values Subgroup: dependent user agents Priority: 3 At 05:57 PM 5/5/99 -0400, you wrote: >Per our discussion today, here's a possible checkpoint and technique. > >Checkpoint: Allow the user to learn of attributename="value" pairs for any >element. >Priority: 3 > >Technique: >The meta-information about an element contained in attribute values can >support the understanding of the containing element, or its descendents. >It should be exposable by user request. > >Details: > >Many attributes are implicitly present, so the presence in an element of an >attribute=value pair cannot be depended upon for information. It is up to the >semantic description of each attribute name and its allowed values for an >element type to indicate both the explicit meaning of the attribute, and what >is the defaulting meaning of a missing attribute. Often this meaning can be >determined from the value of the same-named attribute on an ancestor element. >Other times the semantics indicate no inheritance (e.g., an id, a document- >unique identifier for referencing a particular element). > >Some attributes are generally applicable to all or most element types. For >these, common understanding of their use is reasonable to expect for authors >and users. > >Search on attributename and possibly value is important. Search may be on >the next attributename, or on attribute value, possibly inherited, possibly >qualified by element name. > >Each search returns the next occurrence of the containing element. An >implementation possibility is to list all matches, and return them in >order to the user. > >Another useful result is to learn the different attributename="value" pairs >or a subset of them for any particular element. > >Another useful search is to find the next element that can have a particular >attributename, and for it seeking its default value, possibly from the >nearest ancestor. > >Details for HTML 4.0: These common attributes are associated with almost >all HTML 4.0 element types, and can be learned: > >% attrs > "%coreattrs; %i18n; %events;" > >including: > >% coreattrs > "id ID #IMPLIED -- document-wide unique id -- > class CDATA #IMPLIED -- space separated list of classes -- > style %StyleSheet; #IMPLIED -- associated style info -- > > ELEMENT TYPES WITHOUT %attrs; but with %coreattrs > BDR -- bi-directional override-- > BR -- forced line break -- > HR -- horizontal rule -- > >% i18n > lang %LanguageCode; #IMPLIED -- language code -- > dir (ltr|rtl) #IMPLIED -- direction for weak/neutral text --" > > ELEMENT TYPES WITHOUT %attrs; but with %i18n; > HTML, HEAD -- lang, dir defaults for document -- > META, TITLE -- lang, dir, for use with content -- > STYLE -- lang, dir, for use with title in HEAD -- > >% events; > "onclick %Script; #IMPLIED -- a pointer button was clicked -- > ondblclick %Script; #IMPLIED -- a pointer button was double clicked-- > onmousedown %Script; #IMPLIED -- a pointer button was pressed down -- > onmouseup %Script; #IMPLIED -- a pointer button was released -- > onmouseover %Script; #IMPLIED -- a pointer was moved onto -- > onmousemove %Script; #IMPLIED -- a pointer was moved within -- > onmouseout %Script; #IMPLIED -- a pointer was moved away -- > onkeypress %Script; #IMPLIED -- a key was pressed and released -- > onkeydown %Script; #IMPLIED -- a key was pressed down -- > onkeyup %Script; #IMPLIED -- a key was released --" > > ELEMENT type without %attrs; but with %events; (and %coreatts;) > HR -- horizontal rule, takes space, has no text -- > > ELEMENT types with none of %attrs;, %coreatts;, %i18n;, or %events; > PARAM > BASE > SCRIPT > >Some attribute names are used in consistent ways, as reflected by their comments. A few seem >to have different semantics. The latter should be avoided, particularly where inheritance >of attribute value is presumed. > >For XML applications, a similar set of general attributes may be useful. A common occurrence >is to specialize a general element name to indicate a local variation on the general >element type. For example, in electronic books, different books have different names for >the hierarchic sectioning. Some use chapter, some use part, some use section, some use "El Parto". > >Regards/Harvey Bingham > > > > Jon Gunderson, Ph.D., ATP Coordinator of Assistive Communication and Information Technology Division of Rehabilitation - Education Services University of Illinois at Urbana/Champaign 1207 S. Oak Street Champaign, IL 61820 Voice: 217-244-5870 Fax: 217-333-0248 E-mail: jongund@uiuc.edu WWW: http://www.staff.uiuc.edu/~jongund http://www.als.uiuc.edu/InfoTechAccess --Charles McCathieNevile mailto:charles@w3.org phone: +1 617 258 0992 http://www.w3.org/People/Charles W3C Web Accessibility Initiative http://www.w3.org/WAI MIT/LCS - 545 Technology sq., Cambridge MA, 02139, USA
Received on Thursday, 6 May 1999 10:40:26 UTC