- From: Domenic Denicola <domenic@domenicdenicola.com>
- Date: Tue, 10 Dec 2013 23:42:39 +0000
- To: Jonas Sicking <jonas@sicking.cc>
- CC: Ian Hickson <ian@hixie.ch>, Boris Zbarsky <bzbarsky@mit.edu>, Webapps WG <public-webapps@w3.org>
From: Jonas Sicking <jonas@sicking.cc> > Actually, I think our mental models are surprisingly aligned. Which is great! More below. Sweet! > So dropping the arrowthingy element seems fine. I'm not opposed to it, just trying to come up with something minimal. > option:hover should just work, no? Yeah, but options weren't in my original list, so I wanted to be sure to include them. > I'm not sure I understand this. If you want the ::control to render the same way no matter if the select is "open" or not, then why do you need to test for that state? Right, what I meant was: normally, when the select is "closed," I want a hover state for the ::control. But when it is open, I do not want hovering back over the ::control to do anything visual. So my ideal selectors would be like: ::control { background: blue; } ::control:hover { background: green; } select:open ::control:hover { background: blue; } or similar. > I would also think that you need properties to position the ::popout. XUL used to have a really cool way of allowing you to anchor an element against another element. It would let you select which corner of your positioned element should be aligned to which corner of your anchoring element. Details at [1]. > > We should be able to do exactly the same thing in CSS as long as we limit it to positioning child elements against their parent elements. We might also need to allow adding an offset as to account for borders and shadows etc. Sounds like a hard part... I think I could get away with letting the UA handle that for me, at least for now. I.e. ::popout is always below or above control (depending on how much room is available), according to OS-specific logics. Or some other position, if I recall Mac OS X <select>s... > That's what B is. > > ... > > However there's not always pseudo elements that allow you to target the shadow elements. And where there is, those pseudo-elements are non-standard. Ah, that's a more correct way of looking at it; thanks. I was thinking of appearance: none as a switch that would apply all the way down the shadow tree, which it clearly doesn't (at least in Firefox; it does seem to in Chrome). As long as I can nuke that darn Firefox arrow...
Received on Tuesday, 10 December 2013 23:43:11 UTC