<div class="gmail_quote">2009/2/6 Ian Hickson <span dir="ltr"><ian@hixie.ch></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Fri, 6 Feb 2009, Giovanni Campagna wrote:<br>
><br>
> I'm proposing to replace the current rendering mechanism, based on<br>
> Behavioural Extension to CSS, that in turn is based on XBL2, with<br>
> something based on the CSS3 Basic User Interface (css3-ui), ie replacing<br>
> the binding: property with appropriate appearance: property directly on<br>
> the element, instead of relying on the binding itself.<br>
<br>
</div>The two properties are orthogonal -- 'binding' sets the behavior,<br>
'appearance' sets the look-and-feel.<br><div class="Ih2E3d"></div><br></blockquote><div>I thought about it later, and I realized that you cannot style complex
widgets without XBL (or something like that) because pseudo-elements
are not reached by events. If they ever would, we would have horrible
situations we have now.<br>
So for complex widgets (Number, File, Slider) it may be impossible to
avoid a binding property, but anywhere it is possible you should try to
use the available (appearance, content, icon, etc.). Even when using
those, the author is able to shut them down, and knows perfectly which
of them apply (they're defined normatively in HTML5 and they're exposed
by browser tools for web dev). This allows for them to be selectively
disabled, eg. to show BB without a button but with the native icon.<br>What is more important, is that appearance normatively defines what properties from outside the appearance definition are allowed to interfere with the native look of the widget, binding does not. If author style sheets are not imported in XBL (apply-author-sheets="false"), they don't apply at all.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
> The advantage of appearance vs binding is that:<br>
> 1) you don't need an additional pass before applying the correct<br>
> platform-specific widget style<br>
<br>
</div>With UA-native bindings, you wouldn't need an additional pass either.<br><div class="Ih2E3d"></div></blockquote><div>The current spec says "User agents are encouraged to make their bindings set
the 'appearance' CSS property appropriately to achieve
platform-native appearances for widgets": this means that the binding should set appearance, and then appearance should make the widget look like a normal button. </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">
<br>
> 2) you depend on css3-ui, in CR stage, instead of becss, a very early WD<br>
<br>
</div>BECSS is actually probably more stable than CSS3 UI at this point.<br><div class="Ih2E3d"></div></blockquote><div>Why do you say so? Will CSS3 UI go back to Last Call or BECSS process to Last Call in the near future? I'm not sure. In the mean time, CSS3 UI is final, and waiting only for implementation.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
<br>
> 3) you don't block the binding property: I don't expect that applying an XBL<br>
> binding on an element causes it to appear like a span (because it gets<br>
> almost no default CSS)<br>
<br>
</div>This is actually intentional. Experience with elements like <fieldset><br>
that have styles that aren't expressed in CSS is that you end up not being<br>
able to restyle them properly if you desire. With 'binding' we'd be able<br>
to knock out the whole default rendering (including weird things with the<br>
children) in one go.<br><div class="Ih2E3d"></div></blockquote><div>The fact is that binding it the best way to apply a set of event handlers to an element. Having to tweak the computed style of a fieldset in order to find what properties are actually set and reproduce them in the binding, just to put a set of onchange handlers to lots of fieldset, does not look optimal.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
<br>
> 4) you keep the appearance property working: current UA (Firefox and Safari<br>
> at least) already implement appearance, and correctly set it on the input<br>
> element. This could no longer be possible using XBL, because of the CSS<br>
> inheritance model inside XBL (if you apply to appearance to some part of the<br>
> shadow tree, it is not visible on the bound element)<br>
<br>
</div>I don't understand what you mean here.<br><div class="Ih2E3d"></div></blockquote><div>I mean that Firefox and Safari set the appearance property on the widget element, and it is visible from outside, and dynamically changeable at run time. The binding property instead contains an opaque and UA specific value, that is not intended to be changed from JS (to switch back and forth between widget types)<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
<br>
> 5) becss requires "one or more binding languages": it is not necessarily<br>
> XBL2, but currently XBL2 is the only one available: are you constraining<br>
> the implementation of HTML5 on that of XBL2?<br>
<br>
</div>The rendering section has no actual requirements in it, so nothing is<br>
constrained. Furthermore, nothing requires the binding language used by<br>
the UA to actually be a real language, so long as it is triggered by the<br>
'binding' property.<br>
</blockquote><div><br>"A number of elements have their rendering defined in terms of the
'binding' property" (HTML5, with normative reference to BECSS)<br>No BECSS --> no rendering --> no interoperability<br>"A user agent cannot comply to this
specification without also supporting one or more binding languages such
as XBL" (BECSS, with informative reference to XBL2)<br>Do you know any other binding languages outside XBL or HTC (that uses behaviour instead of binding)?<br>"<em>Computed Value:</em>
specified value, with URIs resolved to absolute URIs
"<br>"When a specified URI cannot be used, e.g. due to network errors or
because the specified binding is in an unsupported language, that
specified URI must be ignored, without affecting the other URIs
specified."<br>This means that the binding property must be an absolute <uri>, indicating a network retrievable resource (no about: or urn: URI) in a supported language<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Cheers,<br>
<font color="#888888">--<br>
Ian Hickson U+1047E )\._.,--....,'``. fL<br>
<a href="http://ln.hixie.ch/" target="_blank">http://ln.hixie.ch/</a> U+263A /, _.. \ _\ ;`._ ,.<br>
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'<br>
</font></blockquote></div><br>Giovanni<br><br>PS: did you find useful the remaining material, eg. menu, meter, marquee?<br>