- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 24 Aug 2006 22:25:31 +0000 (UTC)
- To: Mihai Sucan <mihai.sucan@gmail.com>
- Cc: public-appformats@w3.org
- Message-ID: <Pine.LNX.4.62.0608242047550.10139@dhalsim.dreamhost.com>
On Wed, 23 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).
Done (mostly using your text).
> 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?
Correct.
> > 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?
No, and no -- I meant :root (in _any_ stylesheet) would only ever match
<html> in your sample. However, the <xbl:style> element in the samples so
far don't even look at the <html> (or <title>) element(s), so they can't
actually ever match them.
> Is the <style> within one binding allowed to affect the outside?
No (except using apply-binding-sheets).
> 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.
The main point of confusion (that <style> doesn't apply to things outside
the shadow tree, notwithstanding apply-binding-sheets) is implicit in the
fact that there's nothing that says it does... but hopefully the
clarification section based on what you wrote should clear this up.
http://dev.w3.org/cvsweb/~checkout~/2006/xbl2/Overview.html?content-type=text/html;%20charset=utf-8#styleSummary
> IMHO, it's rather confusing how all these styling stuff works. The
> scripting and DOM parts seem more straight forward.
Heh. I thought the implementation part was far more confusing. :-)
> 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.
> > > 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?
> «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.»
That doesn't seem much clearer than what is in the draft now. I like
having the draft be explicit; you wouldn't believe the number of times
I've had people ask me about things which I thought were totally obvious.
For example, in "Otherwise, if there is no implementation element, or if
it does not evaluate to an object", you'd get people asking how it could
evaluate to an object if there wasn't one. :-/
Thanks again for the help,
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 24 August 2006 22:25:42 UTC