W3C home > Mailing lists > Public > public-appformats@w3.org > August 2006

Re: XBL2 review

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 22 Aug 2006 23:30:48 +0000 (UTC)
To: Mihai Sucan <mihai.sucan@gmail.com>
Cc: public-appformats@w3.org
Message-ID: <Pine.LNX.4.62.0608222227140.13239@dhalsim.dreamhost.com>
On Tue, 22 Aug 2006, Mihai Sucan wrote:
> 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.

It is exactly 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?

Nothing would match the :root. 2, A, B, C, D, and 3 would be blue (by 
inheritance from the <div>). 1 and 4 would be black.

> Which becomes green?

None. The only element that matches :root in the document above is the 
<html> element.

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

Fair enough. Changed.

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

I agree that it is a problem. I just don't see that making the spec say 
something or other would solve the problem.

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

First hit for "javascript 1.5" on Google:


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

Sure. But it's still extra complexity. Everything we can do to make things 
simpler helps a little.

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

It's more complicated if a single binding can have a mixed language 
runtime. In particular, I don't know how you'd handle the JS 
"implementation object" dichotomy when half the binding handlers are in 
perl, for example.

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

It would be easy for a future version of the spec to extend into having a 
type attribute on <script> and <style>.

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

Sure. I don't think that anything is being closed here though.

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

Existing complexity is not an argument for unnecessary complexity.

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

I changed the first of those to "Consider". The other two seem reasonable 
since it really is asking you to imagine something not shown. :-)

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

Oh, I see. Yeah, I should list the values. Fixed.

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

It's to allow XForms to be implemented in XBL2. XForms documents rely on 
these pseudo-elements for styling.

It also allows binding authors to let document authors style specific 
parts of the binding without letting them access the entire binding.

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

Notes are non-normative (not official requirements of the spec) so this 
change would change the meaning of the spec.

I'm not sure how to make it better without this problem.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 22 August 2006 23:31:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:05 UTC