Re: Styling form control elements

On Thu, 5 Dec 2013, Ryosuke Niwa wrote:
> On Dec 5, 2013, at 8:49 AM, Ian Hickson <ian@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>
> >> <option>Oakland</option>
> >> <option>San Francisco</option>
> >> <option>San 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>
> >> <option>Oakland</option>
> >> <option>San Francisco</option>
> >> <option>San Jose</option>
> >> ...
> >> </select>
> >> </map>
> >> and
> >> <switch><input 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>
> >  <option>Oakland</option>
> >  <option>San Francisco</option>
> >  <option>San 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.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 5 December 2013 21:43:21 UTC