XSL-FO chapter from XML Bible updated

I'm happy to announce that I've posted an updated version of Chapter 
18 of the XML Bible, XSL Formatting Objects, at Cafe con Leche:

http://www.cafeconleche.org/books/bible2/chapters/ch18.html

This is the complete chapter, approximately 70 pages with many full examples
of XSL-FO. Everything should now be up-to-date with the November 2001 
Recommmendation of the XSL-FO specification and FOP 0.20.4.  Mostly 
the changes were fairly minor, just changing the master-name 
attribute to the master-reference attribute on about four elements. I 
also updated the FOP coverage to version 0.20.4, and fixed a few 
minor errors where I noticed them.

--

-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo <at> metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|          XML in a  Nutshell, 2nd Edition (O'Reilly, 2002)          |
|              http://www.cafeconleche.org/books/xian2/              |
|  http://www.amazon.com/exec/obidos/ISBN%3D0596002920/cafeaulaitA/  |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
+----------------------------------+---------------------------------+

Re: Draft TAG Finding: Consistency of Formatting Properties

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

css selectors

I think that there is a need for a selector in CSS, which selects an
element of a certain type which directly precedes an element of another
type. Already in CSs we can specify E+F which matches element F directly
following element E, and this would work along the same lines, something
like E-F would match an F element directly before an E element.

Perfect example of why this is needed:

Take a set of blockquotes. Now the generally held typography rule is that
every one should have a starting quote, but only the very last one from
the same source should have an ending quote. Currently, the only way you
could specify this would be to give every blockquote only a quote at the
start, and then use a class on the last blockquote and blockquotes of that
type would receive an ending quote as well. However this could very
quickly get tedious, especially when you're putting up single blockquotes
at a time.

If you had the E-F selector, you could simply use the rules:

blockquote {
	quotes: '"' '"';
}

blockquote-blockquote {
	quotes: '"' '';
}

blockquote:before {
	content: open-quote;

Re: css selectors

> Take a set of blockquotes. Now the generally held typography rule is that
> every one should have a starting quote, but only the very last one from
> the same source should have an ending quote. Currently, the only way you
> could specify this would be to give every blockquote only a quote at the
> start, and then use a class on the last blockquote and blockquotes of that
> type would receive an ending quote as well.

Isn't the rule you cite for multiple paragraphs within a single
quotation as opposed to for multiple separate quotations in a row?  I
would think that:

blockquote > p {
  quotes: '"' '"';
}

blockquote > p:before {
 content: open-quote;
}

blockquote > p:last-of-type:after {
 content: close-quote;
}

would be what you would want... (and is perfectly doable within the
scope of the existing CSS3 Selectors module).

Not to say that the selector you propose is not useful, but I think this
use case if flawed.

Re: css selectors

On Mon, 8 Jul 2002, Boris Zbarsky wrote:

>blockquote > p:before {content: open-quote;}
>blockquote > p:last-of-type:after {content: close-quote;}

That won't do the trick. How about

<blockquote>
<p>thing
</p>
<p>thing2
</p>
<table>
<!-- [...] -->
</table>
<p>
</p>
</blockquote>

?

Sampo Syreeni, aka decoy - mailto:decoy <at> iki.fi, tel:+358-50-5756111
student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

New spec: media queries

I'm happy to announce that the "media queries" draft is no longer a
draft, but a "Candidate Recommendation" (CR).

    http://www.w3.org/TR/css3-mediaqueries

It is not quite a "standard" yet, but it is close. Calling it a CR
means that W3C believes it is stable and ready to be implemented. It
will go to the next step, "Recommendation," when there are sufficient
implementations to prove that we were right. Or, of course, we may be
proven wrong by lack of products or by complaints from implementers...

So, please, if you can, try to implement media queries in software and
use them in style sheets. And let this mailing list know the results.

We expect to keep the specification in Candidate Recommendation state
for at least six months. After that we'll see if we need to keep it
there longer, if it is ready to go to Recommendation or should be
dropped or redesigned.

We are slowly learning to deal with Candidate Recommendations (a
relatively new type of document in W3C's process). This one has a few
niceties that previous CRs didn't have: the "exit criteria," which the
working group wants to be met before it will propose the spec for
Recommendation, are included in the document itself; there is a link
to the comments that we received on the last draft; and there is a
link to a page that will eventually hold statements by W3C members
about any patents and licenses (hopefully all "royalty free") that
apply to CSS.

Re: New spec: media queries

Bert Bos <bert <at> w3.org>:
>
> I'm happy to announce that the "media queries" draft is no longer a
> draft, but a "Candidate Recommendation" (CR).
>
>     http://www.w3.org/TR/css3-mediaqueries

"Pixelschubser"[1] will love this one, once it gets implemented -- I'm
afraid we'll see a lot pages with CSS for two screen sizes (1024×768px and
800×600px probably) with color support and nothing else. It may also become
a handy way to hide badly degrading CSS3 files from older [i.e. current]
browsers.
One thing made me wonder: What's the correct display-height and
display-width for virtually enlarged desktops? Say a 2048×768px area mapped
to a screen displaying just 1024×768px.

Small errors I noticed:
* 2. - ordered list, first item: the period is misplaced.
* 3.1. - table, first row, third column: <del>the</del>.
* 4. - example triplet: The three examples are not HTML, XHTML and XML, but
XML, XHTML and CSS. In the middle code sniplet 'rel="stylesheet"' appears
twice.
* In the source "<pre><span ...>" is used where one (i.e. I) would expect
"<pre><code ...>".

[1] There's no suitable translation I'm aware of for those people loving
blind GIFs, layout tables and CSS positioning.

Christoph Päper

CSS in XML format ?

Re: CSS in XML format ?

> I would like to do convert strict XHTML + CSS documents to some other 
> format using XSLT. In order to do so, interpreting the stylesheet 
> information during this transformation is essential.Unfortunately, the 
> CSS syntax is very hard (to use a euphemism) to interpret with XSLT.
>  
> Is there an initiative to have CSS use XML syntax ? I understand that 
> when CSS 1 was first proposed by Bos & Lie XML was not around, but why 
> not plan a transition towards XML syntax ?

Patrick,

XSL is already in XML format, while CSS has it's own unique one. I find 
the syntax of CSS to be much much more intuitive for what it does, and 
would strongly object to it being rewritten in xml. Apasrt from anything 
else it would be much more verbose, and harder to learn. I also believe 
it'd be less intuitive, create much larger file sizes than necessary, 
and of course it wouldn't work in current browsers which already do a 
good job interpreting it as it is.

If the presentation is that important that you need to use it when 
you're transforming I recommend you use XSL, however I'd take another 
look at what you're doing. CSS is purely presntational, whereas XML 
languages are meant to describe what they're marking up -- not suggest 
how to mark it up (apart from XSL obviously).

--

-- 
Lach
__________________________________________
http://members.evolt.org/luminosity/
MSN: luminosity  <at>  members.evolt.org
__________________________________________

Re: CSS in XML format ?

----- Message d'origine -----
De: "Lachlan Cannon" <luminosity <at> members.evolt.org>

>
> > I would like to do convert strict XHTML + CSS documents to some other
> > format using XSLT. In order to do so, interpreting the stylesheet
> > information during this transformation is essential.Unfortunately, the
> > CSS syntax is very hard (to use a euphemism) to interpret with XSLT.
> >
> > Is there an initiative to have CSS use XML syntax ? I understand that
> > when CSS 1 was first proposed by Bos & Lie XML was not around, but why
> > not plan a transition towards XML syntax ?
>
> Patrick,
>
> XSL is already in XML format, while CSS has it's own unique one. I find
> the syntax of CSS to be much much more intuitive for what it does, and
> would strongly object to it being rewritten in xml.

Yes, I have heard this argument. Right now, having to convert it, I'm not at
all convinced of its strength...

I see two schools of thought : the style sheet syntax must be terse and
intuitive for human conception or the style sheet syntax should be in XML to
be easily processable, verbosity is of no consequence since style sheets are
more and more produced automatically or through an GUI interface (my case at
least).

> Apart from anything
> else it would be much more verbose, and harder to learn. I also believe
> it'd be less intuitive, create much larger file sizes than necessary,
> and of course it wouldn't work in current browsers which already do a
> good job interpreting it as it is.

I did say transition, I don't see why one version of CSS could not be
expressed using both syntaxes while mentioning that XML will become the
future standard syntax.

> If the presentation is that important that you need to use it when
> you're transforming I recommend you use XSL,

You mean FO ? Unfortunately, I do not control the XHTML that I need to
convert automatically. And these many files (constantly new ones are being
created by the customer) use CSS !

P. A.
-----------------
Unicode en français
(tout le texte normatif, annotations, tous les noms de caractères 3.2)
http://hapax.iquebec.com