Cart
|
[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] CSS Flow Objects in XSL [WAS: RE: HTML Flow objects that spa
 > -----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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
