A proposal for un-prefixing

[Eric Seidel]

[Separating from the shadow-dom specific threads.]


My current thinking on un-prefixing is Blink should:

- Treat all -webkit-foo and webkitFoo() APIs just like any other
shipped API in our platform (they're not special or internal, we've
shipped these and may have to support them).

- Treat all prefixed APIs as “deprecated” (not change behavior other
than crash/sec fixes) and plan to remove as many of them as possible
as quickly as possible.

- Track prefixed APIs (spreadsheet?) and work to remove each
independently. Some will be no-brainers, but others may require
careful investigation, surveys, deprecation warnings, blog posts, etc.
Some we may never remove (hence how they’re like all other shipped
APIs).

- Avoid ever adding additional prefixed APIs (as we’ve already been doing).

- Prefixed -> unprefixed conversions of these APIs should still go
through the existing “intent to ship” process (be guarded by feature
flags, etc.).

[Alex Komoroske]

+1 to everything you said.

[Dimitri Glazkov]

I love it.

:DG<

[mvuj...@adobe.com]

+1. Great policy!

[Michelangelo De Simone]

+1. Seems perfect.

--
Bye,
Michelangelo

[divya....@gmail.com]

On Tuesday, April 16, 2013 1:55:01 AM UTC-7, Eric Seidel wrote:

- Avoid ever adding additional prefixed APIs (as we’ve already been doing).

I think it would be useful to outline policies on prefixed pseudo-elements that Kent Tamura outlined in this thread https://groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/blink-dev/ZAdZJWahyF8 :

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

 

Perhaps there should be a document that also tracks which of the prefixed stuff should be specced and interoperable and another that tracks how to discourage usage of UA-dependent prefixes until absolutely necessary & outlining best practices. 

[Darin Fisher]

Anything exposed to web developers [*] should be done so sans-prefix.  When it comes to enabling the styling of form control innards, it seems like we can specify what we support and expose non-prefixed pseudo-elements.  That way, if other browser vendors like what we have spec'd, they can match our implementation as well.

-Darin

[Darin Fisher]

Oops, I meant to add:

[*] The one exception is probably window.chrome.* where we have some limited API surface area added in by Chrome to expose some very Chrome-specific features.

[Eric Seidel]

I have created a first-pass spreadsheet attempting to list our current
"-webkit-" prefixed API surface:
https://docs.google.com/a/chromium.org/spreadsheet/ccc?key=0AidRaO7Awc-DdGoxdTYxRGxVT3oxMXhyR1hxbVBIdmc#gid=0

We have a huge number of CSS properties/values which are -webkit-
prefixed. I suspect that my grepping was too course, and I have
listed too many items which are not actually APIs. I've also likely
included many "internal" CSS properties which only exist in html.css
and are not intended to be exposed to the web (there is a separate
thread about enforcing that).

I've given all of commi...@chromium.org edit writes, please just
click the "share" button if you'd like to edit and your not yet a
committer, I'm happy to add you!

On Tue, Apr 16, 2013 at 1:55 AM, Eric Seidel <ese...@google.com> wrote:

[Ojan Vafai]

On Tue, Apr 16, 2013 at 1:55 AM, Eric Seidel <ese...@google.com> wrote:

My current thinking on un-prefixing is Blink should:

- Treat all -webkit-foo and webkitFoo() APIs just like any other
shipped API in our platform (they're not special or internal, we've
shipped these and may have to support them).

-  Treat all prefixed APIs as “deprecated” (not change behavior other
than crash/sec fixes) and plan to remove as many of them as possible
as quickly as possible.

One exception to not changing behavior here is where the API presents an undue implementation burden. This is especially true of we're planning on shipping an unprefixed version. Having them be different is often worse IMO than slightly breaking backwards-compatibility on the prefixed version.

[Eric Seidel]

Although it sounds like this proposal has been well received (at least
by those in PDT), I would note that those working on new CSS
properties cannot yet use this model, since it is currently impossible
to RuntimeEnabledFeature guard a CSS property. We're working on the
problem:
https://code.google.com/p/chromium/issues/detail?id=232181

But until then, I recommend that teams working on new CSS properties,
continue using their existing -webkit- prefixes. I expect we'll have
RuntimeEnabledFeature guards working for CSS properties by middle of
next week.

[Rick Byers]

It looks like prefixed JavaScript properties (like TouchEvent.webkitRadiusX) aren't listed.  I've added a few I know about and found with a quick search, but a more thorough search is probably necessary.

