Re: Styling form control elements

[Tab Atkins Jr.]

On Thu, Dec 12, 2013 at 10:03 AM, Jonas Sicking jo...@sicking.cc wrote:
 On Tue, Dec 10, 2013 at 8:24 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Wed, Dec 11, 2013 at 2:46 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 12/10/13 6:30 PM, Jonas Sicking wrote:

 I would also think that you need properties to position the ::popout.


 Oh, yes.  The extra fun here is:

 1)  Should the popout be able to paint outside the browser window? Right
 now, comboboxes (select size=1) can but normal CSS boxes cannot.

 2)  The popout needs to pop out in different directions (up or down)
 depending on the screen position of the anchor, the popout dimensions, and
 the screen dimensions.

 3)  The size of the popout needs to be capped in some way.

 Maybe all that logic should just live in the UA and the page just needs a
 way of saying here is a popout thingie, anchor it here.

 Yes, the popout thingy probably needs to be a specialized 'display'
 value that is only valid on the popout pseudo, so we can bottle the
 magic precisely.

 Allowing the popout thingy to go outside of the browser window, while
 at the same time allowing it to be heavily customized, scares me a
 lot. At some it allows click-jacking parent windows. Or even rendering
 input controls in the parent window and steal data that the user
 thinks he's entering into the parent.

 Even just detecting where in the parent window the user is hovering
 the mouse or clicking could leak critical data if the user is unaware.

 Can we define a subset of styles that are safe?

 I had imagined that we pretty quickly would fall back to rendering the
 popout only inside the same window. Sadly.

Yeah, I imagine that while the popout is in the magic 'display' state,
it only accepts a handful of text/bg properties. Considering the
display modes of popouts in mobile browsers, that's about all we can
allow anyway.  You'd have to switch it to display:block or
appearance:none or whatever to get full power, and then you lose the
more magical aspects of popout behavior.  (And browsers can always
force it into the magical mode with a UA !important rule, which mobile
browsers probably should do.)

~TJ

Re: Styling form control elements

[Jonas Sicking]

On Tue, Dec 10, 2013 at 8:24 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Wed, Dec 11, 2013 at 2:46 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 12/10/13 6:30 PM, Jonas Sicking wrote:

 I would also think that you need properties to position the ::popout.


 Oh, yes.  The extra fun here is:

 1)  Should the popout be able to paint outside the browser window? Right
 now, comboboxes (select size=1) can but normal CSS boxes cannot.

 2)  The popout needs to pop out in different directions (up or down)
 depending on the screen position of the anchor, the popout dimensions, and
 the screen dimensions.

 3)  The size of the popout needs to be capped in some way.

 Maybe all that logic should just live in the UA and the page just needs a
 way of saying here is a popout thingie, anchor it here.

 Yes, the popout thingy probably needs to be a specialized 'display'
 value that is only valid on the popout pseudo, so we can bottle the
 magic precisely.

Allowing the popout thingy to go outside of the browser window, while
at the same time allowing it to be heavily customized, scares me a
lot. At some it allows click-jacking parent windows. Or even rendering
input controls in the parent window and steal data that the user
thinks he's entering into the parent.

Even just detecting where in the parent window the user is hovering
the mouse or clicking could leak critical data if the user is unaware.

Can we define a subset of styles that are safe?

I had imagined that we pretty quickly would fall back to rendering the
popout only inside the same window. Sadly.

/ Jonas

Re: Styling form control elements

[Jonas Sicking]

On Sat, Dec 7, 2013 at 11:57 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
 From: Jonas Sicking [mailto:jo...@sicking.cc]

 The reason you've been unable to get rid of the arrow is because it's a 
 separate box that is rendered inside the outermost box. That will remain 
 true even if you use select or select::control to match the outermost 
 box.

 This is why I believe you want a new pseudo-element to select this separate 
 inner box, so that you can change it's rendering or hide it.

 I think we have somewhat divergent models of how I'd want to be styling this. 
 More below.

Actually, I think our mental models are surprisingly aligned. Which is
great! More below.

 However I'd be curious to see what your UI would look like. Should be easy 
 to do by simply using a DOM like.

 div class=select
   div class=optionvalue 1/div
   div class=optionvalue 2/div
 /div

 Would you mind putting together a prototype of what you had in mind?

 What I had in mind was more like this:

 div class=select
   span class=controlvalue 1/span
   div class=popout
 div class=optionvalue 1/div
 div class=optionvalue 2/div
   /div
 /div

 With the browser toggling display: none/display: block on the popout 
 according to OS-specific behaviors.

Ah! This is very similar to what I had in mind. I had imagined.

div class=select
  span class=controlvalue 1/span
  span class=arrowthingy↓/span
  div class=popout
div class=optionvalue 1/div
div class=optionvalue 2/div
  /div
/div

I.e. exactly the same but with an extra styleable hook for the down
array clickable thingy.

However using ::after to create such a down arrow seems reasonable. It
does make some styling harder, like if you want to have separate
borders around the control and the arrowthingy. But arguably that's
a shortcoming of CSS and not something we should work around here.

