Is ES officially a PascalCase and camelCase langauge?

Andrea Giammarchi andrea.giammarchi at
Tue Jun 28 10:41:43 UTC 2016

I think background-color, as it is in CSS, works well with JSON, and
backgroundColor, as it is already in JS works well as counterpart.

Whoever introduced background_color there really should rethink such

This is exactly the kind of shenanigans I'd like to see disappearing once
we have a clear "it's either quoted 'background-color' or backgroundColor
for properties and never 'background_color'".

How difficult could this be?


On Tue, Jun 28, 2016 at 9:58 AM, kdex <kdex at> wrote:

> I'd appreciate that, too, but I think the scope should be much bigger than
> just ES (which is hard to enforce).
> Right now, we even see some deviations in certain Web APIs that are
> designed to interoperate with ES to some degree.
> See for example [1] or [2].
> One of the most opposing trends (and thus maybe weirdest cases) would be
> the property names in web app manifests
> using something akin to C-style variable naming [3], i. e. underscores,
> all-lowercase, often using ambiguous abbreviations
> like `dir` for `direction` but being A-OK with spelling out
> `background_color` instead of `bg_col`.
> I'm not saying that it's futile to incorporate the unwritten style rules
> into the spec, but it wouldn't "fix" misnamed Web APIs
> that would still appear somewhere in our code (and might make linters go
> nuts?).
> [1]
> [2]
> [3]
> On Dienstag, 28. Juni 2016 08:14:14 CEST Andrea Giammarchi wrote:
> > I know the "what majority does" answer, yet I wonder if to avoid API
> > fragmentation we should stick in the specification the fact that
> ECMAScript
> > is a `camelCase` oriented programming language.
> >
> > This will put an end to those coming from C, Python, Ruby, or PHP using
> > `property_name` for their new API and developers will finally have a
> > minimal guide on language naming convention.
> >
> > It is backward compatible, since IIRC there are no exception to this
> > unwritten rule in older specs or APIs, and it will hopefully grant future
> > consistency.
> >
> > It shouldn't be different from what WebIDL has already, if anything,
> since
> > also WebIDL follows same convention.
> >
> > Thoughts?
> >
> > Best Regards
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list