Re: Attaching Semantics to Class (was: open issues)

At 08:58 AM 2000-09-20 -0700, Kynn Bartlett wrote:
>At 12:07 PM -0400 9/18/00, Wendy A Chisholm wrote:
>>For example, issue #42. Attaching semantics to classes  had a lot of 
>>discussion on the WCAG list, but was it resolved?  Len - did you 
>>receive a satisfactory answer?  Seems to me it was still being 
>>discussed.
>
>In my opinion the issue was not sufficiently resolved and while
>I like Len a lot, I don't like his proposal. :)  I feel that
>exposing the arbitrary inner workings of HTML and CSS to the
>end user -- i.e. by identifying specific "classes" -- is a
>very poor solution to the problem of poor semantics in HTML
>code.  A better solution would be to increase the semantical
>content of HTML markup, not try to modify CSS in the proposed
>manner.

AG::

Once consideration that runs counter to that argument is roughly as follows:

The injunction to use semantic CLASS marks and not style rule synonyms is
in the WCAG already.  To get human concepts reflected in these selections,
they have to be exposed to some human, and exposing them to users places
some "plain English" pressure on authors.

In other words, give the way CSS works, one cannot relegate CLASS marks to
"the inner workings" and achieve a common-sense core for the alternate-sign
variation across alternative style sheets.

The other technical issue is that once you start examining what the
semantic classes are that need to be conveyed for universal styling, one
discovers a requirement for multiple heredity [why couldn't sandbox.com
have double-hatted a table column as simultaneously a FIELDSET so the
logical structure would be preserved?].  In that case the solution where we
have to negotiate with the format spec writers may be CLASS marks for
subclasses because there is no single-level classification that captures
what needs to be said.  So as one of the stuckees for "make the format
contain the semantics out of the box" I wish to reserve the wiggle room to
use subtype indications via CLASS attributes and not assume that one flat
dictionary of element types is going to capture everything that needs to be
expressed.


[shift gears, pop up a level]

My main concern is how to link up the discussions of general accessibility
strategies in GL, evaluation strategies in ER, and requirements
articulation for new formats in PF.  [Actually, UA and AU are essential to
make the progress-generating engine work.]

The only idea I can see is that we deal in object- and graph- classes as
the way to capture how it has to work;  Then we can map these to some
things -- maybe hard coded element and attribute types in XML, maybe
architectures of supertypes -- I can't say for sure.  But when it comes to
back-fitting what we have learned onto HTML, it is almost certain that we
will need to use CLASS marks to annotate more semantics onto the elements
that float around in the hypertext coding at the moment.

To give an example.  I really liked Kynn's analysis of the W3C Home Page
and explanation how it exemplifies common intra-page structures of the
current fashion of page design: masthead, left-nav-bar, payload,
right-sidebar-highlight, footer-aka-slash-etc.

Now "masthead" and "footer" are not classes, they are roles.  The define
the relationship of a sub-range of content to the whole page.  But for the
User Agent trying to guess what is the extent of the masthead, there are
legitimate CLASS designations that would sure help.  How about <IMG
CLASS="logo, sponsor" src=...> and  <span CLASS="indicia,
copyright">...</span>?

I am really bummed that we can't tell the UA group what to write into their
User Agent spec as to how the User Agent should recognize the principal
parts of a page, and most importantly discriminate between payload and
packaging roles within the page.  This distinction is endemic.  It's
present in 99-44/100% of all web pages.  It would solve the "tank trap of
repetitive links at the head of the page" problem deader than a doornail.
I am sorry I haven't fomented more effective action plans to move us (the
WAI) to where we have a markup vocabulary, whether in CLASS ROLE or
whatever indications, and authoring session practices that will make this
level of deconstruction a piece of cake for the User Agent.

Len's proposal may or may not be the answer, but it attempts to solve a
valid problem.

Al



>
>--Kynn
>-- 
>--
>Kynn Bartlett <kynn@idyllmtn.com>
>http://www.kynn.com/
>

Received on Wednesday, 20 September 2000 15:41:27 UTC