We should not introduce any -blink- prefixed properties. We might need to find a new mechanism to accomplish this task.
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?
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.
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
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.
- E
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. :)
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.
- E
In what way is it orthogonal? Using these pseudos requires authoring engine-specific content, which is precisely the vendor prefixed property debacle.