Re: Draft TAG Finding: Consistency of Formatting Properties

/ Bert Bos <bert@w3.org> was heard to say:
| Some more comments on 
|
|     http://www.w3.org/2001/tag/doc/formatting-properties.html
|     (version of 25 July 2002)
|
| 1) The heading of the document looks a bit like that of a WD, in
| particular because it has a "previous version" link. But unlike WDs,
| it has no "this version" link, so it is not immediately clear how to
| cite it.

Uhm,

I see:

   Consistency of Formatting Property Names, Values, and Semantics

   TAG Finding 25 Jul 2002

   This version:
      http://www.w3.org/2001/tag/doc/formatting-properties (HTML, XML)

   Previous versions:
     http://www.w3.org/2001/tag/doc/formatting-properties-2002-07-15
     http://www.w3.org/2001/tag/doc/formatting-properties-2002-06-17

   Editor:
     Norman Walsh, Sun Microsystems, Inc. <Norman.Walsh@Sun.COM>

Findings are in some sense a new kind of document and I don't think
there are any official policies on how they should be presented. The
style I selected is the result of my best efforts to produce something
that I felt would be clear and unambiguous, with some specific
suggestions from Ian and a couple of other folks on the TAG.

| 2) Abstract. The abstract gives as the main reason for promoting a
| common vocabulary the fact that XML vocabularies are being combined.
| However, I think ease of use and ease of implementation are more
| important reasons. Even when XML vocabularies are not combined (e.g.,
| if an SVG and an HTML document are displayed one after the other,
| instead of at the same time) or when the vocabularies are not
| expressed as XML element & attribute names (e.g., when formats are
| based on SGML or are proprietary), it still makes sense to use the
| same formatting terms, unless there is a reason not to.

Fair enough. There are many reasons why consistency is a good thing.
I'm sure my wording for the abstract was influenced by the spirit of
the issue as it was raised.

If the finding is revised, I'll happily update the abstract.

| 3) Section 1, par. 2. Why is it "imperative" that there is a common
| set of properties? I agree that it is useful, but why is it necessary?
| The text further down hints at the inheritance of properties, but that
| only plays a role in very few situations (see below).

I thought that was a natural follow-on from the preceding sentence:

"This has a positive benefit for the user- and developer-communities
because it reduces the number of property languages that need to be
understood by users and applications."

It's an application of the common principal that things that have the
same effect should look the same and things that have different
effects should look different.

| 4) Section 1, par. 3. "[...] document that consists of XSL Formatting
| Objects, XHTML table mark-up, SVG diagrams, and MathML equations." Such
| a document will probably never exist.
|
| Indeed, I believe it is an architectural principle, that the TAG
| hopefully one day puts in writing, that XSL-FO elements are at a
| different semantic level than (X)HTML, SVG and MathML, and that it is
| possible to transform the latter three into the former, but that
| putting them in the same document would be counter to the goals of the
| semantic Web. In particular, W3C promotes (X)HTML, SVG and MathML as
| permanent repositories of information and we expect them to be found
| on Web servers, but we don't expect XSL-FO's to be used for anything
| else than as a volatile format, that only exists in the milliseconds
| between the formatting and the printing of the results.

That's not a good reason not to use SVG and MathML in FO documents.
There already exist renderers that are capable of transforming FO+SVG
into PDF. Surely that's a good thing. Similarly, I would expect that
MathML would be a natural way to inject presentational math formulae
into a document printed via FOs.

| I suggest to fix that sentence by omitting XSL-FOs, or to find a
| different example.

I think the fact that FO+SVG works today is a compelling argument to
maintain the reference.

| 5) Section 1, par. 4 & 5. It might indeed be the designer's wish that
| certain things in the text (encoded with HTML or XHTML, to stay within
| W3C technology) visually match things in the included graphic (encoded
| with SVG). But since the rendering models for text and for graphics
| are quite different, it is simplistic to assume that that can be done
| with inheritance. For starters, the most important aspect, the size,
| is not an inherited property, but a derived aspect that follows from
| certain other properties. The color of the text *is* specified by a
| property, but it is likely that it is not the text of the graphic that
| the designer wants to have that color, but the lines and curves. He
| might also want the background color to be the same, but the
| background is typically not inherited, but is made transparent,
| because that matches better what the designer expects.