So dropping the arrowthingy element seems fine.

 I was about to give you a sample. I had it 95% done. But then the webpage I 
 was using interpreted a backspace as a Go Back, and when I pressed forward, 
 all my work is lost. So hopefully you can get the idea without me having to 
 re-create that :(. If not let me know and I'll give it another try.

Seems fine. I think we're on the same page.

 Along the way I discovered the following additional needs (eek, scope creep!)

I don't think this is scope creep at all. As an implementor, I'm much
less interested in implementing a styleable-formcontrols feature that
is so minimal that it won't get used, than a more complex, but
comprehensive enough solution that it's actually solving people's use
cases.

 - I indeed needed to style the option and the option hover state.

option:hover should just work, no?

 - I needed a way of telling if the parent select was open or not, so that 
 the ::control could stay in a single visual state while the popout was 
 visible, instead of changing as you hovered.

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?

I don't mind adding a pseudo-class which only matches if the select
is open though. I just didn't understand the use-case.

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.

[1] https://developer.mozilla.org/en-US/docs/XUL/PopupGuide/Positioning

 I agree. But I think this is only part of the problem since often times 
 styling the built-in controls means styling the anonymous elements that are 
 there, not getting rid of them. At least that was my vision.

 But I agree that C is important too.

 ...
 Exactly. So webkit seems closer to C, but still is definitely not C.
 If you did C there would be no popout at all, and all elements would be 
 rendered directly in the page, no?

 Right, I think there was a slight miscommunication. For C, I didn't mean 
 nuke all styles on the existing elements, I meant, nuke all styles on the 
 elements and shadow elements, but still expose to me an appropriate set of 
 styleable shadow elements (like ::control and ::popout).

That's what B is. I.e. we still keep a few shadow elements around as
to enable more rich styling. But we render those style elements using
CSS so that they can be fully styled by the web developer.

Option C is to nuke all shadow DOM and just render the raw elements.

B is already supported in all browsers I tested (didn't test IE).
However there's not always pseudo elements that allow you to target
the shadow elements. And where there is, 

RE: Styling form control elements

[Domenic Denicola]

From: Jonas Sicking jo...@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 selects...

 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...

Re: Styling form control elements

[Jonas Sicking]

On Tue, Dec 10, 2013 at 3:42 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
 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.

Makes sense. Though technically the user won't generally be hovering
the ::control when they hover the popout. Even if the pixels overlap,
I believe that CSS says that you are just hovering the topmost element
and its ancestors (or maybe that's just what all browsers implement).

However the user could still hover the ::control if it sticks out
under the ::popout.

 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...

Hard in what sense? I'd prefer to ask implementors rather than assume
that it's hard for them to implement if that's what you mean. (I can't
speak for the mozilla layout team here).

But I'm fine with postponing this. It seems like something that could
replace piles of JS in many cases, but it's mostly orthogonal to most
of what we're talking about here I suspect.

 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...

I think it does apply down the tree. I.e. applying appearance: none
to the select also means that the options render without
OS-styling applied.

However it's still not option C which would represent rendering of a tree like

div class=select
  div class=optionvalue 1/div
  div class=optionvalue 2/div
/div

Which appears not to be what you're asking for.

Though I feel like we're being inconsistent here. It seems arbitrary
that applying appearance: none removes the arrow, but still keeps a
bunch of other styles. Specifically it still keeps the styling that
renders the selected option value, and it keeps the styling that hides
and positions the popout as needed.

I know you hate that arrow, but I'd rather come up with a set of more
generic rules than equating stylable formcontrols with hiding the
arrow ;-)

Potentially the answer could be to say that appearance: css creates
a control rendered entirely using CSS and thus styleable using the
various proposed pseudo elements.

However appearance: none actually renders C, i.e. only the elements
that are in the DOM as described with the markup above. This wouldn't
be useful for a select size=1, but it could be useful for input
type=text or other form controls.

/ Jonas

Re: Styling form control elements

[Charles Pritchard]

On Dec 6, 2013, at 4:59 AM, Scott González scott.gonza...@gmail.com wrote:
 
 On Fri, Dec 6, 2013 at 5:26 AM, Brian Di Palma off...@gmail.com wrote:
 If UA controls are not styleable in the manner I wish them to be and I
 have access to custom elements + shadow DOM,
 I think I would just create my own controls and use them instead of UA ones.
 
 And you'll make the experience worse for many users because many users have 
 devices that you actually don't want to replace. Also, all the other problems 
 about validation, semantics, etc.


I've seen this theme pop up for years. There are standards of completeness-- as 
long as the browser supports a sufficient API, implementers can support 
complete widgets.

The issue is in enumerating and exposing those items which are necessary to 
construct a widget.

We talk about select, well aria has DOM semantics, pseudo-selectors may work 
for display containers, focus is and has always been mentioned, as well as 
pointer and keyboard input events within WCAG. We have input method editors for 
typeahead style select boxes.

Now we can shoot all that down and say that the UA should be the only point of 
control for custom form elements, but that just doesn't create productive 
discourse.

Enumerating and exposing a means to provide a full (Level AAA) custom control 
is a productive effort. That said, yes, I acknowledge that many controls, UA 
provided or author created have been and will be substandard.

-Charles

Re: Styling form control elements

[Boris Zbarsky]

On 12/10/13 6:30 PM, Jonas Sicking wrote:

I would also think that you need properties to position the ::popout.


Oh, yes.  The extra fun here is:

1)  Should the popout be able to paint outside the browser window? 
Right now, comboboxes (select size=1) can but normal CSS boxes cannot.


2)  The popout needs to pop out in different directions (up or down) 
depending on the screen position of the anchor, the popout dimensions, 
and the screen dimensions.


3)  The size of the popout needs to be capped in some way.

Maybe all that logic should just live in the UA and the page just needs 
a way of saying here is a popout thingie, anchor it here.


