[whatwg] [html5] Rendering of interactive content

Giovanni Campagna scampa.giovanni at gmail.com
Fri Feb 6 09:54:52 PST 2009


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.

This in particular applies to the button, input, select and textarea.
Something like this could be included:

button,input[type=submit],input[type=button],input[type=reset] {
appearance:push-button;
}
input[type=submit],input[type=button],input[type=reset] {
content:attr(value,string,contents);
}
input {
appearance:field;
border-width: calc(attr(size,px,0) / 2); /* presentational hint */
}
input[type=password] {
appearance:password;
}
input[type=url]::outside::after {
appearance:push-button;
content:icon;
icon: url(<icon uri>);
} /* the current appearance in Opera */
input[type=range] {
appearance:range; /* Webkit uses a proprietary -webkit-slider-horizontal for
this */
}
input[type=checkbox] {
appearance:checkbox;
}
input[type=radio] {
appearance:radiobutton;
}
input[type=file]::outside::after {
appearance:push-button;
content: "Browse...";
}
select[size] {
appearance:list-menu;
}
select,select[size=1] {
appearance:pop-up-menu;
}

The advantage of appearance vs binding is that:
1) you don't need an additional pass before applying the correct
platform-specific widget style
2) you depend on css3-ui, in CR stage, instead of becss, a very early WD
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)
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)
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?

~ o ~

A part from that, I would like to propose the following CSS for some missing
parts:

marquee[behaviour=slide] {
marquee-style:slide;
}
marquee[behaviour=scroll] {
marquee-style:scroll;
}
marquee[behaviour=alternate] {
marquee-style:slide;
}
marquee[direction=left] {
marquee-direction:forward;
overflow-style:marquee-line;
}
marquee[direction=right] {
marquee-direction:backward;
overflow-style:marquee-line;
}
marquee[direction=up] {
marquee-direction:backward;
overflow-style:marquee-block;
}
marquee[direction=down] {
marquee-direction:forward;
overflow-style:marquee-block;
}
marquee[loop] {
marquee-play-count: attr(loop,integer,initial);
}

(This obviously means that we need a definition of marquee accepting
attributes behaviour = (slide | scroll | alternate), direction = (left |
right | up | down), loop = <integer>. Info found from MSDN).

progress {
display:block;
content:none;
background-color:green;
width: calc(1% * attr(value,number,0) / attr(max,number,1) );
}
progress::outside {
display:block;
text-align:center;
width:auto;
content:contents;
}
progress:empty::outside {
content:calc(attr(value,number,0) / attr(max,number,1) * 100) "%";
}

The same could apply for meter as well, except for the handling of optimal
and suboptimal parts.

menu[type=toolbar] {
appearance:menu-bar; /* are menu bars visually different from tool bars? */
}
menu[type=context]:active {
appearance:menu;
display:block; /* may be actually implied by appearance:menu */
}
menu[type=toolbar] > menu::outside::before, menu[type=toolbar] >
select::outside::before, menu[type=toolbar] > menu::outside::after,
menu[type=toolbar] > select::outside::after, menu[type=toolbar] > hr,
menu[type=toolbar] > option[value=]:disabled, menu[type=context] >
menu::outside::before, menu[type=context] > select::outside::before,
menu[type=toolbar] > menu::outside::after, menu[type=toolbar] >
select::outside::after, menu[type=context] > hr, menu[type=context] >
option[value=]:disabled { /* separators */
display:block;
content:"";
border: 1px solid ThreeDFace;
width:0px;
}
menu[type=toolbar] > menu[label], menu[type=toolbar] > optgroup[label],
menu[type=context] > menu[label], menu[type=context] > optgroup[label] {
appearance:pull-down-menu; /* actually, where are we supposed to specify the
label? */
}
menu[type=toolbar] a, menu[type=toolbar] button, menu[type=toolbar]
input[type=submit], menu[type=toolbar] input[type=reset], menu[type=toolbar]
input[type=button], menu[type=toolbar] input[type=checkbox],
menu[type=toolbar] input[type=radio], menu[type=toolbar] select option,
menu[type=toolbar] command, menu[type=toolbar] bb, menu[type=context] a,
menu[type=context] button, menu[type=context] input[type=submit],
menu[type=context] input[type=reset], menu[type=context] input[type=button],
menu[type=context] input[type=checkbox], menu[type=context]
input[type=radio], menu[type=toolbar] select option, menu[type=context]
command, menu[type=context] bb { /* commands */
appearance:menu-item;
}

I hope that this will help a bit the editor.

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


More information about the whatwg mailing list