Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Wed, 1 Dec 2010, Anne van Kesteren wrote: On Wed, 01 Dec 2010 00:27:23 +0100, Ian Hickson i...@hixie.ch wrote: An update since this topic was discussed on this list before: I updated the vendor-specific syntax a while back to be x-vendor-foo= for content attributes, and .vendorFoo for IDL members; attributes starting with an underscore are also reserved but their use is not encouraged. If we do .vendorFoo shouldn't we just do vendor-foo=? opera, moz, webkit, ms are unique enough and HTML attributes generally do not use hyphens anyway. (And yes, there will be some more vendors, etc. But over the years there have not been many extensions at all so this is all rather manageable.) I think we want a prefix, in general. The problem is that it is not aesthetically pleasing to have a prefix for IDL attributes, unlike content attributes where it doesn't look anywhere near as bad. Hence where we are now, which seems fine. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
An update since this topic was discussed on this list before: I updated the vendor-specific syntax a while back to be x-vendor-foo= for content attributes, and .vendorFoo for IDL members; attributes starting with an underscore are also reserved but their use is not encouraged. On Tue, 17 Aug 2010, Tab Atkins Jr. wrote: On Mon, Aug 16, 2010 at 10:27 PM, Anne van Kesteren ann...@opera.com wrote: In fact, iirc we follow the policy that new attribute names will not have hyphens in them, unless it is for some kind of pattern (like data-). Is this supposed to be a general policy? We couldn't determine whether to go with or without dashes when naming an attribute in the bidi meeting a few months ago - current practice seems to go both ways, from a trawl of the attribute index. I don't know that we follow any concrete policy. HTML uses pretty much every naming convention you can come up with _somewhere_. When adding new features generally I just try to find an existing feature with a similar concept and then use the same naming scheme. So e.g. looking at recent additions, bdo suggests bdi, dir= and name= suggest dirname=. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Wed, 01 Dec 2010 00:27:23 +0100, Ian Hickson i...@hixie.ch wrote: An update since this topic was discussed on this list before: I updated the vendor-specific syntax a while back to be x-vendor-foo= for content attributes, and .vendorFoo for IDL members; attributes starting with an underscore are also reserved but their use is not encouraged. If we do .vendorFoo shouldn't we just do vendor-foo=? opera, moz, webkit, ms are unique enough and HTML attributes generally do not use hyphens anyway. (And yes, there will be some more vendors, etc. But over the years there have not been many extensions at all so this is all rather manageable.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Mon, 30 Aug 2010 19:06:43 +0200, Aryeh Gregor simetrical+...@gmail.com wrote: On Mon, Aug 30, 2010 at 4:19 AM, Simon Pieters sim...@opera.com wrote: This change clashes with data-*. How? Are you missing the fact that *two* consecutive hyphens are needed? If a vendor is called data, then data--feature becomes a data-* attribute and is included in .dataset. -- Simon Pieters Opera Software
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Tue, Aug 31, 2010 at 12:48 AM, Simon Pieters sim...@opera.com wrote: On Mon, 30 Aug 2010 19:06:43 +0200, Aryeh Gregor simetrical+...@gmail.com wrote: On Mon, Aug 30, 2010 at 4:19 AM, Simon Pieters sim...@opera.com wrote: This change clashes with data-*. How? Are you missing the fact that *two* consecutive hyphens are needed? If a vendor is called data, then data--feature becomes a data-* attribute and is included in .dataset. Right. So a vendor shouldn't choose data as their prefix. ~TJ
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Tue, 31 Aug 2010 16:02:02 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: Right. So a vendor shouldn't choose data as their prefix. I could imagine we get ariaset in the future and maybe others. But it is unlikely to be a big problem since there are so many prefixes to chose from. And experimental attributes should really be avoided and only be around for limited amount of time... -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Tue, Aug 31, 2010 at 3:48 AM, Simon Pieters sim...@opera.com wrote: If a vendor is called data, then data--feature becomes a data-* attribute and is included in .dataset. I missed the fact that data--foo is actually a valid data attribute. I guess I assumed that the name part couldn't start with a hyphen. data--foo would be accessed via JS as .dataset.Foo rather than .dataset.foo because of a degenerate application of the camel-casing rules, but it's allowed. Anyway, I preferred the initial-underscore convention -- it's easier to spot, and would be more understandable to people who know CSS.
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Tue, 17 Aug 2010 00:14:17 +0200, wha...@whatwg.org wrote: Author: ianh Date: 2010-08-16 15:14:15 -0700 (Mon, 16 Aug 2010) New Revision: 5307 Modified: complete.html index source Log: [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers think underscores are ugly. Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=9590 Modified: source === --- source 2010-08-16 22:11:13 UTC (rev 5306) +++ source 2010-08-16 22:14:15 UTC (rev 5307) @@ -2347,15 +2347,16 @@ pFor markup-level features that are intended for use with spanthe HTML syntax/span, extensions should be limited to new - attributes of the form code title=_var - title=vendor/var-var title=feature/var/code, where + attributes of the form code title=var + title=vendor/var--var title=feature/var/code, where var title=vendor/var is a short string that identifies the vendor responsible for the extension, and var - title=feature/var is the name of the feature. New element names - should not be created. Using attributes for such extensions - exclusively allows extensions from multiple vendors to co-exist on - the same element, which would not be possible with elements. Using - the code title=_var title=vendor/var-var + title=feature/var is the name of the feature. (Note the use of + emtwo/em hyphens in the name.) New element names should not be + created. Using attributes for such extensions exclusively allows + extensions from multiple vendors to co-exist on the same element, + which would not be possible with elements. Using the code + title=var title=vendor/var--var title=feature/var/code form allows extensions to be made without risk of conflicting with future additions to the specification./p @@ -2369,14 +2370,14 @@ these features could write:/p prelt;pThis smells of lemons! -lt;span _ferret-smellovision _ferret-smellcode=LEM01 - _mb-outputsmell _mb-smell=lemon juicelt;/spanlt;/p/pre +lt;span ferret--smellovision ferret--smellcode=LEM01 + mb--outputsmell mb--smell=lemon juicelt;/spanlt;/p/pre /div - pAttribute names starting with a U+005F LOW LINE character (_) are - reserved for user agent use and are guaranteed to never be formally - added to the HTML language./p + pAttribute names containing two consecutive U+002D HYPHEN-MINUS + (-) characters are reserved for user agent use and are guaranteed to + never be formally added to the HTML language./p p class=notePages that use such attributes are by definition non-conforming./p This change clashes with data-*. -- Simon Pieters Opera Software
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Mon, Aug 30, 2010 at 4:19 AM, Simon Pieters sim...@opera.com wrote: This change clashes with data-*. How? Are you missing the fact that *two* consecutive hyphens are needed?
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Mon, Aug 16, 2010 at 10:27 PM, Anne van Kesteren ann...@opera.com wrote: On Tue, 17 Aug 2010 06:32:33 +0200, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Aug 17, 2010 at 4:05 PM, Ian Hickson i...@hixie.ch wrote: Hmm, good point. Any other suggestions? Mozilla has already added a number of extensions using just a moz prefix ... e.g. mozInnerScreenX, mozPaintCount, mozRequestAnimationFrame. Webkit has added extensions using a webkit prefx ... e.g. webkitDisplayingFullscreen. In theory I guess that pattern could conflict with new features. But in practice it doesn't seem likely unless new engines enter the market and choose prefixes poorly. (I.e., don't choose a prefix that matches an English verb or noun.) Note that this is for element attributes, not interface members. Having said that, vendor-name (i.e. a single dash) is probably sufficient. It seems highly unlikely we will ever use webkit-, ms-, o-, gecko- as an attribute name. In fact, iirc we follow the policy that new attribute names will not have hyphens in them, unless it is for some kind of pattern (like data-). Is this supposed to be a general policy? We couldn't determine whether to go with or without dashes when naming an attribute in the bidi meeting a few months ago - current practice seems to go both ways, from a trawl of the attribute index. ~TJ
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Tue, 17 Aug 2010 20:40:20 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: Is this supposed to be a general policy? We couldn't determine whether to go with or without dashes when naming an attribute in the bidi meeting a few months ago - current practice seems to go both ways, from a trawl of the attribute index. Yeah, see e.g. the various form* attributes, autofocus, item* attributes. The only new attribute I can think of with a dash is data- and that's a special case. Elements have no dashes at all. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Monday 2010-08-16 15:14 -0700, wha...@whatwg.org wrote: [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers think underscores are ugly. Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=9590 This has the disadvantage that vendor-specific features can't be commented out in a conformant way since '--' is not permitted within comments, per http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#comments I'd also note that Gecko has quite a few _moz- attributes, although they're for internal things rather than things that we intend to expose to authors. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Mon, 16 Aug 2010, L. David Baron wrote: On Monday 2010-08-16 15:14 -0700, wha...@whatwg.org wrote: [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers think underscores are ugly. Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=9590 This has the disadvantage that vendor-specific features can't be commented out in a conformant way since '--' is not permitted within comments, per http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#comments Hmm, good point. Any other suggestions? I'd also note that Gecko has quite a few _moz- attributes, although they're for internal things rather than things that we intend to expose to authors. Yeah, that's what the original suggestion came from. It was changed because of: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9590 I don't really mind what we use, so long as people are willing to use it and we can guarantee that it won't conflict with future attributes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Tue, Aug 17, 2010 at 4:05 PM, Ian Hickson i...@hixie.ch wrote: Hmm, good point. Any other suggestions? Mozilla has already added a number of extensions using just a moz prefix ... e.g. mozInnerScreenX, mozPaintCount, mozRequestAnimationFrame. Webkit has added extensions using a webkit prefx ... e.g. webkitDisplayingFullscreen. In theory I guess that pattern could conflict with new features. But in practice it doesn't seem likely unless new engines enter the market and choose prefixes poorly. (I.e., don't choose a prefix that matches an English verb or noun.) Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Tue, 17 Aug 2010 06:32:33 +0200, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Aug 17, 2010 at 4:05 PM, Ian Hickson i...@hixie.ch wrote: Hmm, good point. Any other suggestions? Mozilla has already added a number of extensions using just a moz prefix ... e.g. mozInnerScreenX, mozPaintCount, mozRequestAnimationFrame. Webkit has added extensions using a webkit prefx ... e.g. webkitDisplayingFullscreen. In theory I guess that pattern could conflict with new features. But in practice it doesn't seem likely unless new engines enter the market and choose prefixes poorly. (I.e., don't choose a prefix that matches an English verb or noun.) Note that this is for element attributes, not interface members. Having said that, vendor-name (i.e. a single dash) is probably sufficient. It seems highly unlikely we will ever use webkit-, ms-, o-, gecko- as an attribute name. In fact, iirc we follow the policy that new attribute names will not have hyphens in them, unless it is for some kind of pattern (like data-). -- Anne van Kesteren http://annevankesteren.nl/
