Re: XBL2 review

Le Tue, 22 Aug 2006 02:55:11 +0300, Ian Hickson <ian@hixie.ch> a écrit:

> 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!

You're welcome.

>> 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?

Yes, it's explained. However, due to the complexity of XBL2 one can truly  
understand only in practice.

Based on my understanding: the <style> is applied only to the bound  
element and its shadow content that was generated by the attached  
bindings. Also, the <style> is applied to explicit children whose  
<content> apply-binding-sheets is set to true.

Continuing from the above, author sheets (styles from the bound document)  
are applied to the shadow content only if apply-author-sheets is set to  
true for the <template>.

Last, but not least, one can use author sheets to change the style of  
elements in the shadow content, as long as it matches them with  
pseudo-elements predefined by the XBL2 spec, irrespective of  
apply-author-sheets setting.

Let me know if this is correct.

Given an UA which implements :root CSS3 selector, and having the following  
code:

<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
   <title>Demo</title>
   <xbl xmlns="data:,520e273a-62ad-4528-bb1e-9652bda76d62">
    <binding element="#my-elem">
     <template>
       1
       <div class="my-class">
        2 <content /> 3
       </div>
       4
     </template>
     <resources>
      <style>
       :root { color: green }
       .my-class { color: blue }
      </style>
     </resources>
    </binding>
   </xbl>
  </head>
  <body>
   <div id="my-elem">A
    <p>B</p>
    <p>C</p>
    D
   </div>
  </body>
</html>

... how would the above render? Which is the :root? Which becomes green?

IIANM: 1 4 should be green, 2 3 should be blue, and A B C D should be  
black. If I set apply-binding-sheets="true" for <content />, then A B C D  
should then be blue too.

>> 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.

Good it's now fixed.

«The result of applying the XBL binding above to the HTML given above  
using the CSS given above is equivalent to the result one would get if one  
simply placed the div element with class="nav" before the div element with  
class="main".»

It's definitely better, but ... I would recommend:

«The result of all the code given above is equivalent to the result one  
would get if one simply placed the div class="nav" before the div  
class="main".»

This, IMHO, makes up for even easier reading.

>> 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.

Good point, yet I am not convinced. The PNG spec makes transparency  
optional, starting even from the short description at the beginning of the  
document.

Making Selectors "optional" is almost the same...

Not much I can add.

>> 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.

I looked over at developer.mozilla.org, but I didn't find this. Link?

>> 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?

True, this adds extra complexity.

It's minor complexity compared to the big complexity of implementing XBL2  
itself.

>> 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.

This suggestion came from VoiceXML-experience. :)

>> 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.

I don't completely agree.

An UA with several script implementations (e.g. Perl, Python and  
ECMAScript), will ensure "interoperability" between them. AFAIK Mozilla2  
is aiming for a Python implementation. Will they force a document to use  
*only* Python or *only* JS? Yes, it's complicated to get the two seemingly  
working in the same document, but this is not related to XBL2, CSS, XML,  
HTML, nor HTTP.

XBL2 should, at least, optionally allow combining several style types and  
script types. The specification should allow an open door for future  
versions which might define how. At the moment, there's no need to do so.

I'm just saying that XBL2 shouldn't close the "eyes" on future  
possibilites.

Extra complexity is not a very good argument for me, since DOM, SVG, JS,  
CSS, X+V, XML Events, already add huge complexity. If complexity would be  
a problem, XSLT, MathML, nor XBL2 would be implemented.

>> 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.

There's also the second example, which repeats "imagine" 3 times: each  
aligned on the left, as the first word in the sentence (for visibility?).  
If you want, leave it as it is, for diversity :).

>> 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.

No problem. Let me try to explain again.

I believed I can use xbl:pseudo="any-value" then :any-value from CSS.

Only reading chapter 5.7.4. I found out I can't use any value, just the  
predefined ones. However, the predefined ones are not a "big deal".  
xbl:pseudo only adds complexity with no obvious benefit (IMHO). E.g.  
instead of xbl:psuedo="icon" the author can use class="icon".

Maybe you can elaborate on the benefit of having xbl:pseudo.

What I like about CSS psuedo-stuff is they provide the means to style  
something "inexisting" in code, such as :first-letter, :first-line. It  
also provides "shorthands" for matching elements :first-child,  
:last-child, :first-of-type, etc. xbl:pseudo takes another path, turning  
pseudo-stuff into something as "graspable", as "simple" as a class name.

I'm not sure I can explain this any better.

>> 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.

Yes, it's better: now I understand what it says. Again, there's a "but"  
... I recommend rephrasing, for making it even easier to understand:

From:
«1. If this is the first time the binding defined by that binding element  
is used since that binding document was loaded, and if that element  
contains an implementation element, then:

   1. The first implementation element child of the binding element must  
have its code compiled and run (see below).
   2. The return value of that script, if any, must be forever associated  
with that binding element as that binding's implementation prototype  
object.

Otherwise, if the binding element doesn't contain an implementation  
element, or if it does but it does not evaluate to an object, then an  
empty object must be created (by invoking the Object constructor in the  
global scope of the binding document), and the binding element's  
implementation prototype object must be forever set to that object.»

"that binding element" in the first phrase doesn't sound right to me. It  
somehow implies I know which binding element, "that one!".

Also, the word "binding" seems overused.

To:

«1. The first implementation element child of the binding element must  
have its code compiled and run (see below). The return value of the  
script, if any, must be forever associated as the binding's implementation  
prototype object.

Note: The implementation prototype object is created only the first time  
the binding is used, after the binding document has loaded.

Otherwise, if there is no implementation element, or if it does not  
evaluate to an object, then an empty object must be created (by invoking  
the Object constructor in the global scope of the binding document) and  
forever associated as the implementation prototype.»

I'm not sure if this is good for copy/paste. Maybe you can continue from  
this.

> Thanks for your input!

You are welcome, and thanks to Anne for reminding me about XBL2.


-- 
http://www.robodesign.ro
ROBO Design - We bring you the future

Received on Tuesday, 22 August 2006 18:14:11 UTC