Vender prefix for form control shadow dom pseudo ids

[Keishi Hattori]

Hi.

I'm working on transitioning the <select> element from a custom renderer to shadow dom.

Right now we specify the style for shadow dom elements inside html.css using pseudo ids like -webkit-progress-bar. So I plan to do the same and add some new pseudo ids.

Obviously I can't use the "-webkit-" prefix, so may I use "-blink-" for my new pseudo ids?

- Keishi

[Adam Barth]

We should not introduce any -blink- prefixed properties.  We might need to find a new mechanism to accomplish this task.

Adam

[Dimitri Glazkov]

What a cool task! Let's start sharing design docs and try to figure
out how we could accomplish this, what primitives we might need, and
what's the path to get there.

:DG<

[Elliott Sprehn]

On Sun, Apr 7, 2013 at 9:01 PM, Adam Barth <aba...@chromium.org> wrote:

We should not introduce any -blink- prefixed properties.  We might need to find a new mechanism to accomplish this task.

These aren't properties, they're elements inside the _platform_ provided components and are inherently specific to blink. This feature has existed in every browser for a long time and doesn't need fixing. :)

I'd rather we didn't come up with a complicated solution to a problem that doesn't exist. Even mozilla still uses -moz for these since the spec has no authority to dictate what the inside of our shadow DOM looks like and shouldn't since different OS'es need different things in there (ex. Android vs Desktop). 

Also note that the Shadow DOM spec for pseudo@ has specific rules in it for things that start with dash so that we can support select::-blink-separator { background: red; } style things.

- E 

[Elliott Sprehn]

Introducing new primitives to the platform because we're allergic to seeing our own name in the CSS is silly, lets not do that. We don't need any new hammers here.

- E 

[Adam Barth]

Are these properties visible to the web?  More specifically, can a web site detect that we've used a -blink- name?  If so, we should figure out how to implement this feature without leaking these implementation details to the web.

Adam

[Elliott Sprehn]

Yes, but that's the point. Every browser has a different shadow DOM structure, and so do different operating systems. You need to be able to style each one differently. Otherwise we're saying the HTML5 spec should dictate the internal structure of our Shadow DOM. 

We should be leaking the implementation details, that's what these are for.

- E

[Adam Barth]

I think I might be misunderstanding.  It sounds like you're saying we want web developers to write engine-specific CSS.  Don't we want web developers to write standards-based CSS that works the same way in every rendering engine?

Adam

[Daniel Freedman]

While it may be the case that some shadow dom constructions are too platform specific to mandate in a specification, I think it would be a noble goal to strive towards a pseudo-element naming convention that is without prefix.

The most common example I've worked with for pseudo element styling is the input placeholder. As of this moment, all the major vendors support styling the placeholder through input::-{vendor}-input-placeholder.

As a developer, writing `input::-webkit-input-placeholder, input::-moz-input-placeholder, input::-ms-input-placeholder, input::-blink-input-placeholder, input::-NEW_THING-input-placeholder { color: rgba(some different gray) }` is the same sort of awfulness as all the versions of -{vendor}-transform.

If Blink could be the impetus for the dropping of all prefixes for all the web platform, and I could finally just write `input::placeholder{ .. }`, then what a wonderful world it would be.

Now, as for select element, I'm not sure what the pseudo element names would look like, but I have to give an emphatic +1 to FINALLY being able to style that thing.

If it could be without a `-blink` prefix, that would be great, but anything at all that makes it so that no one has to write a custom one just to change some colors is a major win.

[Elliott Sprehn]

On Mon, Apr 8, 2013 at 10:19 AM, Adam Barth <aba...@chromium.org> wrote:

...

We should be leaking the implementation details, that's what these are for.

I think I might be misunderstanding.  It sounds like you're saying we want web developers to write engine-specific CSS.  Don't we want web developers to write standards-based CSS that works the same way in every rendering engine?

That's exactly what I'm saying, yes. Having a standard here would dictate the internal structure of our Shadow DOM and our internal styling, and would be bad for mobile and future devices since not every device even implements <select> as a drop down menu.

- E

[Elliott Sprehn]

On Mon, Apr 8, 2013 at 10:21 AM, Daniel Freedman <dfr...@chromium.org> wrote:

While it may be the case that some shadow dom constructions are too platform specific to mandate in a specification, I think it would be a noble goal to strive towards a pseudo-element naming convention that is without prefix.