-Boris

Re: Styling form control elements

[Tab Atkins Jr.]

On Wed, Dec 11, 2013 at 2:46 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 12/10/13 6:30 PM, Jonas Sicking wrote:

 I would also think that you need properties to position the ::popout.


 Oh, yes.  The extra fun here is:

 1)  Should the popout be able to paint outside the browser window? Right
 now, comboboxes (select size=1) can but normal CSS boxes cannot.

 2)  The popout needs to pop out in different directions (up or down)
 depending on the screen position of the anchor, the popout dimensions, and
 the screen dimensions.

 3)  The size of the popout needs to be capped in some way.

 Maybe all that logic should just live in the UA and the page just needs a
 way of saying here is a popout thingie, anchor it here.

Yes, the popout thingy probably needs to be a specialized 'display'
value that is only valid on the popout pseudo, so we can bottle the
magic precisely.

~TJ

RE: Styling form control elements

[Domenic Denicola]

From: Boris Zbarsky [mailto:bzbar...@mit.edu] 

 You can, but if it doesn't match the scrollbar width in cases when there is a 
 scrollbar the result looks pretty terrible when the popup is opened...  And 
 scrollbar widths are user-configurable.

Ah! Right. Well, styling scrollbars would also be nice :). But yes, good to get 
all these subtleties written down...

However, I'd like to point out that many of the styles our designers make don't 
have a thumb at all, just an arrow of some sort. This generally doesn't need to 
match the scrollbar of the popout in any way. I'll give an example in my reply 
to Jonas.

Re: Styling form control elements

[Brian Di Palma]

If UA controls are not styleable in the manner I wish them to be and I
have access to custom elements + shadow DOM,
I think I would just create my own controls and use them instead of UA ones.

I know it sounds wasteful but I'd imagine that the best ones would end
up being reused much like jQuery UI widgets are today.

In that case does this difficult problem need to be solved?

On Fri, Dec 6, 2013 at 4:12 AM, Ryosuke Niwa rn...@apple.com wrote:
 On Dec 5, 2013, at 3:15 PM, Ian Hickson i...@hixie.ch wrote:
 On Thu, 5 Dec 2013, Jonas Sicking wrote:

 I think both are issues. I.e. I think we have two separate use cases:

 1. Enable using the built-in rendering of form controls, but style them
 using author-supplied CSS.

 2. Enable completely replacing the rendering of form controls

 I think 1 is *really* hard. Maybe hard enough that we can't do it. But I
 think it would help the web a lot if we could pull it off, so I think we
 should try.

 I think there are simple cases we can address like changing the color of 
 placeholder text, etc...

 And I think is=... is the wrong solution for 2. As is wrapping the
 control with custom elements. You should be able to attach a replacement
 style using CSS. This is what decorators is, which so far no one is
 working on afaict.

 Agreed.

 Agreed.

 On Dec 5, 2013, at 1:42 PM, Ian Hickson i...@hixie.ch wrote:
 On Thu, 5 Dec 2013, Ryosuke Niwa wrote:
 On Dec 5, 2013, at 8:49 AM, Ian Hickson i...@hixie.ch wrote:
 On the other hand, this still doesn't tell UA whether it should be
 ignoring the binding on a given platform or not (i.e. it doesn't address
 the device-specific UI control use case).

 Yeah. I don't know of a way to fix that.

 Indeed, this is a hard problem.  My point was simply that using shadow DOM or 
 custom element wouldn't magically solve this problem.

 The problem you're worried about is one that we _do_ have today on mobile
 devices with sites that aren't designed with mobile devices in mind, just
 not particularly for form control styling. For example, page widths, input
 events, all kinds of things like that, make Web pages break on mobile, or
 look bad on mobile.

 Any solution we come up with for the general problem should, in theory, be
 able to solve the problem for this specific subcase too.

 Agreed.

 On the other hand, using CSS for binding shadow DOM has a culprit that
 instantiation  life-cycle of such shadow DOM becomes a tricky issue.
 i.e. spec'ing exactly when those shadow DOM bind  unbind would be
 tricky.

 Yes. But we shouldn't shy away from hard problems. ;-)


 Agreed.  Perhaps you could write a spec for us? ;)

 - R. Niwa

Re: Styling form control elements

[Scott González]

On Fri, Dec 6, 2013 at 5:26 AM, Brian Di Palma off...@gmail.com wrote:

 If UA controls are not styleable in the manner I wish them to be and I
 have access to custom elements + shadow DOM,
 I think I would just create my own controls and use them instead of UA
 ones.


And you'll make the experience worse for many users because many users have
devices that you actually don't want to replace. Also, all the other
problems about validation, semantics, etc.

Re: Styling form control elements

[TJ VanToll]

 On Thu, 5 Dec 2013, Jonas Sicking wrote:
 
 I think both are issues. I.e. I think we have two separate use cases:
 
 1. Enable using the built-in rendering of form controls, but style them 
 using author-supplied CSS.
 
 2. Enable completely replacing the rendering of form controls


I agree and like this summation.

 On Dec 5, 2013, at 3:15 PM, Ian Hickson i...@hixie.ch wrote:
 On Thu, 5 Dec 2013, Jonas Sicking wrote:
 
 I think both are issues. I.e. I think we have two separate use cases:
 
 1. Enable using the built-in rendering of form controls, but style them 
 using author-supplied CSS.
 
 2. Enable completely replacing the rendering of form controls
 
 I think 1 is *really* hard. Maybe hard enough that we can't do it. But I 
 think it would help the web a lot if we could pull it off, so I think we 
 should try.
 
 I think there are simple cases we can address like changing the color of 
 placeholder text, etc...

