At 04:40 PM 12/27/2002 -0500, L. David Baron wrote:
>> >A number of markup languages have elements whose expected rendering is
>> >far too complicated to be described by CSS at present. The best example
>> >of such elements at present is form controls (both in HTML and XForms).
>>
>> Agreed that not all properties of those elements are exposed in CSS.
>> However, many CSS properties do often apply such as font, border, etc..
>
>I can think of three different ways the 'border' property might apply to
>an INPUT with type=button (outside the normal input control, as a
>substitute for the edge of the button that gives it the raised look, or
>around the text of the button). Applying 'width' to SELECT is worse.
That is why we agreed in our last exchange, that it would be better if the
styles were applied to the content tree, rather than at the abstract
content markup layer. I will remind you below about you wrote and what I
responded:
>>Since form
>>controls can't currently be defined in terms of the CSS formatting model
>>the effects of many (or all, I claim) properties are undefined.
>>Interoperable stylability of form controls requires either listing the
>>meaning of every CSS property for every form control or a general
>>mechanism to reduce the form controls to simpler components. I prefer
>>the second approach.
>
>This is also what I was proposing. With XSLT the abstract widget gets
> transformed into a content tree of normal XHTML elements which can then
> be styled with existing CSS properties. We can do this today and work
with
> all major browsers!
>> Remember that CSS is an optional layer that should not be relied upon,
>> unless one wants to be presentation (browser and browser configuration)
>> dependent.
>
>True. CSS may not be the best way of binding XBL, at least for some
>uses.
I think may have missed part of my point. You were writing about the
ability to style Forms and lamenting the lack of Forms-specific CSS
properties. You wrote that for interoperability, then you preferred a
"mechanism to reduce the form controls to simpler components". I agreed
with that and said that XSLT can provide the mechanism. And I also pointed
out that from interoperability perspective, CSS properties on Forms are not
to be relied upon (interoperability by definition meaning not presentation
dependent).
>> Also note that HTML DOM is a legacy markup, which will be maintained.
>
>I have no idea what you mean here or what it has to do with anything I
>said.
You deleted the context of what I wrote. In any case, you were writing
about the abiliting to manipulate form elements in the HTML DOM. Please
realize that those are not exposed in DOM core. They are specific to
legacy design of HTML. This is to say that having presentation layer
properties in HTML DOM is not the most OO way of authoring content, and
thus DOM core will not likely ever expose these (according to post from Ray
Whitmer in the references I cited in my original post). And there will
likely be other superior ways to abstract the presentation layer
properties. An example being .selected property.
Understanding this point is central to understanding why using XSLT and
orthogonal design is crucial if you want to produce content with the
longest lifespan.
Believe me when I say that I do not live and work in some academic vacuum,
that I produce real code, that works real well and fast in the real world
solving real problems for real users. I am not here proposing abstract
dreams. There will come a time soon where I will take these abstract
points and show real working implementation. If you can not visualize it,
then I understand it is difficult to convince you. I can only hope you try
to appreciate the benefits of orthogonal design. If you assume it means
slow and unrealistic implementation, then I disagree.
>> That is precisely why making good orthogonal design decisions is so
>> crucial. As I explained above, XSLT is browser independent because it is
>> based on orthogonal design. XBL and XUL is imo "spagetti" (non-orthogonal,
>> merging of layers) design which will delay wide implementation forever
>> (unless of course you believe that you only need Mozilla).
>
>This (and the comments before it, which I cut) are missing the point of
>my previous message. Believing that things will work adequately (i.e.,
>be fast enough for real users to use) if you use general solutions at
>every layer is not realistic.
XSLT is merely a transforming parser. The slowness only depends on how
much power you use. I would doubt that the kind of transformations I am
proposing (which are mostly templated search and replace) would account for
more than a few % of overall speed of processing a document. And I doubt
it is significantly more resource intensive than XBL.
> One of the reasons Mozilla is/was slow is
>that it has done things exactly as you suggest, and used general,
>available solutions to problems rather than coming up with specific
>solutions more tailored to its needs.
It may have been just poor design and programming. I do not have time to
figure out Mozilla's problems. I'd rather move on doing code that works.
Imo, it is myopic to judge W3C standards in terms of Mozilla's experience.
Please stop asking me to relate my proposal to Mozilla's past performance.
It is quite clear already that I do not hold Mozilla project in high
esteem. If you have experience that says using XSLT will be slower than
XBL then please give those facts. Else this whole discussion just
digresses into a political one.
You did not respond to my point that using XSLT completely removes the
browser dependency. Unlike XBL, it will work on the other 99% of user
clients today.
>While it is a good idea to begin with general solutions when they might
>be adequate rather than prematurely optimizing, I find it hard to
>believe that retransforming an entire document
What is XSLT doing that XBL isn't doing in that regard? It is the same.
They both look for some abstract markup element and replace it with a
content tree.
> and redoing the layout of
>the entire result document (something that is already known to take a
>few seconds or more for complex pages) for any DOM manipulation would
>have acceptable performance for some of the more complex pages on the
>web today.
Afaik, XSLT transformations happen before XHTML DOM. The layout is only
rendered once. Whether Mozilla is using XSLT in some other way that merges
it with another layer that thus requires re-rendering, would be a problem
Mozilla created for itself.
-Shelby Moore