I fully understand that there may be more going on than can be
practically presented in a short, motivating example. However, I
maintain that it's logical for inherited properties to inherit across
boundaries. Or do you think that the user would be less surprised if
he was told that all properties of the SVG are independent of the
context in which it occurs?

| I believe that the real reason for wanting a common vocabulary *is*
| related to that example, but it is not inheritance that is the key.
| Rather, it is the designer's wish to specify the commonalities of the
| styles in a single place (i.e., a single style sheet). That means that
| it is not strictly necessary that the vocabularies are the same, but
| it does help the designer with learning and with avoiding mistakes.

I'll grant that it is not strictly necessary. But are you arguing that
such commonalities are so unimportant that there should be nothing
which motivates WGs to work cooperatively to achieve them?

| course, by virtue of being strewn with angle brackets) then it makes
| sense to expect that you can use the same binding mechanism (i.e.,
| selector syntax) for both.

What selector syntax makes the most sense is probably going to be a
consequence, at least in part, of the tools the designer is using.

| 6) The article talks about a "common vocabulary" and, although it
| doesn't say so explicitly, it seems to imply that there should be only
| one.

An editorial failing on my part then as that was not the intent.

| I don't think that follows. All that the example shows is that it
| is good for the designer (and the implementer) that they can apply the
| same vocabulary to many situations. In the example of an SVG graphic
| that is used by an HTML text, it is convenient for the designer that
| he can use CSS (i.e., CSS-style selectors and CSS properties) for
| both. But it is not the fact that there is only one style language
| that is important, but the fact that he can use the one he knows (or
| likes) in both cases.

Even if he knows four style languages, he will probably benefit if the
formatting properties and values that are effectively the same are, in
fact, the same in all of them.

If language 1 used a 'font-size' property and language 2 used
'fontsize', and language 3 used 'fontSize' and language 4 used
'font_size', and all were designed to set the font size, surely we can
agree that that would be a nightmare for the user (and the
implementors, though I generally care less about making their life
hard than I do about the users).

On the other end of the spectrum, if some three-D modeling language
needs a property for setting some aspect that's unique to three
dimensional objects, it clearly doesn't make sense to force all tools
to be aware of that property.

| 7) Section 1, par. 7. This paragraph contains an important point, that
| merits more emphasis. It is indeed very bad when two very similar
| terms, such as 'font-family' and 'fontFamily' occur in the same
| context (i.e.,  in the same style sheet). That invites errors by
| designers and bugs by programmers.
|
| Indeed, such a close likeness is much worse than having two completely
| unrelated terms for similar concepts, such as 'font-family' and
| 'svg-text-font'.

Well, I'm not sure the latter is more than marginally superior to the
former, but at least we can agree that the former is very bad indeed.

| That is why the CSS WG has prepared a document[3] (meant to be
| published as part of the CSS syntax module[4]), that talks about
| precisely this. Maybe it should be linked from the TAG article, or
| paraphrased in it.
|
| [3] http://www.w3.org/Style/Group/css3-src/css3-naming
| [4] http://www.w3.org/Style/Group/css3-src/css3-syntax

A set of design principles for choosing new names seems entirely
reasonable, though I expect that it may need to be elevated to a
coordination issue unless all WGs can easily agree to the principles.

| 8) Section 2. It is nice to see the cooperation between SVG, XSL and
| CSS called out explicitly, but it looks a bit out of place in a
| document that purports to give a timeless (well, let's say long-term)
| architectural guideline. Maybe it would read better if it was phrased
| differently: as an example or a case study of historical interest.

Perhaps.

| 9) Section 3. The conclusion reuses the word "consistent," but it
| 10) Section 3. Another important word in this section is

This section would benefit from some revision.

| 11) Hmm, these comments are longer than the article itself. Does that
| suggest something about the article?

Not to me.

| Maybe even that "consistency of
| formatting property names" is an interesting example of *something*,
| but not an architectural principle in itself?

Nope, doesn't suggest that to me at all. That a principle is short is
often a virtue.

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@Sun.COM    | Anything more than the truth would be too
XML Standards Architect | much.--Robert Frost
Sun Microsystems, Inc.  |

Received on Thursday, 15 August 2002 17:20:00 UTC