[whatwg] [html5] Rendering of interactive content

[Ian Hickson]

On Sat, 7 Feb 2009, Giovanni Campagna wrote:
> 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.

As far as I know I've only used 'binding' where it is necessary.

Note that <bb> only uses the binding if it's not empty.


> 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.

I'm not sure what you mean when you say 'binding' doesn't define this -- 
as far as I can tell, XBL2 fully defines what should happen here.

We can't really know ahead of time whether the bindings should have 
apply-author-sheets="false" or "true", though.


> > 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.

I wouldn't characterise that as an extra pass, but ok. I don't think it's 
a problem.


> > > 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).


> > > 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.


> > > 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)

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'.


> > > 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

But the rendering definitions are non-normative anyway.


> "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)?

The browser can invent a fictional one for its own internal use.


> "*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

We'll probably change that to just use keywords in due course.


On Sat, 7 Feb 2009, Giovanni Campagna wrote:
> 
> Yes, but UA that don't follow that set of CSS rules are not 
> interoperable with UA that follow, ie scripts must detect what 
> properties are ignored or defaulted.

Why would a script do that?


> > Furthermore, user agents are free to use any method they like to mimic 
> > the suggested rendering, including CSS3 UI where applicable. They 
> > don't have to use BE CSS at all.
> 
> They're "expected" to use CSS, and I expect that, according to html5, 
> "button { binding: initial; }" makes it like a <span>.

Right.


> > If this is not obvious from the text, perhaps you would like to 
> > suggest a change to the text that would make it clearer?
> 
> I don't agree with rendering being "optional". If interoperability is so 
> important (and it is), rendering should be normative. Obviously I'm not 
> asking to depend on CSS, I'm asking that "UA should act if the following 
> CSS was specified" (even if it doesn't support CSS)

That's basically what we have now, except that we can't make it any more 
normative because we don't know all the different ways that people will 
use HTML. Browsers are by far not the only way that people consume HTML, 
let alone desktop browsers with screens.


On Sat, 7 Feb 2009, Giovanni Campagna wrote:
> >
> > CSSOM-implementing UAs do not have to do express all styling with CSS 
> > properties.
> >
> > When they do, you can query for those properties via the CSSOM.
> 
> Yes, but what properties should I query for? Binding, behaviour, 
> appearance, border, color, font, all in once? And what should their 
> values be?

There is no way to say. The user could have a user style sheet that 
replaces all the default values anyway.


> If <input type="submit"> in some UA is rendered with all properties set to
> initial, not only it does not express the semantic of a button, but it may
> be difficult for a user to actually recognize it as a button and eventually
> click it. In that case I, as the author, may need to manually set {
> appearance:push-button; content:attr(value,string,"Send"); } in order to
> have my form submitted.
> Try this example (in Firefox or Safari):
> data:text/html,<style>label { position:fixed; top:-1em; border:1px solid
> black; } label input { -moz-appearance:none; -webkit-appearance:none;
> border:none; width:auto; } input[type=submit] { -moz-appearance:none;
> -webkit-appearance:none; background-color:transparent; border:none;
> }</style><form action="http://www.google.com/search"
> method="get"><label>Search: <input type="text" value=""
> name="q"></label><input type=submit value="Go">
> 
> Imagine that was the UA default stylesheet instead of an author 
> stylesheet and you may see what interoperability means with web 
> application look and feel.

Browsers that do that wouldn't be very usable. Is this a real concern? I 
mean, does any browser do this?


> HTML5 should not mandate the UA present <a>s in blue, but it should 
> mandate the UA present <a>s like links (appearance:hyperlink). The color 
> of course is a matter of visual themes and platform.

HTML5 actually does say links should be blue. :-)


> An other example: HTML5 should mandate <button> displayed with
> appearance:push-button; even if the UA doesn't support CSS.

It does: 

# When the button binding applies to a button element, the element is 
# expected to render as an 'inline-block' box rendered as a button whose 
# contents are the contents of the element.

Whether this means 'appearance: push-button', or some fancy combinations 
of borders, or something else entirely, is neither here nor there.


On Sun, 8 Feb 2009, Giovanni Campagna wrote:
> > >
> > > Yes, but what properties should I query for?
> >
> > In order to find out what, precisely?
>
> What to reset, for example (see the first Ian email on this topic)

Just reset everything? I really don't understand. Set the values you want, 
leave the rest alone, and the page will render fine. There's no need to 
"reset" anything.


On Sun, 8 Feb 2009, Giovanni Campagna wrote:
> 
> I agree with you that we must not constrain the innovation, but in that 
> case, what is the whole purpose of the Rendering section?

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).


> If the UA suddenly displays hyperlinks in green and I decided that my
> background is green, the user will complain with me, not with the UA (and
> will probably switch to a different website)

Authors should never the background colour without setting the foreground 
colour. So that would be the author's fault.


> Having somewhere said that <table> should be rendered as CSS tables, allows
> you to put a border-collapse for example. If <table> suddenly starts to be
> displayed as an hierarchical tree, my site may be broken at once.

The spec does suggest using the CSS table model for tables. However, I 
don't see why if I, as a user, would rather navigate your table as a tree, 
I shouldn't be able to do so. It might not look like how you wanted it to, 
but that doesn't mean it's broken.


> The solutions are two:
> 1) either provide a default style sheets only for author and say: "you want
> the usual rendering everywhere? import this". This means that the whole
> Rendering sections should be moved to an Appendix and a separate
> downloadable CSS file should be provided. In addition the "presentational
> hints" become useless, since many of them cannot be expressed in terms of
> CSS, and actually, all UA default style sheets are less important, because
> most of time they will be overriden by author style sheets. Last, but not
> least, you have to face an increased traffic to load an heavy CSS file just
> for two or three display.
> 2) mandate a set of CSS properties and value.

I'm not convinced that there is a problem to solve.


On Mon, 9 Feb 2009, Giovanni Campagna wrote:
> 
> So the whole rendering section is just for implementors and authors 
> should act if no default style sheet is present or worse, if it could be 
> everything, like a inline-block <div> or blue <table>, so that the 
> author should set all supported properties to initial or the HTML5 
> "expected" value?

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:
> I, author, want consistent rendering on all plaforms and browser:

Then you are going to be disappointed. This is not a supported goal.


> I, implementor, want to provide backward-compatible rendering for those
> author that didn't follow rule 1), I import HTML5 style sheet inside UA
> defaults.
> In both case, a downloadable stylesheet would be much appreciated.

There's no way to express the rendering section exclusively as CSS, so we 
can't provide code in that form.

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