The most common example I've worked with for pseudo element styling is the input placeholder. As of this moment, all the major vendors support styling the placeholder through input::-{vendor}-input-placeholder.

As a developer, writing `input::-webkit-input-placeholder, input::-moz-input-placeholder, input::-ms-input-placeholder, input::-blink-input-placeholder, input::-NEW_THING-input-placeholder { color: rgba(some different gray) }` is the same sort of awfulness as all the versions of -{vendor}-transform.

If Blink could be the impetus for the dropping of all prefixes for all the web platform, and I could finally just write `input::placeholder{ .. }`, then what a wonderful world it would be.

This doesn't work as you think it does though without forcing every browser to implement the same shadow DOM and internal CSS styling for inputs.

Mozilla could have: 

<div><div style="padding-left: 5px"><div pseudo="-moz-placeholder"></div></div></div>

Webkit could have:

<div  style="margin-left: 3px"><div pseudo="-moz-placeholder"></div></div>

Opera mobile could have:

<div pseudo="-moz-placeholder"></div>

If your plan was to style the place holder to a different location you need to do so in an engine specific manner.

Honestly this isn't a problem that needs solving right now. What we do works just fine, and blocking our implementation of <select> on trying to solve a problem in every browser makes us slow. I'd suggest we just use -webkit for now since that's what all our other pseudo elements use.

- E

[Daniel Freedman]

On Mon, Apr 8, 2013 at 10:28 AM, Elliott Sprehn <esp...@chromium.org> wrote:

On Mon, Apr 8, 2013 at 10:21 AM, Daniel Freedman <dfr...@chromium.org> wrote:

While it may be the case that some shadow dom constructions are too platform specific to mandate in a specification, I think it would be a noble goal to strive towards a pseudo-element naming convention that is without prefix.

The most common example I've worked with for pseudo element styling is the input placeholder. As of this moment, all the major vendors support styling the placeholder through input::-{vendor}-input-placeholder.

As a developer, writing `input::-webkit-input-placeholder, input::-moz-input-placeholder, input::-ms-input-placeholder, input::-blink-input-placeholder, input::-NEW_THING-input-placeholder { color: rgba(some different gray) }` is the same sort of awfulness as all the versions of -{vendor}-transform.

If Blink could be the impetus for the dropping of all prefixes for all the web platform, and I could finally just write `input::placeholder{ .. }`, then what a wonderful world it would be.

This doesn't work as you think it does though without forcing every browser to implement the same shadow DOM and internal CSS styling for inputs.

Mozilla could have: 

<div><div style="padding-left: 5px"><div pseudo="-moz-placeholder"></div></div></div>

Webkit could have:

<div  style="margin-left: 3px"><div pseudo="-moz-placeholder"></div></div>

Opera mobile could have:

<div pseudo="-moz-placeholder"></div>

If your plan was to style the place holder to a different location you need to do so in an engine specific manner.

Yes, that would be problematic for placement. Coloring is still not solvable without long, identical-but-for-prefix selectors. Maybe CSS variables baked into the spec would be more sufficient? 

Honestly this isn't a problem that needs solving right now. What we do works just fine, and blocking our implementation of <select> on trying to solve a problem in every browser makes us slow. I'd suggest we just use -webkit for now since that's what all our other pseudo elements use.

 

Absolutely agree that this discussion shouldn't block <select>. `select::-{prefix}-{options inside}` today is certainly better than `select::{options-inside}` that may never come around.

- E

[Anne van Kesteren]

On Monday, April 8, 2013 6:28:38 PM UTC+1, Elliott Sprehn wrote:

This doesn't work as you think it does though without forcing every browser to implement the same shadow DOM and internal CSS styling for inputs.

FWIW, I think Mozilla would be happy to converge where we can so if you have the resources to document the bindings (e.g. on the WHATWG Wiki) that might be a very good start to solving the form control issue.

[Jarred Nicholls]

Wouldn't it be wise to at least concur on a prefix going forward?  Since <select> will be new, I'd say this is the opportunity to decide that now; funny, that's exactly what the OP is questioning.

Sticking to -webkit- would not allow <select> to change to something different later on without breaking content.  Unless, there is an ability to assign multiple pseudos?  In that case there's no need to decide anything now and a change can be done all at once.  I don't know the answer to that question.

 

- E

[PhistucK]

This is indeed problematic. I have a proposal which is probably the worst of both of the worlds from some perspective, but, still.

