Is ES officially a PascalCase and camelCase langauge?
kdex at kdex.de
Tue Jun 28 11:34:08 UTC 2016
As for the Web APIs, this should be (and has been) filed with the corresponding APIs.
Specifically for the Web Manifest spec, you might want to check  and  (there's even a few comments on `background-color`).
(tl;dr: W3C says: "There are now about ~50000 sites using manifests, it's too late to make these kinds of changes" and "We eff'ed up, and gotta live with it.")
Rants aside, since this mailing list is really just scoped to ES, I think it's worth bringing up that many languages handle this differently.
Languages that define a set of coding standards are sparse; there are many where every framework uses its own guidelines (like PHP with Zend, PEAR, …).
Some appear to recommend some non-normative guidelines (like C# ) while others do in fact maintain official documents stating their coding conventions,
like Rust  and Python .
On Dienstag, 28. Juni 2016 11:41:43 CEST Andrea Giammarchi wrote:
> 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 kdex.de> 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  or .
> > 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 , 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?).
> >  https://github.com/w3c/web-nfc/issues/27
> > 
> > https://github.com/w3ctag/design-principles/issues/15#issuecomment-115113438
> >  https://www.w3.org/TR/appmanifest/#example-manifest
> > 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
> > >
More information about the es-discuss