- From: Giovanni Campagna <scampa.giovanni@gmail.com>
- Date: Fri, 6 Feb 2009 18:54:52 +0100
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.htm>
Received on Friday, 6 February 2009 09:54:52 UTC