Fw: Heretical view

["Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>]

Guy_Murphy@xxxxxxxxxx wrote:
>I might well be missing something, but I don't see the difference with
>regard to dynamic mainupulation of a document between HTML FOs and XSL FOs.
>With dHTML you have to scope the elements you're interested in manipulating
>either *this*, by indexing a collection, or by ID. You can surely scope XSL
>FOs in the browser by the same methods, and then change the FO as you seem
>fit.


But you lose the DOM object for the stylesheet itself, which allows you to
manipulate all such objects at once.

>Working on the assumption that I am missing something fundamental in your
>arguement can you give a more specific example of the problems you foresee.
>Can I not simply manipulate FOs dynamically.... I need to take a closer
>look at the rec this weekend I think.


Here's an example. I'm using it to avoid flicker when I'm loading complex
Web pages in IE:

<STYLE ID="EverythingStyle" TYPE="text/css">
.EVERYTHING {
    visibility: hidden;
}
</STYLE>
<SCRIPT LANGUAGE="JavaScript">
function whenReady() {
    // I'd rather use a more DOM-like interface here, such as:
    // document.all.EverythingStyle.visibility = 'visible'.
    // The following is what works for IE, however:
    document.all.EverythingStyle.addRule("visibility: visible; ");
}
</SCRIPT>

The "EveryoneStyle" is applied to, well, everything. Initially no element on
the page is visible. This allows me to do some processing to cover up for
IE's many flaws and bugs of implementation. I can, for example, scroll and
zoom images by dynamic code, adapt font sizes to percentages of the boxes
they are contained in, and in general have fun with the DOM. If elements
were visible at this stage you'd see a flicker as IE would be desperately
racing to reflow the page for every change.

When I'm finally ready I access the style sheet itself - and here is the
crucial difference between FOs and CSS - and change the visibility value.
All the elements appear at once, properly configured. No flicker.

This is just an example - you might claim an esoteric one - for what you can
do when you can manipulate the style sheet itself via the DOM. More
conventional examples are just effecting the way a whole class of elements
is displayed - for example, causing all file elements in a tree view to
disappear, or highlighting all references to a certain topic inside a text,
and so on.

This is why I'm not comfortable with http://www.w3.org/TR/NOTE-XSL-and-CSS -
they want to simply replace <fo:*> with <css:*>. I see this as giving up a
crucial capability provided by CSS. Instead, I'd rather they adopted
approach #2, with HTML being a special case (via Voyager, say). My bet is
that browser implementers would be able to support it with very little
work - this is _just a new input syntax_ for existing functionality. Just
replace:

<style type="text/css">
Non-XML text syntax
</style>

With:

<css:stylesheet>
XML syntax for the above
</css:stylesheet>

And:

<AnyHtmlElement STYLE="Non-XML text syntax">
...
</AnyHtmlElement>

With:

<AnyHtmlElement>
    <css:style css-attribute="value" .../>
    ...
</AnyHtmlElement>

Choosing the XML syntax to preserve the DOM access patterns for the style
elements.

I'm interested in your comment that print people are horrified by the
prospect of using CSS instead of FO for printing. Surely writing:

<Chapter>
    <css:style some-attributes...>
</Chapter>

Instead of:

<fo:block some-attributes...>
...
</fo:block>

Isn't enough, by itself, to cause this reaction. So I guess their problem is
with the rendering model supported by CSS - the particular list of
attributes - which admittedly isn't up to high-quality printing. Well then,
why don't we make use of the excellent work done in specifying the FO
objects and attributes and simply insert them into CSS2?

If, on the other hand, the reason is the horrible implementations of CSS out
there, well, it becomes a psychological problem more then a technical one.
The W3C is supposed to be a group of "heavy weight" companies - surely they
can overcome such a problem.

Share & Enjoy,

    Oren Ben-Kiki


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list