Le Tue, 22 Aug 2006 02:55:11 +0300, Ian Hickson <[EMAIL PROTECTED]> a écrit:
On Mon, 21 Aug 2006, Mihai Sucan wrote:
I have reviewed the XBL2 draft (21 august 2006 draft, directly from the
CVS) and I have the following comments to make:
Thanks!
You're welcome.
0. General things
a)
<style> in <resources>
How's this supposed to work? Is the provided style applied as if the
shadow content is a document by itself? Or is the style added to the
entire owning document, just like adding a new <style> in header? Or...
is the <style> applied as if the bound element is a document by itself?
In theory this is defined in section 5.10; is that not detailed enough?
Yes, it's explained. However, due to the complexity of XBL2 one can truly
understand only in practice.
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.
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? Which becomes green?
IIANM: 1 4 should be green, 2 3 should be blue, and A B C D should be
black. If I set apply-binding-sheets="true" for <content />, then A B C D
should then be blue too.
Bad phrasing:
«The result of applying the XBL binding above to the HTML given able
using
the CSS given above is to equivalent to the result one would get if one
simply
placed the div element with class="nav" before the div element with
class="main", but the effect is achieved without needing any changes to
the
markup.»
I don't understand what's exactly meant. Please rephrase.
Wow, I must have been asleep when I wrote that. Fixed.
Good it's now fixed.
«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.
1.2.1. Attributes Containing Selectors
«Note: This specification does not specify what level of Selectors
support is
required.»
Why?
If one UA claims support for XBL2 the author can't rely on the support
of CSS
3 Selectors, practically rendering XBL2 support useless if no Selectors
are
supported. XBL2 specification should provide a list of required
Selectors for
claiming conformance. If not, we will endup with UAs doing something
similar
to IE 6: they added support for PNG, but they missed one of the
"coolest"
feature in PNG (transparencies).
It wouldn't help. PNG is a great example of this -- despite transparency
being in the spec, IE still didn't implement it.
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.
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?
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.
2.14. The prefetch element
Suggestion: new attribute "condition". This should be an ECMAScript
expression
which if evaluates to true, the file is loaded. Some may want to
prefetch some
images based on various conditions.
You can do this today using <script> elements -- just add the <prefetch>
elements you want dynamically.
This suggestion came from VoiceXML-experience. :)
2.15. The script element
This should have a type attribute. The script-type attribute of xbl
element
would be only the "default type". Why not allow multiple types of
scripts in a
single binding?
Same as for style, except even more so -- having multiple languages in
one
binding would be very complicated to specify and implement.
I don't completely agree.
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.
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. At the moment, there's no need to do so.
I'm just saying that XBL2 shouldn't close the "eyes" on future
possibilites.
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.
5.4. Processing content elements
The example starts with «Imagine the following simple document». I am
not
sure if that's appropriate, because I won't imagine anything. The
provided
example is result of what the author imagined. If I have to imagine
something,
I'd imagine something else.
I'd suggest switching from "imagination examples" to just examples:
"Given the
following document", then "Having the X element bound to...".
Removed imagination from this example.
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 :).
5.7.4. The matching pseudo-elements
Until reaching this chapter I believed I can assign any pseudo-element,
for
use within CSS. Quite an interesting concept, at first.
Reading this chapter I reached the conclusion this is much like the
state
attribute for the div element. Instead of using the provided list of
psuedo-elements, one can use class names (icon/value/choices...). Even
the
provided example emphases that, for me, at least.
Not sure I understand.
No problem. Let me try to explain again.
I believed I can use xbl:pseudo="any-value" then :any-value from CSS.
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.
What I like about CSS psuedo-stuff is they provide the means to style
something "inexisting" in code, such as :first-letter, :first-line. It
also provides "shorthands" for matching elements :first-child,
:last-child, :first-of-type, etc. xbl:pseudo takes another path, turning
pseudo-stuff into something as "graspable", as "simple" as a class name.
I'm not sure I can explain this any better.
6.4. ECMAScript bindings
«First, if this is the first time the binding defined by that binding
element
is used since that binding document was loaded, then, if that element
contains
an implementation element, then the first such element must have its
code
compiled and run (see below), and the return value of that script, if
any,
must be forever associated with that binding element as that binding's
implementation prototype object.»
This very lengthy phrase is hard for one to understand. I recommend a
better
wording. I have no suggestion, since a correct rephrasing requires
accurate
understand, and I myself don't feel confident enough to say "yeah, I
know what
he meant".
I tried to make this clearer.
Yes, it's better: now I understand what it says. Again, there's a "but"
... I recommend rephrasing, for making it even easier to understand:
From:
«1. If this is the first time the binding defined by that binding element
is used since that binding document was loaded, and if that element
contains an implementation element, then:
1. The first implementation element child of the binding element must
have its code compiled and run (see below).
2. The return value of that script, if any, must be forever associated
with that binding element as that binding's implementation prototype
object.
Otherwise, if the binding element doesn't contain an implementation
element, or if it does but 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 the binding element's
implementation prototype object must be forever set to that object.»
"that binding element" in the first phrase doesn't sound right to me. It
somehow implies I know which binding element, "that one!".
Also, the word "binding" seems overused.
To:
«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.
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.»
I'm not sure if this is good for copy/paste. Maybe you can continue from
this.
Thanks for your input!
You are welcome, and thanks to Anne for reminding me about XBL2.
--
http://www.robodesign.ro
ROBO Design - We bring you the future
