> -----Original Message-----
>
From: Chris Maden
> Subject: Re: HTML Flow objects that span
rules
. . .
> Flow objects must be atomic within their
construction rules. They are
> *objects*, not tags. This is
the main reason I don't like the so-
> called "HTML Flow
Objects"; using the syntax '<tr>' to mean "create
> the
flow object whose HTML representation begins with the string
>
'<tr>'" has the strong and intuitive implication that one is
>
generating markup, not objects, and this is exactly where Ed has
> gotten
confused.
I think it would be appropriate to replace flow classes
<DIV> and <SPAN> with their corresponding names in the 'display'
property: <block> and <inline>. This would help alleviate the
confusion the existing tags have created. To would also help define a
future direction for XSL with respect to CSS flow objects (that being the
inclusion of new flow objects <run-in>, <compact>, and maybe
most of the table related display options; 'marker', 'list-item',
and 'none' are redundant within the XSL syntax).
In my opinion, this
association is what makes XSL most powerful. The CSS working group have
worked very hard to define a strong flow class hierarchy. The predominant
things that have limited them have been the strong association with the HTML
structure, the lack of transformation capabilities, and a syntax that struggles
to deal with necessary concepts such as element selection (resulting in a
somewhat obscure and very detail oriented notation) and generated content
(resulting in the :before and :after pseudo-elements and the 'counter-*'
properties).
XSL does a good job of handling these
short-comings, but lacks a specific set of flow classes. The original
editors of XSL proposed the DSSSL-O flow classes. While these classes
provide a rich set of classes for visual design, they are not have a wide
support in web design circles. In addition, they fail to deal with some of
the issues modern online documents must deal with, such as the capability to
present themselves on non-2D devices, such as aural streams. DSSSL-O
objects also introduce some concepts to the web that are already handled by
other means, such as the Link flow object for which the <A> tag and the
XLink spec already cover more thoroughly.
Here are some issues I think this
integration brings up for the XSL working group:
- What
aspects of CSS flow object properties are already managed by XSL? This is
necessary to describe the specific flow objects that should be implemented by
XSL as a standard. For example, 'content' and 'counter' properties can be
generated in XSL in other ways.
- Conversely, what aspects of CSS cannot be accomplished
with XSL? For instance, CSS have introduced the concepts of pseudo-element
and pseudo-class to select aspects of the document that are described in the
grove/document tree.
- How can a designer specify
different flows for different mediums? CSS attributes include hooks for
capabilities such as aural presentations. Is there a need for a
<rule-group> that enables/disables rules based upon characteristics of the
user agent such as predominate media and language (correlating to CSS's @media
rule, '|=' selection operator, and ':lang' pseudo-element). I would assume
this is especially necessary for providing specialized structural
transformations for alternative mediums, something that CSS can
do.