Currently, unknown pseudo element selectors invalidates the entire rule.

For example -

::-moz-placeholder,

::-webkit-input-placeholder

{

 color: blue;

}

This does nothing in WebKit and in Gecko.

While I agree the prefixes are bad, not everything can or should be standardized (though I could also argue otherwise). Some implementation details are worth leaking.

Therefore, perhaps some new parsing rules should be added and some convention for implementation details.

::-(prefix)-internal-(name)

The difference is that these selectors with these pseudo elements can be combined.

::-webkit-internal-option-list, ::moz-internal-option-list

{

 color: blue;

}

This can make it easier to handle implementation details while explicitly exposing the fact that they are internal to the engine and saving a lot of bits when writing CSS.

Yeah, that is not such a good idea. :)

☆PhistucK

[TAMURA, Kent]

If CSS rulesets for such shadow elements are not many, we can avoid to name a pseudo ID and can specify style by C++ code.  See http://src.chromium.org/viewvc/blink/trunk/Source/WebCore/html/shadow/TextControlInnerElements.cpp?revision=146977#l123

--
TAMURA Kent
Software Engineer, Google

[PhistucK]

Would that prevent web developers from using these?

If so, the whole point is that web developers can use these (and that it is a legitimate use).

☆PhistucK

[Eric Seidel]

Most use of -webkit- in html.css are for internal-only properties
which have no plan for standardization (and may not even exist in
tomorrow's Blink). Example :-webkit-seamless-document:
http://trac.webkit.org/browser/trunk/Source/WebCore/css/html.css#L63

These aren't really intended to be exposed to the web, but are as a
side effect of not having special code to remove them from
site-visible CSS.

Hixie has long exploited this internal-css-properties browser practice
on his personal site to do evil things... :p I'm sure other webdevs
have discovered these internal properties and play with them. Ideally
we'd have ways to not expose them to the web at all.

There is another class of -webkit- uses in html.css which are
standardizable properties which are currently -webkit-prefixed. Such
as -webkit-any:
http://trac.webkit.org/browser/trunk/Source/WebCore/css/html.css#L180

I think that these are two separate issues. One of which should
probably use -internal- and be special cased to be not accessible from
the web, and the other of which should remain -webkit- until we can
deprecate/standardize them.

I think we should do our best to coordinate with other browser vendors
to do this. I'm not exactly sure what the CSSOM or getComputedValue
should return when using an -internal- css value, for instance. :)

[Ojan Vafai]

On Mon, Apr 8, 2013 at 11:33 PM, Eric Seidel <ese...@chromium.org> wrote:

Most use of -webkit- in html.css are for internal-only properties
which have no plan for standardization (and may not even exist in
tomorrow's Blink).  Example :-webkit-seamless-document:
http://trac.webkit.org/browser/trunk/Source/WebCore/css/html.css#L63

These aren't really intended to be exposed to the web, but are as a
side effect of not having special code to remove them from
site-visible CSS.

Hixie has long exploited this internal-css-properties browser practice
on his personal site to do evil things... :p  I'm sure other webdevs
have discovered these internal properties and play with them.  Ideally
we'd have ways to not expose them to the web at all.

There is another class of -webkit- uses in html.css which are
standardizable properties which are currently -webkit-prefixed.  Such
as -webkit-any:
http://trac.webkit.org/browser/trunk/Source/WebCore/css/html.css#L180

I think that these are two separate issues.  One of which should
probably use -internal- and be special cased to be not accessible from
the web, and the other of which should remain -webkit- until we can
deprecate/standardize them.

+1. We should not expose property names that are just implementation detail. If nothing else, they have historically been a frequent source of security bugs because the C++ side code isn't expecting them to be styled e.g. with display: none.

It's very useful to be able to use CSS in html.css to style these things, so I think it's still fine to use the pseudos. We just need to make these things only parse and/or apply when listed inside the UserAgent stylesheet.

 

I think we should do our best to coordinate with other browser vendors
to do this.  I'm not exactly sure what the CSSOM or getComputedValue
should return when using an -internal- css value, for instance. :)

I'm confused. If these aren't exposed to the web, then why does CSSOM or getComputedValue need to know anything about them?

[Eric Seidel]

If they aren't exposed to the web, then what is? :)

Take -webkit-marquee for instance:
http://trac.webkit.org/browser/trunk/Source/WebCore/css/html.css#L90

