PROPOSAL: Technique for Attribute Access

In the terminology of the current working draft, you are proposing a
checkpoint like:

Checkpoint: Allow the user to view the attributes of an element
Subgroup: Depedent user agents
Priority: 3

in addition to the searching checkpoint?

Jon


At 10:40 AM 5/6/99 -0400, you wrote:
>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
> 
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

Received on Thursday, 6 May 1999 10:49:13 UTC