Update HTML style guide with rule for camel casing attribute values.

[cjcenizal]

Per #11602 (comment):

We're using camel case pretty much everywhere (e.g. test subject selectors, even CSS class names), so I think it makes sense to be consistent by applying camel case to IDs too.

[jbudz]

@cjcenizal mind if we get some more eyes on this or link to a previous discussion? The text LGTM but I'm against camel casing ids, and I can't find previous discussions. Most html ids I've seen use hyphens and I'm not sure why we'd change it.

[Bargs]

It seems that any naming scheme relying on case sensitivity can lead to subtle bugs because html and css follow different case sensitivity rules. Different browsers also sometimes have different rules.

Quoting from the linked article:

The simplest way to mitigate any potential issues surrounding case sensitivity is to always use lowercase for everything in your markup and CSS, where possible. If that’s not possible, make sure the case you use is consistent between your CSS and your document markup.

[kobelb]

I'm not necessarily advocating for this, but historically I've found myself using hypens for CSS classes and camelCasing for ids within HTML, but I think it's just a convention I integrated from working with Bootstrap.

[cjcenizal]

Per Slack convo w/ @archanid, we could expand this exception to use hyphens as a grouping mechanism among similar elements, e.g.

<section id="welcomePage-introSection">
  <!-- Content -->
</section>

<section id="welcomePage-aboutSection">
  <!-- Content -->
</section>

Ater thinking about this a bit I'm not sure how useful this would be, and I'd prefer to keep our naming as simple as possible. This still seems readable and understandable to me:

<section id="welcomePageIntroSection">
  <!-- Content -->
</section>

<section id="welcomePageAboutSection">
  <!-- Content -->
</section>

[rhoboat]

Hm, I agree with you @cjcenizal. Simpler is easier to do and clearer to read.

[spalger]

LGTM

[cjcenizal]

@Bargs I looked into it and here is what I've found:

1. The majority of our CSS uses elements or classes to define selectors.
2. Of those which use attributes, the majority use just the attribute name (not the value), all of which use lower-case (and the attribute names are insensitive anyway).
3. Of those which use attribute names and values, the attributes used are either type or class. The acceptable values for type are defined by the HTML spec, and the values for class are case sensitive.
4. We have 31 instances of selectors using IDs, with a mix of camel-case and kebab-case. Styling IDs is a bad practice, so we should assume that we'll remove these selectors at some point, and avoid adding new ones in the future.

Given all of these, the only situations where I can see the casing being a problem in our CSS is when we use a [class=${something}] attribute as part of a selector. This seems to be a very rare edge case, since normally you'd just write .something instead. Based on this, I think that casing problems will be very rare events during development.

[Bargs]

@cjcenizal Sounds reasonable, thanks for doing the additional research. Just to cover our bases, how would you feel about adding a note that casing in html and css should always match, even if one happens to be case insensitive?

[cjcenizal]

@Bargs Updated, would you mind taking another look?

[Bargs]

LGTM!