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

Re: XBL2 review

From: Mihai Sucan <mihai.sucan@gmail.com>
Date: Fri, 25 Aug 2006 13:40:54 +0300
To: "Ian Hickson" <ian@hixie.ch>
Cc: public-appformats@w3.org
Message-ID: <op.tet5ag14mcpsjgr0b0dp@localhost.localdomain>

Le Fri, 25 Aug 2006 01:25:31 +0300, Ian Hickson <ian@hixie.ch> a écrit:

>> 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).
>
> Done (mostly using your text).

Thanks!

>> Is the <style> within one binding allowed to affect the outside?
>
> No (except using apply-binding-sheets).

Oops, here!

This is news to me. I didn't know apply-binding-sheets means the <style>  
in a binding is applied to the entire bound document. If you say <title>  
and <html> can be styled from a <style> in a binding *if*  
apply-binding-sheets is set to true, this means exactly that  
apply-binding-sheets makes <style>s to be applied to the entire bound  
document.

What I understood about apply-binding-sheets is rather different. If this  
attribute is set to true, for the <content> element in a <binding>, then  
the <style> from the <binding> is applied to the explicit children of the  
<content>. Explicit childrens are those children "cloned" from the bound  
element to the shadow content. So, <style> applies *only* to these nodes,  
not to the entire bound document.

Corrections?

If the intended purpose of apply-binding-sheets is to make <style>s apply  
to the entire bound document, you have to update the spec in order to  
reflect this. From the spec, I didn't get this, not even the slightest.

If not, you should still update the spec adding a paragraph explicitly  
stating <style>s do not apply to the entire bound document, even if  
apply-binding-sheets is set to true. Thus you eliminate a point of  
confusion.

>> 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?).
>
> I don't really see what can be simplified. Any suggestions? All the
> features are there to take care of pretty important use cases.

This is the main problem. All features are there for various important  
reasons.

Only suggestion I could come up with: remove the complexities of having  
apply-binding-sheets and apply-author-sheets. Remove these attributes.  
Define the behaviour as if apply-binding-sheets would be true (applying  
*only* to explicit children, not the entire bound document) and  
apply-author-sheets is also set to true. This would make it easier to  
implement, to define and to understand.

However, I don't think that's acceptable.

>> > > 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.
>
> Interesting. So you would not say that implementing XForms is an  
> important
> use case for XBL2?

It's important, if you make/want it so.

Here's how I see this:

You don't start writing a spec, which once implemented, helps you  
implement one of the thousands of other specs. In my mind this is not a  
good purpose. It's like you build a car (XForms) which you don't know to  
start, so you build another car (XBL2) ... and this time you'll be able to  
push the XForms one. If XForms is no good, leave it. XBL2 must thrive on  
its qualities, on its own features and use cases. XBL2 IMHO has many  
purposes, many wild use cases which we can't even think of right now.

Again, if XBL2 turns out that good, in order to be able to implement  
XForms, XHTML2 (or vice-versa?), or any other spec, then "wow", "cool".  
Yet, this should not be exactly the purpose.

I can't explain this any better. To me it just sounds weird to build a  
car, to push an older one.

Just a thought...

> Thanks again for the help,

You are welcome!

-- 
http://www.robodesign.ro
ROBO Design - We bring you the future
Received on Friday, 25 August 2006 10:41:19 GMT

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