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

Re: XBL2 review

From: Mihai Sucan <mihai.sucan@gmail.com>
Date: Wed, 23 Aug 2006 15:52:44 +0300
To: "Ian Hickson" <ian@hixie.ch>
Cc: public-appformats@w3.org
Message-ID: <op.teql16abmcpsjgr0b0dp@localhost.localdomain>

Le Wed, 23 Aug 2006 02:30:48 +0300, Ian Hickson <ian@hixie.ch> a écrit:

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

Maybe a bit of "easy to read" prose like mine above would help, something  
like a non-normative summary/overview.  What I wrote above took me reading  
a few chapters two-three times (lots of terms and definitions to keep up  
with).

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

My reasoning was that <content /> has apply-binding-sheets to false, and  
because of that the <style> .my-class cannot affect in any way the nodes.  
Something like sandboxing.

Continuing from the above:

  <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>
        .my-class { color: blue }
        title { display: block }
       </style>
      </resources>
     </binding>
    </xbl>
   </head>
   <body style="color: green">
    <div id="my-elem">A
     <p>B</p>
     <p>C</p>
     D
    </div>
   </body>
  </html>

According to what you said: 1 4 would be green, 2 ABCD 3 would be blue.  
Correct?

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

Let me get this right: will :root match <html> from that <style>? If yes,  
that means in the new sample code ... <title> would show up?

Is the <style> within one binding allowed to affect the outside?

* * *

See, I understood this part of the spec (above you agreed with my  
understanding), however, these "small" details are not explicitly defined  
by the spec. Maybe you should add further details, clearing the points we  
are discussing in this thread.

IMHO, it's rather confusing how all these styling stuff works. The  
scripting and DOM parts seem more straight forward. Adding to confusion is  
even the xbl:pseudo which is allowed irrespective of apply-author-sheets.  
I understand the reasoning, but I'm sure all this will give some headaches  
to web devs who'll try to use XBL2 in big projects. If not headaches, at  
least unexpected results / surprizes.

A possible solution is simplification of the styling part (would this be  
too late?).

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

True, true :) .

>> I believed I can use xbl:pseudo="any-value" then :any-value from CSS.
>
> Oh, I see. Yeah, I should list the values. Fixed.

Better.

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

Do you guys want to have enough features in XBL2 for implementing XForms?

That should be just a bonus, not one of the purposes/targets.

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

Oops, my mistake. How about this:

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

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.

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


-- 
http://www.robodesign.ro
ROBO Design - We bring you the future
Received on Wednesday, 23 August 2006 12:53:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:10:20 GMT