- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 6 Dec 2013 11:09:25 -0800
- To: Domenic Denicola <domenic@domenicdenicola.com>
- Cc: Ian Hickson <ian@hixie.ch>, Boris Zbarsky <bzbarsky@mit.edu>, Webapps WG <public-webapps@w3.org>
On Thu, Dec 5, 2013 at 5:56 PM, Domenic Denicola <domenic@domenicdenicola.com> wrote: > From: Jonas Sicking [mailto:jonas@sicking.cc] > >> The tricky part is finding a set of pseudo elements that work across different UAs, and that give authors enough control that they can integrate the control with the look-and-feel of their website. > > I am wondering if we put forward the following concrete proposal, how much objection there would be: > > - Two pseudo-elements, select::control and select::popout. (Representing the control you see by default, and the extra box that pops out when you click the select.) The control that you see by default can simply be targetted with "select", no? The three pieces that are often brought up are: 1. The popout 2. The little down arrow that's displayed in the default control, usually on the right-hand-side. 3. The part of the default control which displays the currently-selected option. To make matters somewhat more complex, <select>s can also be rendered as a list rather than as a popout. Do the above pseudo elements map to anything in such a <select>? > - If implementations don't think that a control + popout UI is a good match, e.g. mobile platforms that take up the entire screen when you click the control, they do not have to implement them. (Or can implement only control, or only popout.) Agreed > - `appearance: none` on both reverts them to the default <div> styles, i.e. no styles. There are actually 3 different modes here: A) The default rendering. Many times this can not be described using CSS, and so can't always be styled with CSS B) Fallback rendering that still renders a full form control, but which is rendered using shadow content and CSS and thus can be styled using CSS. C) No special rendering at all. I.e. the <select> is just an inline element, as are the <option>s inside it. Gecko currently falls back from A to B if the page applies CSS styles which we can't render using A. A good way to see this is to open the following markup in Firefox for OSX: <input type=button value=hi><input type=button value=hi style="background:red"> The first button will be rendered using A, the second using B. You can also explicitly trigger B by using -moz-appearance:none data:text/html,<input type=button value=hi><input type=button value=hi style="-moz-appearance: none"> There is currently no way to make gecko use C. I believe that webkit has similar behavior. Though using -webkit-appearance: none of course. So when you say, "default <div> styles", do you mean B or C? I think there are use cases for explicitly triggering the C rendering. I'm not sure if there are for triggering the B rendering. The auto-fallback might be good enough. But I'm really not sure. This is part of what needs to be figured out in order to make form controls stylable. > - No specification (for now) of individual items inside the ::popout. Not even the <option>s? > I know implementers have generally been pretty scared of nailing this stuff down, but I tried to make this as unobjectionable and minimal as possible, and so would be interested to hear what kind of concrete objections there are. I apologize if I am retreading though, and in that case would appreciate pointers to older threads. I'm certainly interested in nailing this stuff down. And I know many others within mozilla are too. / Jonas
Received on Friday, 6 December 2013 19:10:24 UTC