[whatwg] [html5] Rendering of interactive content

Thu Feb 12 07:47:28 PST 2009

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

> [...]
>
> > > > 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.
>
> CSS3 UI is very vague, and is going to need serious work before browsers
> are able to actually implement it properly. A lot of the vendor feedback
> at the time it was written was dismissed (e.g. it doesn't have a
> particularly useful or comprehensive list of appearances).
>
Well, it is the *Basic* User Interface, that is, the bare minimum. All the
rest is Advanced UI, that I hope one day we will have.

>
> > > > 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.
>
> I don't understand why you would need to know what properties are set, or
> what 'onchange' has to do with anything here.

<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
<xbl xmlns="http://www.w3.org/ns/xbl">
<binding id="textboxes" >
<handlers><handler event="onchange">window.alert("Hey! You changed my text
box!"); </handler></handlers>
</binding>
</xbl>
<style>input[type=text] { binding: url(#textboxes); }</style>
</head>
<body><form><input type="text" value="Change me!" /></form></body>
</html>

At a first look, it just sets an onchange event handler to every
input[type=text]. Using the HTML5 approach to widgets presentation, you
would need to set the appearance to field on the bound element or it will
look much like a <span>

>
>
> [...]
> >
> > 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)
>
> I expect we'll define actual values for 'binding' in due course; that's
> mostly waiting on XBL2 getting implemented. I don't see why 'appearance'
> would work better with JS than 'binding'.
>
Ah ok. I thought you wanted to leave that to be implementation dependent.
This is completely different.

>
> [...]
>
> We'll probably change that to just use keywords in due course.
>
So what should be the difference between appearance: field and binding:
field ?

>
> [...]
>
>
> It's a guide to Web browser vendors who wish to render things in a
> commonly accepted way.
>

> > I think that section is for
> > - implementors of new UAs, that don't need to reverse engineer the
> > competitor products in order to find the defaults
>
> Right.
>
>
> > - authors, that in this way know what to expect from the various UA with
> > less testing, that sometimes is also impossible, eg. you cannot test the
> > rendering of a mobile phone if you don't have a mobile phone
> > Having somewhere written that hyperlinks should be blue, allows you to
> style
> > the background-color to anything but blue.
>
> The section is not really for authors (though I suppose authors might find
> it interesting, in the same way they might find the parser section
> interesting).
>
>
> [...]
>
>
> Authors should act as if the default style sheet is something sensible but
> they don't know what. (Because that is in fact what the situation is, once
> you consider user style sheets.)

That is, the rule for authors is "not just act as the UA default style sheet
was not present, but also act as if it was completely undefined or defined
to something weird", so explicitily write it every time it may be dangerous,
like for :link.

That's a completely different point of view. Thank you for clarifications,
I'll write div { display:block; } and :link { color:blue;
background-color:transparent;} in all my style sheets from now on.

Giovanni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090212/d13452fb/attachment-0001.htm>