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 9590 - Consider "prefix--" instead of "_prefix-" as a pattern for proprietary extensions
Summary: Consider "prefix--" instead of "_prefix-" as a pattern for proprietary extens...
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: NE
Depends on:
Blocks:
 
Reported: 2010-04-25 09:18 UTC by Maciej Stachowiak
Modified: 2010-10-15 15:36 UTC (History)
14 users (show)

See Also:


Attachments

Description Maciej Stachowiak 2010-04-25 09:18:55 UTC
Consider "prefix--" instead of "_prefix-" as a pattern for proprietary extensions. I've been trying to convince people at Apple to use the naming pattern recommended by the standard for vendor extensions, and the sheer ugliness of "_webkit-" makes it an impossible sell. "webkit-" is more palatable, and in practice will never conflict with a future standard feature, but presumably we want something that can work for an arbitrary vendor and will never conflict with a future standard. So a perhaps less ugly possibility is "prefix--" (note double hyphen).
Comment 1 Ian 'Hixie' Hickson 2010-08-16 22:13:26 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: Concurred with reporter's comments.
Comment 2 contributor 2010-08-16 22:14:28 UTC
Checked in as WHATWG revision r5307.
Check-in comment: use vendor--feature instead of _vendor-feature since Apple engineers think underscores are ugly.
http://html5.org/tools/web-apps-tracker?from=5306&to=5307
Comment 3 Ian 'Hixie' Hickson 2010-08-17 04:08:02 UTC
dbaron brought up an interesting problem with this:
   http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027973.html
...so it might change again.
Comment 4 Simon Pieters 2010-09-08 08:13:34 UTC
Another problem: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-August/028270.html
Comment 5 Leif Halvard Silli 2010-09-25 21:58:45 UTC
(1)  That _vendor  to some developer is ugly, should be considered an  irrelevant issue

(2)  vendor--feature, in contrast to _vendor-feature, can also be used in element names: <vendor--element></vendor--element>.  Whether that is an advantage or an disadvantage depends on the angle one looks at it from ...  But regardless what HTML5 says, one _must assume_ that, sooner or later, vendors *will* make use of this syntax in elements as well as in attributes.

(3) As justifcation for my conclusion in (2), take a look at vendor prefixes in CSS: 

      In CSS, then -vendor-feature is *typically* used for properties - and this has no effect on other browsers's ability to read the non-vendor properties. *However*, -vendor-feature is *also* used in selectors, even in pseudeo-selectors and pseudo-elements (Mozilla has some of those and Webkti also has them in meda quieries). And when used in pseudo elements/selectors, then user agents from other vendors are required, per the CSS rules, to ignore the the entire selector - which is a feature that can be, and is used, used to target particular user agents.

     Thus, even if _vendor-feature is chosen for HTML5, vendors could still enable support for such elements, while other vendors would then be required to ignore such elements (per HTML5's parsing rules).

(4) Both <_vendor-element> and <vendor--element> works in the XML serialization.

(5) That  _vendor--feature creates problems w.r.t. <!-- <i ven--dor > -->, could be considered a feature as well - if one wants to discourage use of this option.
Comment 6 Ian 'Hixie' Hickson 2010-09-28 19:41:04 UTC
Maciej, are there any other syntaxes Apple would be willing to use? Maybe using a dot?

   vendor.attribute=""
   _vendor-attribute=""
   vendor_attribute=""

Anyone got any other ideas? It has to be well-formed in XML, not clash with comment syntax, not clash with data-* and other features, and be something UAs are willing to use (otherwise what's the point).

Mozilla currently uses the _vendor-attr syntax.
Comment 7 Simon Pieters 2010-09-28 20:10:13 UTC
It was pointed out on IRC that the vendor.foo syntax needs escaping in Selectors.
Comment 8 Edward O'Connor 2010-09-28 20:12:25 UTC
> Anyone got any other ideas? It has to be well-formed in XML, not clash with
> comment syntax, not clash with data-* and other features, and be something UAs
> are willing to use (otherwise what's the point).

How about x-vendor-attribute=""?

* It's well-formed XML.
* It doesn't clash with comment syntax, data-*, or other features.

I can't speak to browser vendors' willingness to use it, but there's at least one precedent: WebOS's x-mojo-* attributes.
Comment 9 Ian 'Hixie' Hickson 2010-09-28 23:56:40 UTC
mjs, dbaron: Would x-vendor-attr="" be acceptable?
Comment 10 L. David Baron (Mozilla) 2010-09-29 01:32:49 UTC
x-vendor-attr sounds fine to me
Comment 11 Jonas Sicking (Not reading bugmail) 2010-09-29 05:29:07 UTC
I'm not a huge fan of the x-vendor-function syntax, but if that's what everyone else prefers then I can live with it. However a few other alternatives to consider are:

vendor_function_vendor_function
vendor__function
vendor-function-

I think out of these I like the first one the most, though I guess the concern is that other specs might use that syntax and eventually we might want to bring those specs into HTML, a'la SVG?
Comment 12 Jonas Sicking (Not reading bugmail) 2010-09-29 05:30:40 UTC
Err.. don't know why my comment got munged. Here was the list I was going for:

vendor_function_   
vendor_function   
vendor__function  
vendor-function-
Comment 13 Jonas Sicking (Not reading bugmail) 2010-09-29 05:31:44 UTC
Arg, sorry, that wasn't it, the intended list was:


vendor_function   
_vendor_function  
vendor__function  
vendor-function-
Comment 14 Maciej Stachowiak 2010-09-29 05:47:59 UTC
(In reply to comment #9)
> mjs, dbaron: Would x-vendor-attr="" be acceptable?


x-vendor-attr="" seems like the best suggestion to my tastes, out of those so far. I will briefly survey the folks who code on WebKit at Apple.
Comment 15 Henri Sivonen 2010-09-29 08:48:54 UTC
_vendor-attribute="" and x-vendor-attribute="" WFM.
Comment 16 Ian 'Hixie' Hickson 2010-09-29 19:45:22 UTC
Should I just reserve anything starting with "x-" and anything containing an underscore, and recommend using either "x-vendor-feature" or "_vendor-feature"? Or would it be better to strongly recommend a specific syntax? (If the latter, I'll go with x-vendor-feature since it has the highest chance of being used.)
Comment 17 Anne 2010-09-29 19:50:50 UTC
I think we should reserve everything apart from x-vendor-feature.
Comment 18 Jonas Sicking (Not reading bugmail) 2010-09-29 21:54:24 UTC
I would not pay attention to the mozilla _moz-foo syntax. I'm fairly certain that it's only used internally and that we never use it to enable features that authors might want. I.e. there is no reason for it to ever appear in markup that people put through a validator. In the long term our current uses will hopefully go away and instead use internal state flags rather than ones exposed in the DOM.
Comment 19 Ian 'Hixie' Hickson 2010-09-29 22:37:48 UTC
I've reserved "x-*" and anything containing "_", but only recommended the use of "x-*".

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: see diff below
Rationale: see the WHATWG posts cited above for why the original suggestion of "--" has been rejected.
Comment 20 contributor 2010-09-29 22:38:27 UTC
Checked in as WHATWG revision r5562.
Check-in comment: Change how vendor extensions are marked up.
http://html5.org/tools/web-apps-tracker?from=5561&to=5562