Le Fri, 25 Aug 2006 01:25:31 +0300, Ian Hickson <[EMAIL PROTECTED]> 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