This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25418 - [WebDriver Spec]: Should we be pushing the use of vendor prefixes for extensions?
Summary: [WebDriver Spec]: Should we be pushing the use of vendor prefixes for extensi...
Status: RESOLVED FIXED
Alias: None
Product: Browser Test/Tools WG
Classification: Unclassified
Component: WebDriver (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Browser Testing and Tools WG
QA Contact: Browser Testing and Tools WG
URL: https://dvcs.w3.org/hg/webdriver/raw-...
Whiteboard:
Keywords:
Depends on:
Blocks: 20860
  Show dependency treegraph
 
Reported: 2014-04-22 22:48 UTC by Marc Fisher
Modified: 2016-09-02 21:11 UTC (History)
5 users (show)

See Also:


Attachments

Description Marc Fisher 2014-04-22 22:48:53 UTC
With both Chrome (http://www.chromium.org/blink/developer-faq#TOC-Will-we-see-a--chrome--vendor-prefix-now-) and Firefox (http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0731.html) moving away from vendor prefixes, should we being encouraging the use of these prefixes in the wire protocol?

Also the referenced list of extensions (http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords) seems noticeable sparse.
Comment 1 Andreas Tolfsen 2014-04-23 10:22:08 UTC
I think so.  The WebDriver use case is somewhat different from the use case of web platform standards in that we need to provide ways through the protocol to do browser specific actions.

Examples of this might include switching context from browser context to chrome context (which is the case of Marionette-Firefox), specific UI widget automation (which used to be the case of Opera), and I'm sure there are many other.
Comment 2 David Burns :automatedtester 2014-04-24 10:05:01 UTC
I have to agree with Andreas that if there are things specific to a UA then we should prefix them.

However if it is to handle something that is in a specification then we should not prefix it (e.g. how to handle web components should not be prefixed).

I am happy to add a note saying the above if people are happy with that.
Comment 3 Andreas Tolfsen 2014-04-24 10:40:26 UTC
I'm not sure a note is needed, but the important point here is that one shouldn't prefix things that can feasibly be done cross-browser.

If a browser vendor decides to add an API in the future for handling, say, interception of HTML5 video, that would be a prime candidate for specification (ideally upfront) and shouldn't be prefixed.
Comment 4 Marc Fisher 2014-04-24 19:54:42 UTC
I agree that we need a mechanism to scope driver/browser specific extensions. My concern is that the suggested browser prefixes aren't a good mechanism for this for the following reasons:

1. Usage of the suggested browser prefixes seems to be declining in general.
2. The extensions are more a property of the driver than of the browser. e.g. I could imagine a Selenium-specific extension that works regardless of which Selenium supported browser is used.
3. Any given browser could have more than one driver implementation. e.g. MS's upcoming implementation of an IE driver vs. the current Selenium IE driver; Marionette vs. Selenium Firefox Driver
4. The list of prefixes don't match current browsers or drivers very well. e.g. -webkit- is used for all WebKit-based browsers plus Chrome which forked from WebKit but is diverging significantly. Does it really make sense to use this one as the mechanism for scoping, likely incompatible, different extensions for Safari (iOS, Desktop), Chrome (Android, Desktop, iOS), Blackberry, Opera (Maybe? Where does it even fit in now that it is using Chromium?), Android Browser, who knows what else.

I think a better proposal would be something like:

/session/:sessionid:/ext/:driver-identifier:/:endpoint:

With a non-normative statement that driver vendors try to ensure that the identifiers be unique.
Comment 5 Simon Stewart 2016-09-02 21:11:06 UTC
Reading http://www.w3.org/TR/webdriver/#protocol-extensions suggests that Marc's suggestion has been followed already. Marking this as resolved, but we can reopen.