The problem is that there are very few simple cases. Placeholders, range 
inputs, checkboxes, and radio buttons are the only form elements that use 
reasonably consistent rendering across platforms.

Having the UA control how data is collected from the user has had huge benefits 
for the web platform. By standardizing these pseudo elements we would be 
limiting the ability of the UA to build optimized UIs. For instance if IE’s 
::-ms-check were standardized, it would prevent a mobile device from rendering 
a checkbox as a switch without violating the spec.

As much as I would love to be able to consistently style the native controls, I 
don’t see standardizing pseudo elements as a viable solution.

TJ

On Dec 5, 2013, at 11:12 PM, Ryosuke Niwa rn...@apple.com wrote:

 On Dec 5, 2013, at 3:15 PM, Ian Hickson i...@hixie.ch wrote:
 On Thu, 5 Dec 2013, Jonas Sicking wrote:
 
 I think both are issues. I.e. I think we have two separate use cases:
 
 1. Enable using the built-in rendering of form controls, but style them 
 using author-supplied CSS.
 
 2. Enable completely replacing the rendering of form controls
 
 I think 1 is *really* hard. Maybe hard enough that we can't do it. But I 
 think it would help the web a lot if we could pull it off, so I think we 
 should try.
 
 I think there are simple cases we can address like changing the color of 
 placeholder text, etc...
 
 And I think is=... is the wrong solution for 2. As is wrapping the 
 control with custom elements. You should be able to attach a replacement 
 style using CSS. This is what decorators is, which so far no one is 
 working on afaict.
 
 Agreed.
 
 Agreed.
 
 On Dec 5, 2013, at 1:42 PM, Ian Hickson i...@hixie.ch wrote:
 On Thu, 5 Dec 2013, Ryosuke Niwa wrote:
 On Dec 5, 2013, at 8:49 AM, Ian Hickson i...@hixie.ch wrote:
 On the other hand, this still doesn't tell UA whether it should be 
 ignoring the binding on a given platform or not (i.e. it doesn't address 
 the device-specific UI control use case).
 
 Yeah. I don't know of a way to fix that.
 
 Indeed, this is a hard problem.  My point was simply that using shadow DOM or 
 custom element wouldn't magically solve this problem.
 
 The problem you're worried about is one that we _do_ have today on mobile 
 devices with sites that aren't designed with mobile devices in mind, just 
 not particularly for form control styling. For example, page widths, input 
 events, all kinds of things like that, make Web pages break on mobile, or 
 look bad on mobile.
 
 Any solution we come up with for the general problem should, in theory, be 
 able to solve the problem for this specific subcase too.
 
 Agreed.
 
 On the other hand, using CSS for binding shadow DOM has a culprit that 
 instantiation  life-cycle of such shadow DOM becomes a tricky issue.  
 i.e. spec'ing exactly when those shadow DOM bind  unbind would be 
 tricky.
 
 Yes. But we shouldn't shy away from hard problems. ;-)
 
 
 Agreed.  Perhaps you could write a spec for us? ;)
 
 - R. Niwa
 
 

Re: Styling form control elements

[Brian Di Palma]

On Fri, Dec 6, 2013 at 12:59 PM, Scott González
scott.gonza...@gmail.com wrote:
 On Fri, Dec 6, 2013 at 5:26 AM, Brian Di Palma off...@gmail.com wrote:

 If UA controls are not styleable in the manner I wish them to be and I
 have access to custom elements + shadow DOM,
 I think I would just create my own controls and use them instead of UA
 ones.


 And you'll make the experience worse for many users because many users have
 devices that you actually don't want to replace. Also, all the other
 problems about validation, semantics, etc.

I did mention that these would probably be turned into reusable
components in widget libraries.
If they hope to be used by developers I see no reason why the issues
you raised would not be addressed by those libraries.

Re: Styling form control elements

[Scott González]

On Fri, Dec 6, 2013 at 10:53 AM, Brian Di Palma off...@gmail.com wrote:

 I did mention that these would probably be turned into reusable
 components in widget libraries.
 If they hope to be used by developers I see no reason why the issues
 you raised would not be addressed by those libraries.


Are you aware of libraries addressing these issues today? As mentioned
multiple times already, there is nothing to inform a developer what UI/UX
will be most effective. This is why the best we can do right now is leave
certain devices alone while using custom UIs for other devices. But we
don't know (in code) which devices those are.

Re: Styling form control elements

[Brian Di Palma]

On Fri, Dec 6, 2013 at 4:00 PM, Scott González scott.gonza...@gmail.com wrote:
 On Fri, Dec 6, 2013 at 10:53 AM, Brian Di Palma off...@gmail.com wrote:

 I did mention that these would probably be turned into reusable
 components in widget libraries.
 If they hope to be used by developers I see no reason why the issues
 you raised would not be addressed by those libraries.


 Are you aware of libraries addressing these issues today? As mentioned
 multiple times already, there is nothing to inform a developer what UI/UX
 will be most effective. This is why the best we can do right now is leave
 certain devices alone while using custom UIs for other devices. But we don't
 know (in code) which devices those are.

