Re: storing info in XSL-FO: new issue? [was: Draft TAG Finding:...]

On 8/16/02 7:05 PM, "Elliotte Rusty Harold" <elharo@metalab.unc.edu> wrote:

> 
> At 3:09 PM +0200 8/16/02, Hċkon Wium Lie wrote:
>> Also sprach Elliotte Rusty Harold:
>> 
>>> I do not think XSL-FO is any more or less semantic than HTML.
>> 
>> Really?
>> 
>> How do you express that some text is a headline in XSL-FO? Or that
>> some string is a variable?
>> 
> 
> As it happens, when I read this message I had the Mercury News open
> in a browser window, so I looked at how they expressed headlines in
> HTML:
> 
> <a 
> href="http://ae.bayarea.com/entertainment/ui/bayarea/restaurant.html?id=60966&
> reviewId=11135" 
> class="headline">Pizza heaven</a>
> 
> This does not seem all that far removed from
> 
> <fo:basic-link 
> external-destination="http://ae.bayarea.com/entertainment/ui/bayarea/restauran
> t.html?id=60966&reviewId=11135"
> role="headline">Pizza heaven</fo:basic-link>
> 
> The New York Times does it a little differently:
> 
> <font FACE="Times New Roman,Times,Serif" SIZE="+1"><strong>Baseball
> Players' Union Sets Strike Date for Aug. 30</strong></font>
> 
> This is even easier to reproduce in XSL-FO:
> 
> <fo:inline font-face="Times New Roman,Times,Serif" font-size="120%"
> font-weight="bold">Baseball Players' Union Sets Strike Date for Aug.
> 30</fo:inline>

So you're saying that instead of encouraging better practices on the web, we
should introduce/legitimize more complicated ways of encouraging current
poor practices?

For details on why these current practices are poor, and what better
practices are, just read WAI-CAAG.

 http://www.w3.org/TR/WAI-WEBCONTENT/


>> Consider one example from Braille renderings. Since Braille characters
>> use much space, words are often contracted to fit more text on one
>> page. However, some words -- for example program variables -- should
>> not be contracted. HTML gives you the ability to express this (using
>> the VAR element) and this is crucial to improve Braille renderings.
>> XFO, on the other hand, gives access to the text but information that
>> can be used to decide if a word can be contracted or not is lost.
> 
> Interesting. I wasn't even aware of the VAR element. I wonder how
> many web developers are? And how many use it for its intended purpose?
> 
>> The sematics of HTML may be shallow, but it's just enough to enable
>> non-visual presentations which is critical for universal
>> accessibility.
> 
> XSL-FO contains all the aural properties of CSS.

You completely miss the point.  The point is that non-visual presentations
are possible from the semantics of current HTML elements, WITHOUT the author
having to provide specialized markup for each non-visual presentation.


> It is no more 
> limited to visual presentation than HTML is (which is to say, in
> practice, it's quite tied to visual layout).

This (along with your comment about VAR) sounds like you think of HTML as
folks did in the HTML 3.2 days.

Perhaps you should take a look at XHTML 1.1, XHTML Basic, and the draft of
XHTML 2.0.


> I understand the 
> theoretical point that HTML does not have any official layout model,
> unlike XSL-FO and SVG. However, the implicit layout model enforced by
> Web browsers is so strong that it renders the point moot.

Not at all true for XHTML Basic for example, which has very little in the
way of presentation (deliberately so).

What you're saying may be true for _desktop_ browsers displaying HTML4.  For
alternative devices (handhelds, tvs, phones etc.) your statement is
completely false.


> HTML is a 
> layout language, a less powerful one than XSL-FO to be sure, but
> still a layout language. DocBook it is not.

No, it's not DocBook.  It's simpler.  HTML is an easy to learn language for
marking up hypertext documents with relatively simple structure, which
happens to be 90%+ of documents.

HTML 3.2 was a part-layout, part-semantic language.  HTML4 Transitional was
similarly so.  HTML4 Strict was much much less so.  XHTML Basic hardly has
any required presentation at all.  XHTML 2.0 has almost none (and we're
working on eliminating the few remaining bits).

This transition was enabled by the decision early on to separate out
presentational hints from the markup and put them in style sheets.  Others
have done a far better job of documenting all the advantages (size, speed,
accessibility, portability, device independence, media independence,
user-customization/adaptation etc.) of doing so.

> In 2002 anyone who thinks an H1 element really means anything other
> than "Make this a big, bold, block level element" is kidding
> themselves.

I think you meant to write "In 1996...".

Or perhaps you wish to argue with WAI-CAAG:

 http://www.w3.org/TR/WAI-WEBCONTENT/#tech-logical-headings

"3.5 Use header elements to convey document structure and use them according
to specification. [Priority 2]
For example, in HTML, use H2 to indicate a subsection of H1. Do not use
headers for font effects."


Nice to know that you think W3C's accessibility efforts are "kidding
themselves".


> The L in HTML stands for "Language". HTML evolves as all
> languages do. The meaning of its words is defined by its speakers.
> HTML has escaped the ivory tower of semantics, and been vulgarized as
> successful languages always are. The prescriptions of the W3C have
> about as much affect on HTML as the prescriptions of the Académie
> Française have on French (that is, little to none).

So we should stop work on any new markup languages at all at W3C, because
the "speakers" are defining markup language evolution?  Your arguments in
this message could be rephrased as - why bother with XSLFO when you have
HTML already widely adopted?


Tantek

Received on Friday, 16 August 2002 23:03:14 UTC