That's an internal property, which has no plans of standardization, if
I'm understanding it correctly (if it's not then there are other
examples of such). What do we return for marquee.style.overflow?
Presumably "none" or some other mapping to an "exposed" property.
Then of course marquee.style.overflow = marquee.style.overflow acts a
bit odd. :) But I could live with that oddity.

[Elliott Sprehn]

I think there is confusion here about properties vs pseudo _elements_. If we don't expose the psuedo elements to the web then developers can't style form controls which I think would make a large number of folks rather upset. :)

I think we should either continue using -webkit for the pseudo elements or use -blink for ours. It'd probably be best to use -blink though so we don't have two different implementations of <select> where select::-webkit-separator mean entirely different things.

[Dominic Cooney]

What about:

1. First, do no harm. No new pseudo IDs; have some mechanism where C++ does the styling or the pseudo-ids only work in rules in the UA stylesheet.

2. Start working in public-webapps with other vendors to specify these.

Dominic

[Elliott Sprehn]

On Tue, Apr 9, 2013 at 12:32 AM, Dominic Cooney <domi...@chromium.org> wrote:

What about:

1. First, do no harm. No new pseudo IDs; have some mechanism where C++ does the styling or the pseudo-ids only work in rules in the UA stylesheet.

2. Start working in public-webapps with other vendors to specify these.

The down side of this is that it means the HTML5 spec is now in the business of specifying our internal structure for Shadow DOM on all platforms: Android, Google TV, Chrome OS, future smart refrigerators, ...

I really don't think it benefits anyone to specify how form controls are internally. It just makes it harder to port web content to different devices.

I don't really understand why we're suddenly so allergic to pseudo elements for styling form internals. This worked fine in all browsers historically and is completely orthogonal to the vendor prefixed property debacle. I really feel like we're solving a problem that doesn't exist.

- E

[James Robinson]

In what way is it orthogonal?  Using these pseudos requires authoring engine-specific content, which is precisely the vendor prefixed property debacle.

- James

 

- E

[Ojan Vafai]

We were just talking about pseudos. I don't think we should be using CSS property values for implementation details like this. If we were to add something like this now (and we were not planning on standardizing it), I would suggest we do it as a separate property that we only expose to the UA stylesheet instead of adding a new value to a publicly accessible property, e.g.,

marquee {

    -internal-overflow-behavior-controller-thingy: marquee;

}

Even better than "-internal", we could use some character that's not allowed in real stylesheets to demarcate internal only bits.

[Elliott Sprehn]

On Tue, Apr 9, 2013 at 12:43 AM, James Robinson <jam...@chromium.org> wrote:

...

In what way is it orthogonal?  Using these pseudos requires authoring engine-specific content, which is precisely the vendor prefixed property debacle.

There was never an issue with vendor prefixes for pseudo elements, in fact all the debating about vendor prefixes was about properties and content not working across browsers. The inside of an input is inherently platform specific, unlike something like linear-gradient.

ex. Some platforms have lots of parts for the scrollbar, some don't, it doesn't make sense for the spec to dictate what parts of the scrollbar exist. OS 10.9 might have new ones, or Chrome OS might even remove some.

Apparently I'm the only one who cares about this so I guess I'll concede, but I think we're making a mistake by becoming so allergic to vendor prefixes to the point of harming the web in the process, even more so than Mozilla is (ex. they still use -moz pseudo elements, and they also just shipped mozPay).

- E

[TAMURA, Kent]

There are three types of pseudo elements:

A) Just for internal use.  It would not be helpful for web authors.

  e.g. ::-webkit-seamless-document ::-webkit-textfield-decoration-container

B) UA-independent, possible candidate for standardization

  e.g.  ::-webkit-input-placeholder

C) UA-dependent, can't be standardized, but would be useful for web authors.

  e.g.  ::-webkit-inner-spin-button

I think what we should do for A and B is obvious. We just do Dominic's step 1 for A, do the step 1 and 2 for B.  We need a policy for C.

[Keishi Hattori]

Thanks for all the comments. For my change, I think I can do the styling in C++ and avoid adding any new pseudo ids.

Blink should be a step forward in a stable web platform, so I think we should start work on providing a stable method that allows web authors to customize form controls. We have been talking about this in our team(Kent-san and I) for a while. I am hoping some pseudo elements can be standardized and for others we can expose specific customization options using something like CSS variables.

--
- Keishi