Unless I'm misunderstanding you I think places like
http://component.io/ have some nice widgets.
Some of which are able to play nicely in both mobile and desktop
environments, they might be simple i.e.
http://component.io/ghinda/css-toggle-switch but they can do the job.
It doesn't seem a significant hurdle to create your own or to use a
third party control if browser's aren't as flexible as required.
It's not ideal either though.

Re: Styling form control elements

[Jonas Sicking]

On Thu, Dec 5, 2013 at 5:56 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
 From: Jonas Sicking [mailto:jo...@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, selects 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 options 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=hiinput 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=hiinput 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 options?

 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

RE: Styling form control elements

[Domenic Denicola]

From: Jonas Sicking [mailto:jo...@sicking.cc] 

 The control that you see by default can simply be targetted with select, no?

Hmm, I suppose so. Although I have been unable to get rid of the arrow (which I 
consider part of that control) with CSS. And, I have found that styles applied 
to the select often have effects on the popout, which is undesirable. So that 
is why a ::control made more sense to me.

 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.

I think this level of granularity, separating 2 and 3, is where we start to get 
into trouble. Yes, ideally I would like to style them separately. But in 
practice, just the ability to completely nuke the existing styles, and end up 
with something equivalent to divselected option text/div, would be enough 
to allow us to build our own styles. We can create our own arrows with 
(multiple) background images, or ::after.

 To make matters somewhat more complex, selects can also be rendered as a 
 list rather than as a popout. Do the above pseudo elements map to anything in 
 such a select?

Ah right, easy to forget. I'd say leave any such mapping out of a minimal 
solution. In fact I think a select multiple doesn't have any real parts; 
just the select container and the options. Maybe you'd want a :selected 
pseudo-class on the options. But in reality styling select multiple is much 
less urgent.

 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 options inside it.

 ...

 There is currently no way to make gecko use C.

This is a big problem, as what we want is the ability to just nuke the styles 
and replace them with our own.

 I believe that webkit has similar behavior. Though using -webkit-appearance: 
 none of course.

Not true, which is part of why selects are so much more styleable in Chrome 
than they are in Firefox. http://codepen.io/anon/pen/BFtgD shows that 
WebKit/Blink uses C, as far as I can tell. In particular the arrow disappears, 
which we cannot accomplish in Gecko. In fact, select can be styled perfectly 
in WebKit/Blink... at least as long as the user doesn't click on it. Once they 
do, the mostly-unstyleable popout portion is revealed, and the illusion is 
lost. (I say mostly unstylable because some things, like background-color, 
seem to get inherited from the select to the popout.)

 So when you say, default div styles, do you mean B or C?

Definitely C, although I suppose default span styles would be more 
appropriate.

 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.

I agree that C is much more useful than B. I do not know what the point of B 
would be, really. I don't think anyone consciously chooses to get the ugly 
semi-default buttons you get by adding `background-color: whatever` to a 
button; they instead do a complete overhaul with new colors, new border, new 
box shadow, new border-radius, etc.

 - No specification (for now) of individual items inside the ::popout.

 Not even the options?

Meh, would be nice, but feels like it'd be pushing it. Maybe not though. I 
guess it is pretty important to be able to control e.g. hover color/background.

 I'm certainly interested in nailing this stuff down. And I know many others 
 within mozilla are too.

Cool! It'd be great to finally crack this nut.

Re: Styling form control elements

[Boris Zbarsky]

On 12/6/13 10:25 PM, Domenic Denicola wrote:

We can create our own arrows with (multiple) background images, or ::after.


You can, but if it doesn't match the scrollbar width in cases when there 
is a scrollbar the result looks pretty terrible when the popup is 
opened...  And scrollbar widths are user-configurable.


There's some pretty painstaking code in Gecko to make the arrow bit be 
the width of the scrollbar, last I checked.


On the other hand, I think speccing option should actually be pretty 
simple if desired.  Gecko has no real magic for these in terms of 
rendering; they're just CSS blocks that happen to contain text, and you 
can style them however you please, modulo these UA styles:


option {
   float: none !important;
   position: static !important;
   line-height: normal !important;
   white-space: nowrap !important;
   word-wrap: normal !important;
}

option:checked {
  background-color: -moz-html-cellhighlight !important;
  color: -moz-html-cellhighlighttext !important;
}

and similar for checked options in focused selects but with a different 
color/background.


And even for the :checked case I'd love it if we could allow pages to 
style them somehow without just nuking the selection indicator all the 
time, which is what they do now if we allow changing the color and 
background there.


Now whether you can convince other UAs to use CSS for their options, 
that's a good question.


-Boris

Re: Styling form control elements

[Jonas Sicking]

On Fri, Dec 6, 2013 at 7:25 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
 From: Jonas Sicking [mailto:jo...@sicking.cc]

 The control that you see by default can simply be targetted with select, 
 no?

 Hmm, I suppose so. Although I have been unable to get rid of the arrow (which 
 I consider part of that control) with CSS. And, I have found that styles 
 applied to the select often have effects on the popout, which is 
 undesirable. So that is why a ::control made more sense to me.

The reason you've been unable to get rid of the arrow is because it's
a separate box that is rendered inside the outermost box. That will
remain true even if you use select or select::control to match the
outermost box.

This is why I believe you want a new pseudo-element to select this
separate inner box, so that you can change it's rendering or hide it.

 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.

 I think this level of granularity, separating 2 and 3, is where we start to 
 get into trouble. Yes, ideally I would like to style them separately. But in 
 practice, just the ability to completely nuke the existing styles, and end up 
 with something equivalent to divselected option text/div, would be enough 
 to allow us to build our own styles. We can create our own arrows with 
 (multiple) background images, or ::after.

Do you really think you can build a good select UI using just the
elements elements available in the DOM plus CSS? I.e. using just an
outer element select element and then one inner option element for
each value? In gecko we end up adding a bunch of hidden shadow DOM as
well as some logic not expressible in CSS.

Granted, our UI has been designed by engineers and not designers :)

