[bug] casing rules contrary to Web ecosystem naming conventions

[DerekNonGeneric]

According to the Web Platform Design Principles outlined by members of the W3C TAG, our API is at least in violation of guidelines laid out in the section on naming principles.

Use Web consistent names

When choosing a name for feature or API that has exposure in other technology stacks, the preference should be towards the Web ecosystem naming convention rather than other communities.

	Casing rule	Examples
Methods and properties (Web IDL attributes, operations, and dictionary keys)	Camel case	createAttribute() compatMode
Classes and mixins (Web IDL interfaces)	Pascal case	NamedNodeMap NonElementParentNode
Initialisms in APIs	All caps, except when the first word in a method or property	HTMLCollection innerHTML bgColor
Repeated initialisms in APIs	Follow the same rule	HTMLHRElement RTCDTMFSender
The abbreviation of "identity"	Id, except when the first word in a method or property	getElementById() pointerId id
Enumeration values	Lowercase, dash-delimited	"no-referrer-when-downgrade"
Events	Lowercase, concatenated	canplaythrough languagechange
HTML elements and attributes	Lowercase, concatenated	figcaption maxlength
JSON keys	Lowercase, underscore-delimited	short_name

Refs: https://w3ctag.github.io/design-principles/#casing-rules

---

GhFileImporter

Kind: global class

• GhFileImporter
  • new GhFileImporter(options)
  • .fetchMetadata(owner, repo, path, ref) ⇒ Promise.<any>
  • .fetchFileContents(owner, repo, path, ref) ⇒ Promise.<string>
  • .fetchFileContentsFromUrl(url) ⇒ Promise.<string>
  • .importContents(url) ⇒ Promise.<string>
  • .importContentsFromUrl(url) ⇒ Promise.<string>

new GhFileImporter(options)

Creates an instance of GhFileImporter.

Situation	Casing rule	Status
Classes and mixins (Web IDL interfaces)	Pascal case	ⓧ
Initialisms in APIs	All caps, except when the first word in a method or property	ⓧ

---

The API's class name and other parts will need to be re-written. The class name should likely be GHFileImporter, and the names of the methods ending in *FromUrl would need to be *FromURL are just a couple of things I was able to catch at a quick glance…

This will be a very disruptive breaking change — in this issue, we are offered a brief glimpse at how the new v3 API will be changing to be designed more like a Web Platform API, so that should be an exciting thing to look forward to for the August release happening later this month.