Re: Conventions for composed words in enum

>
> On Tue, Oct 22, 2013 at 8:29 AM, Harald Alvestrand <harald@alvestrand.no <harald@alvestrand.no?Subject=Re%3A%20Conventions%20for%20composed%20words%20in%20enum&In-Reply-To=%3CCADnb78gKPEpzkUcp4rj-Nxhitr%3DefjEFHkik7%2BuxdANHhGEUcA%40mail.gmail.com%3E&References=%3CCADnb78gKPEpzkUcp4rj-Nxhitr%3DefjEFHkik7%2BuxdANHhGEUcA%40mail.gmail.com%3E>> wrote:
> > On 10/21/2013 02:57 PM, Anne van Kesteren wrote:
> >> Yeah, lowercase, no separators.
> >>
> > not to be a pain, but why is the answer here "lowercase" and not "camelCase"
> > or "CamelCase"?
> >
> > trying to understand why this case (identifiers represented as strings) is
> > different from other identifiers.
>
> Just ended up being the convention we use. This is also the convention
> we use for HTML element and attribute names, for what it's worth. It's
> not completely unique.
>
> Is "lowercasewords" still the preferred style? Would it be possible to add
naming guidelines to http://heycam.github.io/webidl/#idl-enums? Absent any
other guidance, the current note implies use of dashes.
http://www.w3.org/TR/api-design/#enums says nothing about naming.

FYI, here are a couple counterexamples in active specs:

   - Fetch is using a mix of concatenation and dashes:
   https://fetch.spec.whatwg.org/#requestcontext
   - Screen Orientation is using dashes:
   https://w3c.github.io/screen-orientation/#orientationtype-enum