However I'd be curious to see what your UI would look like. Should be
easy to do by simply using a DOM like.

div class=select
  div class=optionvalue 1/div
  div class=optionvalue 2/div
/div

Would you mind putting together a prototype of what you had in mind?

 To make matters somewhat more complex, selects can also be rendered as a 
 list rather than as a popout. Do the above pseudo elements map to anything 
 in such a select?

 Ah right, easy to forget. I'd say leave any such mapping out of a minimal 
 solution. In fact I think a select multiple doesn't have any real parts; 
 just the select container and the options. Maybe you'd want a :selected 
 pseudo-class on the options. But in reality styling select multiple is much 
 less urgent.

Agreed. Though I think starting with a couple of simple elements like
this is a good start. Once we embark on things like input type=date
we're going to be in a much bigger world of hurt :).

 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 options inside it.

 ...

 There is currently no way to make gecko use C.

 This is a big problem, as what we want is the ability to just nuke the styles 
 and replace them with our own.

I agree. But I think this is only part of the problem since often
times styling the built-in controls means styling the anonymous
elements that are there, not getting rid of them. At least that was my
vision.

But I agree that C is important too.

 I believe that webkit has similar behavior. Though using -webkit-appearance: 
 none of course.

 Not true, which is part of why selects are so much more styleable in Chrome 
 than they are in Firefox. http://codepen.io/anon/pen/BFtgD shows that 
 WebKit/Blink uses C, as far as I can tell. In particular the arrow 
 disappears, which we cannot accomplish in Gecko. In fact, select can be 
 styled perfectly in WebKit/Blink... at least as long as the user doesn't 
 click on it. Once they do, the mostly-unstyleable popout portion is 
 revealed, and the illusion is lost. (I say mostly unstylable because some 
 things, like background-color, seem to get inherited from the select to the 
 popout.)

Exactly. So webkit seems closer to C, but still is definitely not C.
If you did C there would be no popout at all, and all elements would
be rendered directly in the page, no?

 So when you say, default div styles, do you mean B or C?

 Definitely C, although I suppose default span styles would be more 
 appropriate.

If all we want to do is C then that's super easy really. All we need
to define is that appearance: none removes all UA styling and
reverts the control to be just plain inline (span) elements. No new
pseudo classes needed at all.

Is that enough?

That does mean though that 

Re: Styling form control elements

[Boris Zbarsky]

On 12/5/13 4:30 AM, Ryosuke Niwa wrote:

As I understand it, people want to do:

select name=cities is=map


That's not the main issue being discussed right now, as far as I can tell.

What's being discussed, I think, is that people want to do things like:

  input type=date

and then style the datepicker in some particular way.

-Boris

Re: Styling form control elements

[Scott González]

Yeah, the big issues come in with using the existing elements. Given input
type=date, we want to keep all of the semantics (the APIs, built-in
validation, etc.), but apply custom styling. Custom styling may come in the
form of CSS or it may come in the form of a completely new UI that uses JS.
The latter may or may not use shadow DOM. But the important thing is that
we don't actually want to create a new element type, we want to leverage
the existing ones. To complicate this further, we may want to just leave it
alone in some devices because the native behavior is already optimized.
Unfortunately it's hard to tell when that's the case.


On Thu, Dec 5, 2013 at 10:38 AM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 12/5/13 4:30 AM, Ryosuke Niwa wrote:

 As I understand it, people want to do:

 select name=cities is=map


 That's not the main issue being discussed right now, as far as I can tell.

 What's being discussed, I think, is that people want to do things like:

   input type=date

 and then style the datepicker in some particular way.

 -Boris

Re: Styling form control elements

[Ryosuke Niwa]

On Dec 5, 2013, at 7:38 AM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 12/5/13 4:30 AM, Ryosuke Niwa wrote:
 As I understand it, people want to do:
 
 select name=cities is=map
 
 That's not the main issue being discussed right now, as far as I can tell.

Sorry, I should have been more explicit in my email but I intended to ask 
specifically about using web components for styling control elements.

 What's being discussed, I think, is that people want to do things like:
 
  input type=date
 
 and then style the datepicker in some particular way.

Right.  WebKit (and quite possibly Blink) exposes some special pseudo elements 
to do that kind of stuff: http://trac.webkit.org/wiki/Styling%20Form%20Controls 
 My initial thinking was that we could be standardizing some of these pseudo 
elements.  And accessibility works great if we did that because AT could simply 
ignore (some) styles.


But I've heard an argument that this is not flexible enough, and we should be 
using Web components to solve this problem. The problem, however, is that:

On Dec 5, 2013, at 7:58 AM, Scott González scott.gonza...@gmail.com wrote:

 Given input type=date, we want to keep all of the semantics (the APIs, 
 built-in validation, etc.), but apply custom styling. Custom styling may come 
 in the form of CSS or it may come in the form of a completely new UI that 
 uses JS. The latter may or may not use shadow DOM. But the important thing is 
 that we don't actually want to create a new element type, we want to leverage 
 the existing ones. To complicate this further, we may want to just leave it 
 alone in some devices because the native behavior is already optimized. 
 Unfortunately it's hard to tell when that's the case.