[Tommy Widenflycht (ᛏᚮᛘᛘᚤ)]

Also webkit prefixed constructors seems to be missing (like webkitRTCPeerConnection and webkitMediaStream).

Should they too be unprefixed asap?

[Adam Barth]

Ideally, yes.

Adam

[Pete Blois]

I don't have access to add to the list, but here's a quick grep of webkit names from the Dart bindings generation, HTH (and not sure how much of this is entirely applicable).

CSSRule.WEBKIT_FILTER_RULE

CSSRule.WEBKIT_KEYFRAMES_RULE

CSSRule.WEBKIT_KEYFRAME_RULE

CSSRule.WEBKIT_REGION_RULE

CanvasRenderingContext2D.webkitBackingStorePixelRatio

CanvasRenderingContext2D.webkitGetImageDataHD

CanvasRenderingContext2D.webkitImageSmoothingEnabled

CanvasRenderingContext2D.webkitPutImageDataHD

DataTransferItem.webkitGetAsEntry

Document.webkitCancelFullScreen

Document.webkitCurrentFullScreenElement

Document.webkitExitFullscreen

Document.webkitExitPointerLock

Document.webkitFullScreenKeyboardInputAllowed

Document.webkitFullscreenElement

Document.webkitFullscreenEnabled

Document.webkitGetNamedFlows

Document.webkitHidden

Document.webkitIsFullScreen

Document.webkitPointerLockElement

Document.webkitRegister

Document.webkitVisibilityState

Element.webkitCreateShadowRoot

Element.webkitGetRegionFlowRanges

Element.webkitInsertionParent

Element.webkitMatchesSelector

Element.webkitPseudo

Element.webkitRegionOverset

Element.webkitRequestFullScreen

Element.webkitRequestFullscreen

Element.webkitRequestPointerLock

Element.webkitShadowRoot

File.webkitRelativePath

HTMLElement.webkitdropzone

HTMLInputElement.webkitEntries

HTMLInputElement.webkitGrammar

HTMLInputElement.webkitSpeech

HTMLInputElement.webkitdirectory

HTMLMediaElement.webkitAddKey

HTMLMediaElement.webkitAudioDecodedByteCount

HTMLMediaElement.webkitCancelKeyRequest

HTMLMediaElement.webkitClosedCaptionsVisible

HTMLMediaElement.webkitGenerateKeyRequest

HTMLMediaElement.webkitHasClosedCaptions

HTMLMediaElement.webkitPreservesPitch

HTMLMediaElement.webkitVideoDecodedByteCount

HTMLVideoElement.webkitDecodedFrameCount

HTMLVideoElement.webkitDisplayingFullscreen

HTMLVideoElement.webkitDroppedFrameCount

HTMLVideoElement.webkitEnterFullScreen

HTMLVideoElement.webkitEnterFullscreen

HTMLVideoElement.webkitExitFullScreen

HTMLVideoElement.webkitExitFullscreen

HTMLVideoElement.webkitSupportsFullscreen

IDBFactory.webkitGetDatabaseNames

IDBRequest.webkitErrorMessage

IDBTransaction.webkitErrorMessage

MessageEvent.webkitInitMessageEvent

MouseEvent.webkitMovementX

MouseEvent.webkitMovementY

Navigator.webkitGetGamepads

Navigator.webkitGetUserMedia

Navigator.webkitPersistentStorage

Navigator.webkitTemporaryStorage

Performance.webkitClearMarks

Performance.webkitClearMeasures

Performance.webkitClearResourceTimings

Performance.webkitGetEntries

Performance.webkitGetEntriesByName

Performance.webkitGetEntriesByType

Performance.webkitMark

Performance.webkitMeasure

Performance.webkitSetResourceTimingBufferSize

Text.webkitInsertionParent

Touch.webkitForce

Touch.webkitRadiusX

Touch.webkitRadiusY

Touch.webkitRotationAngle

WebKitAnimationEvent

WebKitCSSFilterRule

WebKitCSSFilterValue

WebKitCSSKeyframeRule

WebKitCSSKeyframesRule

WebKitCSSMatrix

WebKitCSSMixFunctionValue

WebKitCSSRegionRule

WebKitCSSTransformValue

WebKitNamedFlow

WebKitNamedFlowCollection

WebKitPoint

WheelEvent.webkitDirectionInvertedFromDevice

Window WebKitAnimationEvent

