[whatwg] [html5] Rendering of interactive content

[Giovanni Campagna]

2009/2/6 Ian Hickson <ian at hixie.ch>

> On Fri, 6 Feb 2009, Giovanni Campagna wrote:
> >
> > I'm proposing to replace the current rendering mechanism, based on
> > Behavioural Extension to CSS, that in turn is based on XBL2, with
> > something based on the CSS3 Basic User Interface (css3-ui), ie replacing
> > the binding: property with appropriate appearance: property directly on
> > the element, instead of relying on the binding itself.
>
> The two properties are orthogonal -- 'binding' sets the behavior,
> 'appearance' sets the look-and-feel.
>
> 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.
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.
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.

> The advantage of appearance vs binding is that:
> > 1) you don't need an additional pass before applying the correct
> > platform-specific widget style
>
> With UA-native bindings, you wouldn't need an additional pass either.
>
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.

>
> > 2) you depend on css3-ui, in CR stage, instead of becss, a very early WD
>
> BECSS is actually probably more stable than CSS3 UI at this point.
>
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.

>
> > 3) you don't block the binding property: I don't expect that applying an
> XBL
> > binding on an element causes it to appear like a span (because it gets
> > almost no default CSS)
>
> This is actually intentional. Experience with elements like <fieldset>
> that have styles that aren't expressed in CSS is that you end up not being
> able to restyle them properly if you desire. With 'binding' we'd be able
> to knock out the whole default rendering (including weird things with the
> children) in one go.
>
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.


>
> > 4) you keep the appearance property working: current UA (Firefox and
> Safari
> > at least) already implement appearance, and correctly set it on the input
> > element. This could no longer be possible using XBL, because of the CSS
> > inheritance model inside XBL (if you apply to appearance to some part of
> the
> > shadow tree, it is not visible on the bound element)
>
> I don't understand what you mean here.
>
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)

>
> > 5) becss requires "one or more binding languages": it is not necessarily
> > XBL2, but currently XBL2 is the only one available: are you constraining
> > the implementation of HTML5 on that of XBL2?
>
> The rendering section has no actual requirements in it, so nothing is
> constrained. Furthermore, nothing requires the binding language used by
> the UA to actually be a real language, so long as it is triggered by the
> 'binding' property.
>

"A number of elements have their rendering defined in terms of the 'binding'
property" (HTML5, with normative reference to BECSS)
No BECSS --> no rendering --> no interoperability
"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)
Do you know any other binding languages outside XBL or HTC (that uses
behaviour instead of binding)?
"*Computed Value:* specified value, with URIs resolved to absolute URIs "
"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."
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

>
> Cheers,
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Giovanni

PS: did you find useful the remaining material, eg. menu, meter, marquee?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090207/f66f75b1/attachment-0001.htm>