A proposal for un-prefixing

Showing 1-19 of 19 messages
A proposal for un-prefixing Eric Seidel 4/16/13 1:55 AM
[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.).
Re: [blink-dev] A proposal for un-prefixing Alex Komoroske 4/16/13 8:06 AM
+1 to everything you said.
Re: [blink-dev] A proposal for un-prefixing Dimitri 4/16/13 9:21 AM
I love it.

:DG<
Re: A proposal for un-prefixing mvuj...@adobe.com 4/16/13 9:29 AM
+1. Great policy!
Re: [blink-dev] Re: A proposal for un-prefixing Michelangelo De Simone 4/16/13 9:57 AM
+1. Seems perfect.
--
Bye,
Michelangelo
Re: A proposal for un-prefixing divya....@gmail.com 4/16/13 11:09 AM


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. 
Re: [blink-dev] Re: A proposal for un-prefixing Darin Fisher 4/16/13 11:37 AM
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
Re: [blink-dev] Re: A proposal for un-prefixing Darin Fisher 4/16/13 11:40 AM
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.
Re: A proposal for un-prefixing Eric Seidel 4/16/13 11:57 AM
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:
Re: [blink-dev] A proposal for un-prefixing Ojan Vafai 4/16/13 2:51 PM
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.

- 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.).

Re: [blink-dev] A proposal for un-prefixing Eric Seidel 4/17/13 12:12 AM
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.
Re: [blink-dev] A proposal for un-prefixing Rick 5/3/13 10:13 AM
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.

Re: [blink-dev] A proposal for un-prefixing Tommy Widenflycht 5/6/13 5:35 AM
Also webkit prefixed constructors seems to be missing (like webkitRTCPeerConnection and webkitMediaStream).
Should they too be unprefixed asap?
Re: [blink-dev] A proposal for un-prefixing Adam Barth 5/6/13 9:31 AM
Ideally, yes.

Adam

Re: [blink-dev] A proposal for un-prefixing Pete Blois 5/6/13 9:53 AM
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
Re: [blink-dev] A proposal for un-prefixing Tommy Widenflycht 5/6/13 11:53 AM
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.


On Tue, Apr 16, 2013 at 10:55 AM, Eric Seidel <ese...@google.com> wrote:
- Prefixed -> unprefixed conversions of these APIs should still go
through the existing “intent to ship” process (be guarded by feature
flags, etc.).

Re: [blink-dev] A proposal for un-prefixing Adam Barth 5/6/13 12:07 PM
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

 
On Tue, Apr 16, 2013 at 10:55 AM, Eric Seidel <ese...@google.com> wrote:
- Prefixed -> unprefixed conversions of these APIs should still go
through the existing “intent to ship” process (be guarded by feature
flags, etc.).


Re: [blink-dev] A proposal for un-prefixing Tommy Widenflycht 5/6/13 12:23 PM
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.
Re: [blink-dev] A proposal for un-prefixing Eric Seidel 5/6/13 12:28 PM
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.