Re: XBL2 review

On Mon, 21 Aug 2006, Mihai Sucan wrote:
> 
> I have reviewed the XBL2 draft (21 august 2006 draft, directly from the 
> CVS) and I have the following comments to make:

Thanks!

> 0. General things
> 
> a)
> <style> in <resources>
> 
> How's this supposed to work? Is the provided style applied as if the 
> shadow content is a document by itself? Or is the style added to the 
> entire owning document, just like adding a new <style> in header? Or... 
> is the <style> applied as if the bound element is a document by itself?

In theory this is defined in section 5.10; is that not detailed enough?


> A general concern applies, as with CSS 3-stuff, SVG and newer 
> technologies which are not implemented in the dominant web browser (I 
> shall not name it, for the sake of helping the world forget its name :) 
> ). For now and, sadly, for a long time, such technologies are confined 
> to cutting-edge web sites, or to Intranet applications with a limited 
> target audience.

Yup. Not much we can do about this.


> 1. Introduction
> 
> In the example I see <style> in <resources>. Why no type="text/css"?

See below.


> Bad phrasing:
> 
> «The result of applying the XBL binding above to the HTML given able using
> the CSS given above is to equivalent to the result one would get if one simply
> placed the div element with class="nav" before the div element with
> class="main", but the effect is achieved without needing any changes to the
> markup.»
> 
> I don't understand what's exactly meant. Please rephrase.

Wow, I must have been asleep when I wrote that. Fixed.


> 1.2.1. Attributes Containing Selectors
> 
> «Note: This specification does not specify what level of Selectors support is
> required.»
> 
> Why?
> 
> If one UA claims support for XBL2 the author can't rely on the support of CSS
> 3 Selectors, practically rendering XBL2 support useless if no Selectors are
> supported. XBL2 specification should provide a list of required Selectors for
> claiming conformance. If not, we will endup with UAs doing something similar
> to IE 6: they added support for PNG, but they missed one of the "coolest"
> feature in PNG (transparencies).

It wouldn't help. PNG is a great example of this -- despite transparency 
being in the spec, IE still didn't implement it.

At the end of the day browsers are going to implement whatever level of 
Selectors they feel comfortable with. Selectors applies to much more than 
just XBL, it isn't up to XBL to decide what level of Selectors UAs should 
implement. Similarly, XBL doesn't require particular levels of XML or HTTP 
or CSS.


> 2.3. The implementation element
> 
> I personally don't exactly understand the syntax used in the provided
> example:"set memory(value)" and "get memory()". Why a space? Can somebody
> explain that?

It's from JavaScript 1.5.


> 2.9. The div element
> 
> I don't see the real use for the state attribute. There are other ways to do
> the same, and there's no real imperative need for yet-another attribute. It's
> defined as a stylistic hook, same as class. It's a duplicate attribute.

It's useful in complicated cases where you're using the class attribute as 
a way of denoting which element is which, but where the state changes a 
lot, for example where it's a percentage.


> 2.13. The style element
> 
> This should have a type attribute. The style-type attribute of xbl element
> would be only the "default type". Why not allow multiple types of styles in a
> single binding?

Why allow it? That would just be extra complexity for no good reason.

With the current model, UAs just have to check one place and can bail on 
all the styles in the <xbl> if it isn't a supported language.

What's the use case for multiple style languages within one binding?


> 2.14. The prefetch element
> 
> Suggestion: new attribute "condition". This should be an ECMAScript expression
> which if evaluates to true, the file is loaded. Some may want to prefetch some
> images based on various conditions.

You can do this today using <script> elements -- just add the <prefetch> 
elements you want dynamically.


> 2.15. The script element
> 
> This should have a type attribute. The script-type attribute of xbl element
> would be only the "default type". Why not allow multiple types of scripts in a
> single binding?

Same as for style, except even more so -- having multiple languages in one 
binding would be very complicated to specify and implement.


> 4.5. Binding Attachement Model
> 
> Why is the UA allowed to *act* as if it does the steps listed? What does
> acting mean in this context?

It means that the UA can implement the algorithms in whatever way is 
desired, so long as the end result is indistinguishable from the algorithm 
given. This allows UAs to make time/memory tradeoffs relevant to their 
platform.


> 5. Shadow Content
> 
> Recommended rephrasing from:
> «If a binding element that had no template element has a template element
> added, then a shadow tree must be generated.»
>
> ... to:
> 
> «A shadow tree must be generated when a template element is added to a
> binding element that had no template element.»

Good idea, done.

 
> 5.4. Processing content elements
> 
> The example starts with «Imagine the following simple document». I am not
> sure if that's appropriate, because I won't imagine anything. The provided
> example is result of what the author imagined. If I have to imagine something,
> I'd imagine something else.
> 
> I'd suggest switching from "imagination examples" to just examples: "Given the
> following document", then "Having the X element bound to...".

Removed imagination from this example.


> 5.7.4. The matching pseudo-elements
> 
> Until reaching this chapter I believed I can assign any pseudo-element, for
> use within CSS. Quite an interesting concept, at first.
> 
> Reading this chapter I reached the conclusion this is much like the state
> attribute for the div element. Instead of using the provided list of
> psuedo-elements, one can use class names (icon/value/choices...). Even the
> provided example emphases that, for me, at least.

Not sure I understand.


> 6.4. ECMAScript bindings
> 
> «First, if this is the first time the binding defined by that binding element
> is used since that binding document was loaded, then, if that element contains
> an implementation element, then the first such element must have its code
> compiled and run (see below), and the return value of that script, if any,
> must be forever associated with that binding element as that binding's
> implementation prototype object.»
> 
> This very lengthy phrase is hard for one to understand. I recommend a better
> wording. I have no suggestion, since a correct rephrasing requires accurate
> understand, and I myself don't feel confident enough to say "yeah, I know what
> he meant".

I tried to make this clearer.


Thanks for your input!
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'