25418 2014-04-22 22:48:53 +0000 [WebDriver Spec]: Should we be pushing the use of vendor prefixes for extensions? 2016-09-02 21:11:06 +0000 1 1 1 Unclassified Browser Test/Tools WG WebDriver unspecified PC Linux RESOLVED FIXED https://dvcs.w3.org/hg/webdriver/raw-file/default/webdriver-spec.html#extending-the-protocol P2 normal --- 20860 1 fisherii public-browser-tools-testing ato dburns mike paul.irish simon.m.stewart public-browser-tools-testing oldest_to_newest 104225 0 fisherii 2014-04-22 22:48:53 +0000 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. 104255 1 ato 2014-04-23 10:22:08 +0000 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. 104325 2 dburns 2014-04-24 10:05:01 +0000 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. 104327 3 ato 2014-04-24 10:40:26 +0000 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. 104370 4 fisherii 2014-04-24 19:54:42 +0000 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. 127286 5 simon.m.stewart 2016-09-02 21:11:06 +0000 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.