Window WebKitCSSFilterRule

Window WebKitCSSFilterValue

Window WebKitCSSKeyframeRule

Window WebKitCSSKeyframesRule

Window WebKitCSSMatrix

Window WebKitCSSMixFunctionValue

Window WebKitCSSRegionRule

Window WebKitCSSTransformValue

Window WebKitMediaSource

Window WebKitMutationObserver

Window WebKitPoint

Window WebKitShadowRoot

Window WebKitSourceBuffer

Window WebKitSourceBufferList

Window WebKitTransitionEvent

Window.webkitAudioContext

Window.webkitAudioPannerNode

Window.webkitCancelAnimationFrame

Window.webkitCancelRequestAnimationFrame

Window.webkitConvertPointFromNodeToPage

Window.webkitConvertPointFromPageToNode

Window.webkitIDBCursor

Window.webkitIDBDatabase

Window.webkitIDBFactory

Window.webkitIDBIndex

Window.webkitIDBKeyRange

Window.webkitIDBObjectStore

Window.webkitIDBRequest

Window.webkitIDBTransaction

Window.webkitIndexedDB

Window.webkitMediaStream

Window.webkitNotifications

Window.webkitOfflineAudioContext

Window.webkitRTCPeerConnection

Window.webkitRequestAnimationFrame

Window.webkitRequestFileSystem

Window.webkitResolveLocalFileSystemURL

Window.webkitSpeechGrammar

Window.webkitSpeechGrammarList

Window.webkitSpeechRecognition

Window.webkitSpeechRecognitionError

Window.webkitSpeechRecognitionEvent

Window.webkitStorageInfo

Window.webkitURL

WorkerContext.webkitIDBCursor

WorkerContext.webkitIDBDatabase

WorkerContext.webkitIDBFactory

WorkerContext.webkitIDBIndex

WorkerContext.webkitIDBKeyRange

WorkerContext.webkitIDBObjectStore

WorkerContext.webkitIDBRequest

WorkerContext.webkitIDBTransaction

WorkerContext.webkitIndexedDB

WorkerContext.webkitNotifications

WorkerContext.webkitRequestFileSystem

WorkerContext.webkitRequestFileSystemSync

WorkerContext.webkitResolveLocalFileSystemSyncURL

WorkerContext.webkitResolveLocalFileSystemURL

WorkerContext.webkitURL

WorkerNavigator.webkitPersistentStorage

WorkerNavigator.webkitTemporaryStorage

[Tommy Widenflycht (ᛏᚮᛘᛘᚤ)]

Do you mean that webkit-prefixed APIs that today is available without a flag but after removal of the prefix must have a flag?

While I really like the idea to get rid of the webkit prefix it feels a bit tough to add a flag again just because the names change; the feature itself doesn't change. But likely I have misunderstood something.

[Adam Barth]

On Mon, May 6, 2013 at 11:53 AM, Tommy Widenflycht (ᛏᚮᛘᛘᚤ) <tom...@google.com> wrote:

Do you mean that webkit-prefixed APIs that today is available without a flag but after removal of the prefix must have a flag?

That seems like a bit of overkill.  It probably makes sense to email this email list to confirm the intent to ship the API unprefixed.

 

While I really like the idea to get rid of the webkit prefix it feels a bit tough to add a flag again just because the names change; the feature itself doesn't change. But likely I have misunderstood something.

Yeah, we want to make the transition to unprefixed as smooth as possible.  :)

Adam

[Tommy Widenflycht (ᛏᚮᛘᛘᚤ)]

OK, thanks for the clarification. I still have some questions/concerns but since they are very specific to WebRTC I'll start a new thread.

[Eric Seidel]

An already shipping "webkit" prefixed name is shipping, but (according
to at least the CSS WG) is discouraged from use. We didn't "commit"
to that API.

In reality we've committed to all APIs we've shipped, so we may have
to keep webkit-prefixed APIs around if there are users for them.

When we ship an previously prefixed API in its unprefixed form we are
truly committing to keeping that API around the platform for an
indefinite period of time. So it needs to be ready to pass the
"Intent to Ship" process. If it's not ready yet we have runtime flags
for guarding it until then. Then forward-looking Web Developers can
access it when they enable --experimental-webkit-features, but they
also can't depend on their users having it available.

I'm in the middle of a series of patches to make the runtime flags
system brain-dead simple (historically you've had to edit a lot of
files, soon it will only be one). I'll post later this week when I'm
finished.