Re: Comments on 8 December AUGL - PJ comments

PJ responses to CMN responses to PJ responses to CMN responses to IJ issues

...

Issue 6) delete "that is stylistic" from Checkpoint 4.5
  PJ: Either way, we need to define the terms "presentation markup" and
  "structural markup" and give examples of such markup [we don't currently
in
  either the glossary nor the techniques].

CMN I agree that we should define these. A suggestion:

...

PJ's changes to CMN's suggestions:

Presentation markup
  [Markup language] such as [CSS] used to encode information about the
desired presentation or layout of the content.  [CSS], for example, can be
used to control fonts and positioning. Presentation markup should not be
used incorrectly to present or layout information to resemble structural
content.  For example, [CSS] or [HTML40] should not be used incorrectly to
visually layout information to resemble a list with out also using the
[structural markup] for a list.


Structural markup
  [Markup language] such as [HTML40] used to encode 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, [HTML40]
should not be used incorrectly to achieve an indentation visual layout
effect by using the <quote> element. 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.



Issue 7) Checkpoint 5.1

  PJ: the three terms are all the same to me, functions, features, or
  functionalities. But adding "user interface" is limiting.  I read the
  current wording to be more than just the natural integration into the
user
  interface of the tool, but also into the way the tool works inside, or
the
  plumbing (non UI) components of the tool.

CMN I read it the same way, which is why I support using User interface -
it
is not important to the end user how the tool is built (except as a product
differentiation - a well-built tool is generally more efficient than a
badly-built one), only how the user interface works.

PJ I agree that it is not as important to the user how the tool is built,
but how the user interface works.  But, since these guidelines are written
to developers, it is important to write to developers who may at times
think of the UI as separate from the supporting plumbing that supports the
UI.  By using the term "user interfaces" the developer reading the document
may not think of the required functions and features [functionalities is
not a word in my dictionary] that also need to be implemented to comply
with the checkpoint.

Regards, Phill

Received on Tuesday, 14 December 1999 18:05:53 UTC