FW: AuthConfReq: Presentational Markup

This is a little terse, so please don't take too much out
of context, but I've been thinking about how to deal with some
of the authoring/document conformance issues:


What I'd suggest is a clearer separation of conformance
classes, which seem to me to be mixed in this spec (and, for
what it is worth, in other web specs too.)

(a) document conformance: defining what is or isn't a "valid" document,
   with some features added, some features changed, some
   "deprecated", and some "removed" compared to HTML4.

(b) authoring conformance: defining expected, preferable, best practices
  for authoring tools or author behavior

(c) validator conformance: defining expected, preferable, best practices
  for tools that might be used for evaluating (a)

as well as being clearer about the distinction between:

(d) document processor conformance: defining expected, preferable, best
   practices  for any component that reads, scans, interpreters documents

(e) user agent conformance: defining expected, preferable, best practices
  for document processors that are interacting with a user

(f) browser conformance: defining expected, perferable, best practices
  for user agents whose primary purpose is to browse the (primarily
  HTTP-based) web.

Some opinions (to be turned into more concrete edits or bug
reports, if anyone agrees with these):

 (a) I would argue against making any previously valid content invalid
unless
(1) it was never implemented as specified
(2) there is demonstrable harm to others that making the feature
  invalid will repair.

For "interoperability", documents (a) need to be accepted by
all document processors (d).  Conforming documents should be
conservative (robustness principle) even though document processors
are liberal.

I would argue that presentational markup don't meet these criteria.


(b) I think there should be few conformance requirements
on authoring tools, with exceptions made when justified for
general good of issues around security, privacy, internationalization,
accessibility. There are such a wide variety of authoring and
creation tools and content management system generation of HTML
that "authoring" requirements that are generally applicable
will be rare.

(c) I think way too much empahsis has been put on validators.
There are many kinds of validation and tools and checkers that
implement not only determining "valid" content as far as this
specification, but also deal with legacy systems, text-only
systems, screen readers, etc. and each delivery context probably
requires a different validator. I'm not sure there should be
any conformance requirements on validators per se -- they should
most likely be requirements on (a).

(d) I think far too many of the requirements currently actually
only apply to (f) but the spec is written as if they apply to
(d).

I think way too many things that should be "best practices"
and at best a MAY are instead couched as mandatory for (d).



Larry
--
http://larry.masinter.net

Received on Tuesday, 30 March 2010 23:00:03 UTC