Check case-sensitivity

[asamuzaK]

Fixes #303

• Renamed generatePropertyDefinitions.mjs to generateDefinitions.mjs.
• Generates syntax definitions from @webref/css and saves them in lib/generated/syntaxDefinitions.js.
• Added a new function to lib/parsers.js that checks whether syntax is case-sensitive.
• Added a helper function to lib/parsers.js to integrate cache checking and setting.
• Added a caseSensitive option to lib/utils/propertyDescriptors.js.

Regression test

jsdom/jsdom#4032

Benchmark results

jsdom/jsdom#4031

jsdom main + cssstyle@5.3.7:

> jsdom@27.4.0 benchmark
> node ./benchmark/runner --suites style

# style/createElement + setAttribute('style') #
jsdom  x 89.05 ops/sec ±2.99% (65 runs sampled)

# style/createElement + style properties #
jsdom  x 134 ops/sec ±3.09% (75 runs sampled)

# style/createElement + style.cssText #
jsdom  x 93.93 ops/sec ±2.33% (68 runs sampled)

# style/innerHTML: divs with inline styles #
jsdom  x 84.97 ops/sec ±2.80% (70 runs sampled)

# style/innerHTML: simple divs (no styles) #
jsdom  x 2,790 ops/sec ±2.58% (85 runs sampled)

jsdom main + linked cssstyle patch without cache:

> jsdom@27.4.0 benchmark
> node ./benchmark/runner --suites style

# style/createElement + setAttribute('style') #
jsdom  x 101 ops/sec ±2.64% (71 runs sampled)

# style/createElement + style properties #
jsdom  x 112 ops/sec ±2.52% (70 runs sampled)

# style/createElement + style.cssText #
jsdom  x 107 ops/sec ±2.18% (66 runs sampled)

# style/innerHTML: divs with inline styles #
jsdom  x 94.27 ops/sec ±2.82% (68 runs sampled)

# style/innerHTML: simple divs (no styles) #
jsdom  x 3,441 ops/sec ±2.47% (80 runs sampled)

jsdom main + linked cssstyle patch with cache:

> jsdom@27.4.0 benchmark
> node ./benchmark/runner --suites style

# style/createElement + setAttribute('style') #
jsdom  x 130 ops/sec ±2.90% (72 runs sampled)

# style/createElement + style properties #
jsdom  x 134 ops/sec ±2.23% (74 runs sampled)

# style/createElement + style.cssText #
jsdom  x 137 ops/sec ±2.30% (76 runs sampled)

# style/innerHTML: divs with inline styles #
jsdom  x 129 ops/sec ±2.77% (72 runs sampled)

# style/innerHTML: simple divs (no styles) #
jsdom  x 3,498 ops/sec ±2.71% (80 runs sampled)

[domenic]

It seems like this approach involves, at runtime, looking up whether the property is case sensitive. This requires loading a lot of data into the distributed package and into memory, a caching layer to speed it up, a large package bundle size, etc.

But that information is available at npm run prepare time instead.

Could we instead split createGenericPropertyDescriptor() into two functions, createGenericCaseSensitivePropertyDescriptor() and createGenericCaseInsensitivePropertyDescriptor(), and inside generatePropertyDescriptors.mjs pick the correct one?

Edit: actually, it could still be one function createGenericPropertyDescriptor(property, { caseSensitive }).

[asamuzaK]

If we want to process it at prepare time, it would be better to add caseSensitive key and value ​​to the properties in propertyDefinitions Map?

[domenic]

I'm not sure which is best and OK to leave the choice to you. My understanding is that current architecture is split into two steps:

1. Generate propertyDefinitions.js from @webref/css. Some fields of propertyDefinitions.js will be used at runtime, and some in the next prepare-time step.
2. Generate propertyDescriptors.js from propertyDefinitions.js.

We could extend this to add a bit more information in step 1 to propertyDefinitions.js, so that step 2 can be written simply. I think that is your proposal.

I guess the most efficient architecture would be something like:

1. Generate propertyDefinitions.js from @webref/css. Only fields that are used at runtime are included.
2. Generate propertyDescriptors.js from @webref/css.

Then we could run 1) and 2) in parallel at prepare-time, and the package size + runtime memory overhead would be minimal.

But I do not fully understand which fields (name, href, legacyAliasOf, styleDeclaration, extended, syntax) we plan to use at runtime, so I don't know how different the most efficient architecture vs. the current architecture is. It does not feel urgent to switch.

(There is also compromise architecture, which could start with current architecture but then have a step 3 which deletes fields from propertyDescriptors.js that are not used at runtime. This would give the same runtime efficiency as the most efficient architecture, but the prepare-time code would be more messy.)

[asamuzaK]

Submitted another PR.