Re: [w3ctag/design-reviews] EyeDropper API (#587)

> The edge case here is that, whereas "BG" gets de-capitalized to "bg" or "HTML" gets de-capitalized to "html", it's not clear whether "sRGB" should be decapitalized to "srgb".

Hi @domenic 

Right, but the "s" is lowercase by convention, so the first character would always be lower-case, and the intent of being lowercase when the first word of a method or property is to be consistent with the previous rule of camelCase for methods and properties, as the first character in camelCase is always lowercase as opposed to PascalCase.

The edge then as I see it is if ` sRGB ` is used as the first term in a class or mixin which is PascalCase, so then would the lowercase s be forced to uppercase like ` SRGBobject ` or  ` SRGBObject ` ...?

The other edge case then is when sRGB is not the first term — then should the "s" be uppercased? Such as  ` ClassSRGB ` or  still be  `ClasssRGB ` or maybe then invert as ` ClassSrgb `


### Special Convention?

Since the underlying intent of case conventions is to improve readability of the code, perhaps there is room for a convention for terms where the case is already set/standardized, as it is with sRGB (other examples are NaN, Lab, Luv ...) 

The convention would be to use an underscore when the case of the term should not be changed, but the other tenets of the given convention indicates that the case needs to be changed. Examples:

### camelCase
` sRGB_Color  ` or ` _LabColor ` or ` _Luv_sRGB_Color ` 

### PascalCase
` _sRGB_Color  ` or ` LabColor ` or ` Luv_sRGB_Color ` 

Or would that be too confused with JSON keys ... 

### Unrelated side note
Should the table in https://w3ctag.github.io/design-principles/#casing-rules also include a row for GLOBAL_VARIABLES, which are frequently all-uppercase underscore delimited?




-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/587#issuecomment-853338068