On Thu, Dec 5, 2013 at 5:56 PM, Domenic Denicola <[email protected]> wrote: > From: Jonas Sicking [mailto:[email protected]] > >> 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
