On 8/25/06, Mihai Sucan <[EMAIL PROTECTED]> 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
