- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 22 Aug 2006 23:30:48 +0000 (UTC)
- To: Mihai Sucan <mihai.sucan@gmail.com>
- Cc: public-appformats@w3.org
- Message-ID: <Pine.LNX.4.62.0608222227140.13239@dhalsim.dreamhost.com>
On Tue, 22 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.
> Given an UA which implements :root CSS3 selector, and having the
> following code:
>
> <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>
> :root { color: green }
> .my-class { color: blue }
> </style>
> </resources>
> </binding>
> </xbl>
> </head>
> <body>
> <div id="my-elem">A
> <p>B</p>
> <p>C</p>
> D
> </div>
> </body>
> </html>
>
> ... how would the above render? Which is the :root?
Nothing would match the :root. 2, A, B, C, D, and 3 would be blue (by
inheritance from the <div>). 1 and 4 would be black.
> Which becomes green?
None. The only element that matches :root in the document above is the
<html> element.
> «The result of applying the XBL binding above to the HTML given above
> using the CSS given above is equivalent to the result one would get if
> one simply placed the div element with class="nav" before the div
> element with class="main".»
>
> It's definitely better, but ... I would recommend:
>
> «The result of all the code given above is equivalent to the result one
> would get if one simply placed the div class="nav" before the div
> class="main".»
>
> This, IMHO, makes up for even easier reading.
Fair enough. Changed.
> > At the end of the day browsers are going to implement whatever level
> > of Selectors they feel comfortable with. Selectors applies to much
> > more than just XBL, it isn't up to XBL to decide what level of
> > Selectors UAs should implement. Similarly, XBL doesn't require
> > particular levels of XML or HTTP or CSS.
>
> Good point, yet I am not convinced. The PNG spec makes transparency
> optional, starting even from the short description at the beginning of
> the document.
>
> Making Selectors "optional" is almost the same...
>
> Not much I can add.
I agree that it is a problem. I just don't see that making the spec say
something or other would solve the problem.
> > > 2.3. The implementation element
> > >
> > > I personally don't exactly understand the syntax used in the
> > > provided example:"set memory(value)" and "get memory()". Why a
> > > space? Can somebody explain that?
> >
> > It's from JavaScript 1.5.
>
> I looked over at developer.mozilla.org, but I didn't find this. Link?
First hit for "javascript 1.5" on Google:
http://www.mozilla.org/js/js15.html
> > > 2.13. The style element
> > >
> > > This should have a type attribute. The style-type attribute of xbl
> > > element would be only the "default type". Why not allow multiple
> > > types of styles in a single binding?
> >
> > Why allow it? That would just be extra complexity for no good reason.
> >
> > With the current model, UAs just have to check one place and can bail
> > on all the styles in the <xbl> if it isn't a supported language.
> >
> > What's the use case for multiple style languages within one binding?
>
> True, this adds extra complexity.
>
> It's minor complexity compared to the big complexity of implementing
> XBL2 itself.
Sure. But it's still extra complexity. Everything we can do to make things
simpler helps a little.
> An UA with several script implementations (e.g. Perl, Python and
> ECMAScript), will ensure "interoperability" between them. AFAIK Mozilla2
> is aiming for a Python implementation. Will they force a document to use
> *only* Python or *only* JS? Yes, it's complicated to get the two
> seemingly working in the same document, but this is not related to XBL2,
> CSS, XML, HTML, nor HTTP.
It's more complicated if a single binding can have a mixed language
runtime. In particular, I don't know how you'd handle the JS
"implementation object" dichotomy when half the binding handlers are in
perl, for example.
> XBL2 should, at least, optionally allow combining several style types
> and script types. The specification should allow an open door for future
> versions which might define how.
It would be easy for a future version of the spec to extend into having a
type attribute on <script> and <style>.
> I'm just saying that XBL2 shouldn't close the "eyes" on future
> possibilites.
Sure. I don't think that anything is being closed here though.
> Extra complexity is not a very good argument for me, since DOM, SVG, JS,
> CSS, X+V, XML Events, already add huge complexity. If complexity would
> be a problem, XSLT, MathML, nor XBL2 would be implemented.
Existing complexity is not an argument for unnecessary complexity.
> There's also the second example, which repeats "imagine" 3 times: each
> aligned on the left, as the first word in the sentence (for
> visibility?). If you want, leave it as it is, for diversity :).
I changed the first of those to "Consider". The other two seem reasonable
since it really is asking you to imagine something not shown. :-)
> I believed I can use xbl:pseudo="any-value" then :any-value from CSS.
Oh, I see. Yeah, I should list the values. Fixed.
> Only reading chapter 5.7.4. I found out I can't use any value, just the
> predefined ones. However, the predefined ones are not a "big deal".
> xbl:pseudo only adds complexity with no obvious benefit (IMHO). E.g.
> instead of xbl:psuedo="icon" the author can use class="icon".
>
> 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.
> «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.
>
> Note: The implementation prototype object is created only the first time the
> binding is used, after the binding document has loaded.
Notes are non-normative (not official requirements of the spec) so this
change would change the meaning of the spec.
I'm not sure how to make it better without this problem.
Cheers,
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 22 August 2006 23:31:07 UTC