Precisely.

Consider mobile browsers for example.  When mobile browsers initially came out, 
many websites in the wild didn't take mobile browsers into account.  In that 
world, we would like to replace the UI of all custom form controls.  However, 
as the Web evolved to support mobile usage, a lot of websites started having 
mobile versions and UI specifically designed for some mobile operating systems. 
 Unfortunately, web components doesn't give us some magical mechanism by which 
UA determines that a certain custom form control should be replaced by a native 
control.

Furthermore, we can't simply replace custom element with a native form 
control if the custom element could provide some JS API because that'll be 
exposed to the rest of the page.  We can't just swap the UI or what's being 
exposed to AT without changing what's being displayed on the screen since some 
ATs such as Voice Over needs to highlight what's been focused, etc… on the 
screen.

I'd love to solve this problem because I deeply care about accessibility but I 
don't think using shadow DOM magically solves it.

- R. Niwa

Re: Styling form control elements

[Ian Hickson]

On Thu, 5 Dec 2013, Ryosuke Niwa wrote:
 
 Let me understand the problem of styling/replacing builtin form controls.
 
 As I understand it, people want to do:
 
 select name=cities is=map
 optionOakland/option
 optionSan Francisco/option
 optionSan Jose/option
 ...
 /select
 or
 input is=switch type=checkbox ...
 
 to have a nice fallback when is / shadow DOM is not supported.
 
 Why can't we just do:
 map
 select name=cities
 optionOakland/option
 optionSan Francisco/option
 optionSan Jose/option
 ...
 /select
 /map
 and
 switchinput type=checkbox .../switch
 
 instead?

I suppose you _could_ do that, but it would mean that author-defined 
widgets would be second class citizens.

Personally what I'd like is:

 select name=cities
  optionOakland/option
  optionSan Francisco/option
  optionSan Jose/option
  ...
 /select

...with:

 select[name=cities] { binding: url(map); }
   
...in the CSS, since this is just presentation.


 What is so special about form controls or custom elements that warrant a 
 completely different mechanism?

Different than what? I'd love the markup to not be different whether or 
not we're using custom widget presentations.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: Styling form control elements

[Ian Hickson]

On Thu, 5 Dec 2013, Ryosuke Niwa wrote:
 On Dec 5, 2013, at 8:49 AM, Ian Hickson i...@hixie.ch wrote:
  On Thu, 5 Dec 2013, Ryosuke Niwa wrote:
  
  Let me understand the problem of styling/replacing builtin form 
  controls.
  
  As I understand it, people want to do:
  
  select name=cities is=map
  optionOakland/option
  optionSan Francisco/option
  optionSan Jose/option
  ...
  /select
  or
  input is=switch type=checkbox ...
  
  to have a nice fallback when is / shadow DOM is not supported.
  
  Why can't we just do:
  map
  select name=cities
  optionOakland/option
  optionSan Francisco/option
  optionSan Jose/option
  ...
  /select
  /map
  and
  switchinput type=checkbox .../switch
  
  instead?
  
  I suppose you _could_ do that, but it would mean that author-defined 
  widgets would be second class citizens.
 
 Could you elaborate on what you mean by this?

Well for example they wouldn't participate in form.elements, the 
submission model would presumably defer to the select, etc. That is to 
say, the map in the example above is just for style, whereas the 
select in the example above is where all the logic lies.


  Personally what I'd like is:
  
  select name=cities
   optionOakland/option
   optionSan Francisco/option
   optionSan Jose/option
   ...
  /select
  
  ...with:
  
  select[name=cities] { binding: url(map); }
  
  ...in the CSS, since this is just presentation.
 
 This approach is better than using custom element in that author can't 
 expose a new JS API or override existing ones so that UA can safely NOT 
 apply the binding if wanted.

Right.


 On the other hand, this still doesn't tell UA whether it should be 
 ignoring the binding on a given platform or not (i.e. it doesn't address 
 the device-specific UI control use case).

Yeah. I don't know of a way to fix that.

The problem you're worried about is one that we _do_ have today on mobile 
devices with sites that aren't designed with mobile devices in mind, just 
not particularly for form control styling. For example, page widths, input 
events, all kinds of things like that, make Web pages break on mobile, or 
look bad on mobile.

Any solution we come up with for the general problem should, in theory, be 
able to solve the problem for this specific subcase too.


 On the other hand, using CSS for binding shadow DOM has a culprit that 
 instantiation  life-cycle of such shadow DOM becomes a tricky issue.  
 i.e. spec'ing exactly when those shadow DOM bind  unbind would be 
 tricky.

Yes. But we shouldn't shy away from hard problems. ;-)

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: Styling form control elements

[Jonas Sicking]

On Thu, Dec 5, 2013 at 7:38 AM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 12/5/13 4:30 AM, Ryosuke Niwa wrote:

 As I understand it, people want to do:

 select name=cities is=map

 That's not the main issue being discussed right now, as far as I can tell.
 What's being discussed, I think, is that people want to do things like:

   input type=date

 and then style the datepicker in some particular way.

I think both are issues. I.e. I think we have two separate use cases:

1. Enable using the built-in rendering of form controls, but style
them using author-supplied CSS.
2. Enable completely replacing the rendering of form controls

