style reflects affinity grouping beyond what's in an element type

At 07:21 PM 2001-07-19 , Wendy A Chisholm wrote:
>available at:
<http://www.w3.org/WAI/GL/2001/07/19-minutes.html>http://www.w3.org/WAI/GL/2
001/07/19-minutes.html
>
>19 July 2001 - WCAG WG Telecon
>

>3.1
>GV When houses on the block all look the same, children get lost. If don't 
>have differences, people will confuse. Therefore can't look exactly the 
>same everywhere.
>JW The idea in writing this, every element type will have a uniform style 
>applied to it. Usually via style sheet. Sometimes not the case. Consistency 
>understood in terms of hierarchical divisions. Every element should have 
>its own style properties.
>WC In CSS draft, identify function of terms or function of pieces, each 
>piece have similar presentation throughout site.
>GV Agreed.
>JW Reading too much into it GV.
>GV So all bathrooms should be laid out the same.
>GR Different aspect: braille should always be to the right of the objects.
>GV We're all agreeing, but we're writing sufficiency or requirement 
>language. Doesn't matter intent, but the actual words. Instead say, "when 
>setting up type structure, use controls consistently so that users can 
>predict or know or behave way.."
>WC We separated behavior from presentation.
>JW Think this would work if redrafted.
>ASW problem with the word must.
>GV We struck on this before, if this were to be a P3, can't use must 
>language in a lower priority checkpoint.
>JW Perhaps rewrite that not every element has to have consistent style.
>WC More to do with function. e.g. W3C copyright.
>GV What if nav always on top, on some on bottom, would that site be not be 
>AAA b/c nav bar moved?
>JW Yes, would be a problem.
>WC Although, in future, depend on semantics. Won't have to worry so much 
>about positioning.
>GV Instead of having a requirement...
>JW Examples.
>GV Statement of intent, pages should be generally consistent layout so that 
>easy to locate info.
>JW Propose "Intent" for each checkpoint.
>WC Similar to rationale that I already took as an action to put into the 
>draft. We need to create tests and then reach consensus on which we think 
>conform and which don't.
>GV Absolutely great idea.
>JW Need next draft first.
>GV Before the next draft, put in things that we are comfortable with.
>

A problem here is that the issue is pretty deep.

Chris Lilley and I on the PF list have been arguing that a hierarchical model
is too confining for styling plans, and WAI can't ask for content producers to
follow a policy this restrictive because it is unresonably restrictive.  It is
unreasonable because it is a severe restriction, and because it is not
necessary.

The "severe restriction" part is inseparable in my mind from the idea that a
tree is one and a half dimensional while the space generated by tuples of
presentation properties is of a higher dimensionality, and thereby much, much
larger.

The "not necessary" part is that multidimensional styling is effective, is
recognizable by real people.  This latter idea needs to be backed up by
empirical results from the psychology, cognitive science, human factors and
human:computer interaction community.  But based on what one sees in actual
web
pages, there is some credence that may be given to this theory.

A hierarchical model of content containers is reasonable and natural.  One
finds this motif present in the rhetorical practices of actual,
access-ignorant, web content designers.  But, I would claim, one cannot
demonstrate a hierarchical scheme of categories to which styles are bound in a
comparable way in the as_is Web.  De_facto styling lives in a more relational,
associative or higher-dimensional space.  I believe that this mirrors human
perception.  One picks up more kinds of patterns of similarity than fit
naturally into a single tree.  In other words, the taxonomy is much better
expressed in a language that supports multiple heredity than one which does
not.  We need to be able to create themes by styling to pick up on multiple
concurrent kinds of threads of association that the content atoms are
connected
with.

One could create a styling practice where the style rules only depend on the
element type names.  But to make this cover the rich variety of
psychologically
effective styling patterns, it would require that each styling plan was
supported not only by a stylsheet but by an XML 
Schema document that organized the syntax along the lines as used in this
stylesheet.  This would require processing a schema every time you open up a
web page, and the element names would not represent concepts useful across
style plan regimes.  I don't think this is where we want to go.  Never mind
that it is beyond where we can go, in terms of taking the Web industry with
us.

Where is this going?  Just to say that style rules must be allowed to
select on
attribute values as well as on element types.  And that the space of semantic
categories that gets bound to style categories is probably a richer taxonomy
than a single tree.  So we should be prepared for this.

Absolutely we want to ask content providers to have and use and publish a
model
for what it is the styling is conveying.  This is for example the brunt of
XMLGL Guideline 2.  But we can't assume that this takes as constrained a form
as a table of contents tree, or the element type repertory of the syntax. 
Human perception and cognition and discourse is just more multidimensional
than
that.  We need to think of styling as belonging to affinity groups, and that a
given elment instance may belong to several of these concurrenly, and that the
element-plus-affinity-groups-joined information is a refinement of the element
vocabulary, not synonymous with it.  The element type will mostly capture
those
affinity groupings that play a role in the containerization or physical
grouping of content.  The logical groupings that styling represents cover
semantic dimensions that are beyond those reflected in the hierarchical
structure and elment type vocabulary, and to some degree apply
independently of
these.

Structuring containers represent both relatedness in the understanding and
gatheredness in the HTTP communication or user interface representation.
There
are affinity group associations which represent relatedness in the
understanding which has not be reflected in gatheredness, only by markedness,
the bearing of common characteristics.  The analogy between the component
structure tree and the element type tree is only an analogy.  But the fact is
that a tree of element types is too small a space for what people want to
communicate in terms of concurrent affinity groupings.  That is what Chris has
experienced through years of working in the style technology area.  And I
believe he is right.

Al

Received on Saturday, 21 July 2001 14:48:56 UTC