W3C home > Mailing lists > Public > www-tag@w3.org > July 2002

Re: Draft TAG Finding: Consistency of Formatting Properties

From: Håkon Wium Lie <howcome@opera.com>
Date: Sun, 7 Jul 2002 13:55:30 +0200
Message-Id: <200207071155.g67BtUL01238@opera.com>
To: www-tag@w3.org
Cc: www-style@w3.org, w3c-css-wg@w3.org

Also sprach Norman Walsh:

 > 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
Received on Sunday, 7 July 2002 07:55:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:09 GMT