CSS Flow Objects in XSL [WAS: RE: HTML Flow objects that span rules]

Subject: CSS Flow Objects in XSL [WAS: RE: HTML Flow objects that span rules]
From: "Andrew n marshall" <amarshal@xxxxxxx>
Date: Wed, 22 Apr 1998 07:31:23 -0700
> -----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.

Andrew n marshall
  student - artist - programmer
      "Everyone a mentor, Everyone a pupil"

Current Thread