Re: XBL2 review

On 8/25/06, Mihai Sucan <mihai.sucan@gmail.com> wrote:
> >>
> >> 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>.

This understanding is correct. I did not mean to imply the attribute
could affect nodes above the bound element.


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

Well, the nodes aren't "cloned" -- the children of the bound element
are the actual children who end up distributed to the various places
in the tree. (The shadow content template is cloned, and then the
explicit children are simply "attached" in the relevant places.)


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

Done.


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

Yeah, that would break a number of important cases. :-(


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

I guess this makes sense. The idea is that if UAs don't implement
XForms, but authors want to use XForms, they should be able to
implement XForms. Currently, they can't, because they lack a language
like XBL with which to do it. With XBL, they can implement XForms.
They can also implement certain XHTML2 features, Web Forms 2 controls,
etc. Basically it's intended that XBL be a building block language,
rather than an end-feature.

But in any case, the xbl:pseudo attribute does have uses outside XBL,
so even if XForms wasn't a use case it'd still be important.

Cheers,
-- 
Ian Hickson

Received on Friday, 25 August 2006 21:37:01 UTC