Re: [css-forms][css-ui] Styling native components, a proposal

On Tue, Mar 29, 2016 at 1:41 PM, Lea Verou <lea@verou.me> wrote:
>> On 28Mar, 2016, at 17:45, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> Unfortunately, this proposal mostly only addresses the syntax side of
>> styling form controls, which isn't a huge deal.  Moving from the
>> existing specialized pseudo-elements to a single functional
>> pseudo-element with specialized keywords is a fairly trivial change;
>> the main thing it accomplishes is to let us sidestep the broken
>> unrecognized-selector behavior.
>
> But that is the main pain at the moment!! Having to duplicate code several times to work around illegal selector parsing rules. Please do not underestimate how serious an issue this is because it doesn't address all the problems you want to solve.

Don't misunderstand me; I totally understand the pain of the broken
selector behavior.  If that's something you want to fix, tho, we can
do that in a generic way that fixes things for *all* cases, with no
more difficulty than what you're proposing here.

For example, maybe we can still change :matches() to technically
accept anything, and then make a best-effort parse of the selector in
the "expected" error-recovering way (split on top-level comma, then
try to parse each one as a <complex-selector>, throwing out ones that
fail), so all you'd have to do is wrap your selector in :matches() to
make it act better.  Or if not, maybe we can just invent another
function which does the same.

>> This doesn't, however, address the actual problems inherent in styling
>> form controls, which is that they constitute a varied and changing set
>> of displays which don't seem to be amenable to arbitrary styling in
>> general.  The same inputs can have drastically different styling
>> across platforms, and can change styling between versions of the same
>> platform, and the "pieces" can have appearances which can't be easily
>> tweaked via normal CSS properties.
>
> Then parts that don't make sense are not available in those platforms, just like what happens with the pseudo-elements today. I have not met a single author that considers this a serious problem. They try properties, some work, some don't. They're all struggling with the issue I mentioned above.

I get that, *but that sucks*. It means that only the most popular
platforms that the author went out of their way to test get the nice
styles.  We can do better than that.

It also means that if a browser changes its display in any significant
way, it needs to use a totally different name for the changed parts.
The old ones get tainted by previous styling, both from the previous
browser version, and the same browser on different platforms, or
different browsers on the same platform.  The browser-specific names
we have today suck, but at least they prevent browsers squatting on
names or accidentally colliding with other browsers.

>> We talked about this in the existing Forms spec that fantasai and I
>> wrote to start working on this: <https://drafts.csswg.org/css-forms/>.
>> Without an actual fix for these issues, we're just shuffling the
>> existing problems around, which doesn't accomplish much.  We'd love to
>> get more examples of UIs, and get browser implementors interested in
>> solving this, but right now this continues to be low-priority,
>> unfortunately. :/
>
> I provided dozens of links in my email, and they come with examples. There really isn't a shortage of examples of styled controls on the Web.

Sorry, I'm talking about *default platform UI*, so we know what sort
of varying displays there are that need to be accommodated.

> Also, standardizing the components' UI parts will most likely result in the lowest common denominator being the one standardized. Do we really want another Java Swing on the Web? :/

Today, right now, we have forms that are almost always unstyled, or
only very lightly styled, and tend to clash terribly with the outside
page.  A small fraction of sites do more extensive styling with the
browser-specific pseudo-elements, but that doesn't apply to most.

There *is* a way to identify what sorts of style we can reasonably
apply across visual styles.  I'm confident that it's a large enough
subset to satisfy most use-cases.  We just need to find it.

~TJ

Received on Tuesday, 29 March 2016 21:16:07 UTC