Re: ACTION-95, ISSUE-65: Plan to publish a new WD of HTML-5

Also sprach Murray Maloney:

 > >Personally, I don't think any amount of QA effort can keep two
 > >different documents describing the same matter from being in conflict
 > >with each other.
 > 
 > That is useful input. My opinion, based on many years writing, editing
 > and publishing technical documentation is at variance with yours.

Let's compare notes. The situation we're facing is, I believe, similar
to the issue of sharing formatting properties between XSL and CSS:
should these be described in one or two specifications? I argued for
one specification in 1998, but lost. Today, W3C has two sets of
formatting properties that often have the same names, but with
different values and semantics. This has made it hard for
implementation to support both sets -- which definition do you choose?
I fear we will have the same sort of problems if elements in HTML5 are
described in two different places.

Another similarity of the formatting properties anno 1998 and HTML
anno 2009 is that the two camps that argue have slightly differing
backgrounds, culture and goals.

For reference purposes, here is a writeup on the formatting issue done
in 2002:

 |  > In response to formattingProperties-19[1], I have published "TAG
 |  > Finding: Consistency of Formatting Property Names, Values, and
 |  > Semantics"[2]. The TAG invites public comment on this draft
 |  > finding.
 | 
 |  > [1] http://www.w3.org/2001/tag/ilist#formattingProperties-19
 |  > [2] http://www.w3.org/2001/tag/doc/formatting-properties.html
 | 
 | The topic of discussion has a long history in W3C. Formatting was
 | described in early HTML specifications, but it was generally agreed
 | (although with much dissent) that HTML should remain a structural
 | language and formatting should instead be described in style sheets. 
 | 
 | W3C published the CSS1 Recommendation in December 1996 [3] which
 | described a set of formatting properties. The list of formatting
 | properties was extended -- including aural formatting properties -- in
 | May 1998 with the publication of the CSS2 Recommendation [4]
 | 
 | At that point the XSL WG had been started and the issue of how to
 | synchronize the two specifications was discussed. There were three
 | main positions:
 | 
 |   1) XSL is a separate specification and should be free to make its
 |      own choices on formatting
 | 
 |   2) XSL and CSS should use the same property names, but they should
 |      be described in separate specifications. Coordination between the
 |      two working groups will ensure that the specification are
 |      synchronized.
 | 
 |   3) Formatting properties should be described in one language-neutral
 |      specification and referred to by other specifications.
 | 
 | Personally I favored option #3 and started work on a "W3C formatting
 | model" [5]:
 | 
 |   This specification describes the W3C Formatting Model (W3C-FM).
 |   W3C-FM is a common formatting model for onto which all W3C
 |   Recommendations which expose formatting functionality are based.
 |   Currently, HTML4 and CSS2 expose part of the W3C-FM in their
 |   respective languages. Also, work in progress (e.g. XSL and SMIL)
 |   will be based on W3C-FM. W3C-FM is derived from W3C's CSS2
 |   Recommendation and ISO's DSSSL Standard.
 | 
 | However, the XSL WG chose option #2 and published their own list of
 | properties in August 1998 [6][7]. Since then Steve Zilles has worked
 | hard to synchronize XSL-FO and CSS by participating in both groups.
 | With few exceptions (one is discussed below) the names of properties
 | and values are the same across CSS and XSL-FO specifications. Steve
 | is, however, rightfully concerned that order will not necessarily
 | continue [8]:
 | 
 |   I have retired as a full time employee and contributor to the W3C. I
 |   am no longer able to perform the function which I had been
 |   performing. I strongly fear that without architectural affirmation
 |   of the principle of a common, shared set of formatting properties,
 |   that the second law of thermodynamics will quickly lead to a
 |   non-inter-operable set of formatting properties with independent
 |   islands of use.
 | 
 | I agree with Steve's concerns, but not necessarily with the conclusion.
 | I don't think an "architectural confirmation" is enough to keep
 | specifications aligned. I don't think it is possible -- even with an
 | architectural confirmation in place -- to describe formatting
 | properties in two different specifications and have them mean exactly
 | the same. The only solution that will ensure consistency is to
 | describe formatting in one specification. In other words, I believe
 | option #3 is still the correct answer to the problem. The TAG should
 | not publish a "TAG Finding" on this. Rather, W3C should publish one
 | language-neutral specification describing formatting and have other
 | specifications point to it.
 | 
 | Having just argued against [2], I also have one specific comment on its
 | wording. I quote:
 | 
 |   "Furthermore, as XML vocabularies are now being combined in many
 |   ways, it is becoming more than merely beneficial, it is becoming
 |   imperative that a common set of properties and values be developed."
 | 
 | I don't think XML should be mentioned. Using XML to describe
 | presentation is still a controversial issue for some and the above
 | statement opens a different discussion.
 | 
 | Yet another specific comment comes is related to the discussions in
 | the tag. I quote from [9]:
 | 
 |    NW: Have single set of semantic properties among css, xslt, svg,
 |       ... SZ noticed recently that CSS WG has decided to rename some
 |       properties first named by the XSL WG. SZ argues that renaming
 |       properties is a bad idea.
 | 
 | I believe (but could be wrong) the above refers to the CSS WG's
 | decision to include this property in CSS3:
 | 
 |   all-space-treatment: preserve | collapse
 | 
 | XSL, on the other hand, has this property:
 | 
 |   white-space-collapse: true | false
 | 
 | The reason for CSS not using the XSL property (for minutes, see [10])
 | is our long-standing architectural principle to not use true/false
 | values since these leave little room for future extensions. (CSS is
 | truly extensible :) There are no true/false values in CSS1/CSS2. To my
 | knowledge, all other true/false values inherited from DSSSL have been
 | removed from XSL and the remaining one was unintentional. I suggest
 | fixing the error rather than using it as a case for architectural
 | principles.
 | 
 |  [3] http://www.w3.org/TR/REC-CSS1
 |  [4] http://www.w3.org/TR/REC-CSS2
 |  [5] http://www.w3.org/Style/Group/1998/06/WD-W3C-FM.html
 |  [6] http://www.w3.org/Member/Newsletter/1998/0821#xslwd
 |  [7] http://www.w3.org/TR/1998/WD-xsl-19980818
 |  [8] http://lists.w3.org/Archives/Public/www-tag/2002May/0042
 |  [9[ http://www.w3.org/2002/05/20-tag-summary#formattingProperties
 |  [10] http://lists.w3.org/Archives/Member/w3c-css-wg/2001OctDec/0260.html
 | 
 | -h&kon
 |               Håkon Wium Lie                          cto °þe®ª
 | howcome@opera.com                  http://people.opera.com/howcome

   http://lists.w3.org/Archives/Public/www-style/2002Jul/0001.html

(CSS3 now uses the property name white-space-collapse, but the values
are different from XSL)

Cheers,

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Thursday, 29 January 2009 00:30:10 UTC