W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2000

Comments on presentation/structure related to issue 297.

From: Ian Jacobs <ij@w3.org>
Date: Fri, 21 Jul 2000 20:31:35 -0400
Message-ID: <3978EB67.C3887207@w3.org>
To: asgilman@iamdigex.net, w3c-wai-ua@w3.org

At the 20 July teleconference [1], Eric Hansen suggested that
the UA Guidelines (presumably including the 7 July draft [2])
uses the terms style/content inconsistently:
   "In some places, we don't distinguish style and content, in
   others we do. We need to elaborate our definition of content."

The definition of "content" in that draft says that 
"content refers to the document object as a whole or in parts."
The document object definition says that "the document object 
is the user agent's representation of data (e.g., a document)."
This would include style sheets. I think we should leave this
definition as is.

For distinguishing structure from presentation (both conveyed
in content) I propose that we do what was done in the 
Authoring Tool Guidelines, which defines the terms structural 
markup [3] and presentation markup [4]. I propose that we 
reuse or adapt those definitions (quoted below) as necessary.

All of this relates to issue 297 [5], which is entitled 
"Style v. content and background sounds" (the title needs fixing 
since it opposes style and content).

The question is how much UA control is required over certain 
types of content, notably when that content is used to achieve
a presentation effect? I think that the answer depends on the
type of content:

1) Users need full control of content whose purpose is not a 
   presentation effect. The first question is: can we distinguish
   content intended for a presentation effect from content not
   intended for a presentation effect? My answer would be: the
   best we can do is rely on what we can recognize as being
   for style: HTML transitional elements and attributes,
   style sheets, known non-standard markup such as bgsound. 
   (Yes, authors may misuse structural markup for a presentation 
   effect and vice-versa.)

   Note that I don't have a term for "content not intended for
   a presentation effect." I think we tend to use the term 
   "content" (meaning "having information") here, and that's the
   source of the inconsistency. We can oppose style and structure, 
   and style with non-style. Do we need a term for "non-style"? 
   (I hope we don't.)

   I would also note that this discussion sounds a little like the
   discussion about content meant for humans v. content meant for
   machines. Refer to Al's comments on this topic [7]:

     "The distinction between data (raw content) and meta-data 
     (markup) is an artifact of the view assumed by the author.  
     There is no fundamental semantic difference between what is 
     called data vs. metadata.  They both play the same role as 
     bearers of information  Semantically, it is all just
     one class of data.  This is a little-understood fact of 
     information science."

   Al, will you make the same comment about an assertion that
   presentation v. non-presentation (or structure)? 

2) Users also need control of content whose purpose is for presentation,
   but the level of control depends on the nature of the content
   (I would argue).  In some cases, "on/off" control may not
   suffice for providing access. For example, the user needs to be
   able to select a font family that provides access (and can't
   just turn off fonts). In other cases, I think that on/off control
   suffices; access is made possible by being able to turn off
   blinking content, animations used for decoration, and background
   sounds used for decoration. While fine tune control might be
   useful, I think that a requirement to turn off the interfering
   is the Priority 1 requirement.

I think my proposal for issue 5 that arose during the 
Mac IE evaluation [6] is still appropriate in this light.

  - Ian

P.S. The proposal should include a comment that independent
control of volume for different audio sources should NOT be
required for background sounds. The user must be able to
configure the UA to not render this merely decorative sound,
and that should suffice.

[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0097.html
[2] http://www.w3.org/WAI/UA/WD-UAAG10-20000707
[3] http://www.w3.org/TR/2000/REC-ATAG10-20000203/#def-structural-markup
[5] http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#297
[6] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0060.html
[7] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0210.html

Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

   "Structural markup" is markup language that encodes information 
    about the structural role of elements of the content. For
    example, headings, sections, members of a list, and components 
    of a complex diagram can be identified using structural
    markup. Structural markup should not be used incorrectly to 
    control presentation or layout. For example, authors should not
    use the BLOCKQUOTE element in HTML [HTML4] to achieve an 
    indentation visual layout effect. Structural markup should be
    used correctly to communicate the roles of the elements of 
    the content and presentation markup should be used separately to
    control the presentation and layout."

   "Presentation markup" is markup language that encodes
   information about the desired presentation or layout of the content.
   For example, Cascading Style Sheets ([CSS1], [CSS2]) can be
   used to control fonts, colors, aural rendering, and graphical
   positioning. Presentation markup should not be used in place of
   structural markup to convey structure. For example, authors should
   mark up lists in HTML with proper list markup and style them with
   CSS (e.g., to control spacing, bullets, numbering, etc.). Authors
   should not use other CSS or HTML incorrectly to lay out content
   graphically so that it resembles a list.
Received on Friday, 21 July 2000 20:31:46 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:27 UTC