I think 1 is *really* hard. Maybe hard enough that we can't do it. But
I think it would help the web a lot if we could pull it off, so I
think we should try.

And I think is=... is the wrong solution for 2. As is wrapping the
control with custom elements. You should be able to attach a
replacement style using CSS. This is what decorators is, which so far
no one is working on afaict.

/ Jonas

Re: Styling form control elements

[Ian Hickson]

On Thu, 5 Dec 2013, Jonas Sicking wrote:
 
 I think both are issues. I.e. I think we have two separate use cases:
 
 1. Enable using the built-in rendering of form controls, but style them 
 using author-supplied CSS.

 2. Enable completely replacing the rendering of form controls
 
 I think 1 is *really* hard. Maybe hard enough that we can't do it. But I 
 think it would help the web a lot if we could pull it off, so I think we 
 should try.
 
 And I think is=... is the wrong solution for 2. As is wrapping the 
 control with custom elements. You should be able to attach a replacement 
 style using CSS. This is what decorators is, which so far no one is 
 working on afaict.

Agreed.

I think #1 is easier than it looks, though. My vision for doing this would 
be to define some pseudo-elements we say a browser can provide, explained 
as the browser using some default binding that declares those pseudo- 
elements (thought obviously behind the hood it doesn't need to be done 
that way). Obviously there's a limit to how much you can do with just 
this, but I think if we provide sufficient hooks, there needn't be that 
much of a limit.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: Styling form control elements

[Jonas Sicking]

On Thu, Dec 5, 2013 at 3:15 PM, Ian Hickson i...@hixie.ch wrote:
 On Thu, 5 Dec 2013, Jonas Sicking wrote:

 I think both are issues. I.e. I think we have two separate use cases:

 1. Enable using the built-in rendering of form controls, but style them
 using author-supplied CSS.

 2. Enable completely replacing the rendering of form controls

 I think 1 is *really* hard. Maybe hard enough that we can't do it. But I
 think it would help the web a lot if we could pull it off, so I think we
 should try.

 And I think is=... is the wrong solution for 2. As is wrapping the
 control with custom elements. You should be able to attach a replacement
 style using CSS. This is what decorators is, which so far no one is
 working on afaict.

 Agreed.

 I think #1 is easier than it looks, though. My vision for doing this would
 be to define some pseudo-elements we say a browser can provide, explained
 as the browser using some default binding that declares those pseudo-
 elements (thought obviously behind the hood it doesn't need to be done
 that way). Obviously there's a limit to how much you can do with just
 this, but I think if we provide sufficient hooks, there needn't be that
 much of a limit.

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.e. I'm worried about creating something that is a decent amount of
work to implement, but that in practice doesn't work well enough in
practice that authors can use it as much as we'd like them to.

I don't think it'll work if we simply toss a pile of pseudo elements
into a spec and then hope that implementations validate that it's a
good enough set to solve the use case before they deploy it.

/ Jonas

RE: Styling form control elements

[Domenic Denicola]

From: Jonas Sicking [mailto:jo...@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.)
- 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.)
- `appearance: none` on both reverts them to the default div styles, i.e. no 
styles.
- No specification (for now) of individual items inside the ::popout.

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.

Re: Styling form control elements

[Ryosuke Niwa]

On Dec 5, 2013, at 3:15 PM, Ian Hickson i...@hixie.ch wrote:
 On Thu, 5 Dec 2013, Jonas Sicking wrote:
 
 I think both are issues. I.e. I think we have two separate use cases:
 
 1. Enable using the built-in rendering of form controls, but style them 
 using author-supplied CSS.
 
 2. Enable completely replacing the rendering of form controls
 
 I think 1 is *really* hard. Maybe hard enough that we can't do it. But I 
 think it would help the web a lot if we could pull it off, so I think we 
 should try.

I think there are simple cases we can address like changing the color of 
placeholder text, etc...

 And I think is=... is the wrong solution for 2. As is wrapping the 
 control with custom elements. You should be able to attach a replacement 
 style using CSS. This is what decorators is, which so far no one is 
 working on afaict.
 
 Agreed.

Agreed.

On Dec 5, 2013, at 1:42 PM, Ian Hickson i...@hixie.ch wrote:
 On Thu, 5 Dec 2013, Ryosuke Niwa wrote:
 On Dec 5, 2013, at 8:49 AM, Ian Hickson i...@hixie.ch wrote:
 On the other hand, this still doesn't tell UA whether it should be 
 ignoring the binding on a given platform or not (i.e. it doesn't address 
 the device-specific UI control use case).
 
 Yeah. I don't know of a way to fix that.

Indeed, this is a hard problem.  My point was simply that using shadow DOM or 
custom element wouldn't magically solve this problem.

 The problem you're worried about is one that we _do_ have today on mobile 
 devices with sites that aren't designed with mobile devices in mind, just 
 not particularly for form control styling. For example, page widths, input 
 events, all kinds of things like that, make Web pages break on mobile, or 
 look bad on mobile.
 
 Any solution we come up with for the general problem should, in theory, be 
 able to solve the problem for this specific subcase too.

Agreed.

 On the other hand, using CSS for binding shadow DOM has a culprit that 
 instantiation  life-cycle of such shadow DOM becomes a tricky issue.  
 i.e. spec'ing exactly when those shadow DOM bind  unbind would be 
 tricky.
 
 Yes. But we shouldn't shy away from hard problems. ;-)


Agreed.  Perhaps you could write a spec for us? ;)

- R. Niwa