Re: Styling form control elements

> 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 <ian@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 <rniwa@apple.com> wrote:

> On Dec 5, 2013, at 3:15 PM, Ian Hickson <ian@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 <ian@hixie.ch> wrote:
>> On Thu, 5 Dec 2013, Ryosuke Niwa wrote:
>>> On Dec 5, 2013, at 8:49 AM, Ian Hickson <ian@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
> 
>