CSS package: consider additional parsing guarantees

[tidoust]

See discussion in #115 (comment)

[tidoust]

Some notes as I'm looking into adding a check for unicity for CSS property definitions.

There are a number of properties that are defined more than once in practice. In most cases, this is "by design" and needs to be accounted for in the code:

• Many CSS 2.x properties are redefined in dedicated CSS modules. Definitions in modules take precedence.
• Delta specs are often not pure delta specs and may redefine a property.
• css-align > css-flexbox, see Module interactions

There remain properties defined in more than one spec, and for which I don't always know which one is the "right" one:

• fill-opacity defined in fill-stroke-3, SVG2
• fill-rule defined in fill-stroke-3, SVG2
• fill defined in fill-stroke-3, SVG2
• image-rendering defined in css-images-3, SVG2
• inline-size defined in css-logical-1, SVG2
• inset-block-end defined in css-logical-1, css-position-3
• inset-block-start defined in css-logical-1, css-position-3
• inset-block defined in css-logical-1, css-position-3
• inset-inline-end defined in css-logical-1, css-position-3
• inset-inline-start defined in css-logical-1, css-position-3
• inset-inline defined in css-logical-1, css-position-3
• inset defined in css-logical-1, css-position-3
• shape-inside defined in css-round-display-1, css-shapes-2, SVG2
• shape-margin defined in css-shapes-1, SVG2
• string-set defined in css-content-3, css-gcpm-3
• stroke-dasharray defined in fill-stroke-3, svg-strokes, SVG2
• stroke-dashoffset defined in fill-stroke-3, svg-strokes, SVG2
• stroke-linecap defined in fill-stroke-3, svg-strokes, SVG2
• stroke-linejoin defined in fill-stroke-3, svg-strokes, SVG2
• stroke-miterlimit defined in fill-stroke-3, svg-strokes, SVG2
• stroke-opacity defined in fill-stroke-3, svg-strokes, SVG2
• stroke-width defined in fill-stroke-3, svg-strokes, SVG2
• stroke defined in fill-stroke-3, svg-strokes, SVG2

I suspect I should ignore problematic definitions in SVG2 But I don't know whether dropping these properties from SVG 2 is tracked somewhere. I suppose I should also prefer fill-stroke over svg-stroke.

Not sure what to do with css-logical / css-positioning duplicates.

shape-inside should rather be defined with a newValues field in css-round-display.

[tidoust]

shape-inside should rather be defined with a newValues field in css-round-display.

Actually, the definition should rather be dropped entirely since the new display value. Filed w3c/csswg-drafts#6433

[cdoublev]

I suppose that properties duplicated in a higher version level of the same specification, eg. background-clip in css-backgrounds and css-backgrounds-4, are filtered out from your above list, because it is obvious that specification-name-level-x > specification-name-level-y? (where x > y) will have to be checked to achieve unicity.

You write that css-position > css-logical in a comment in another issue. Can you confirm it?

I'm not sure that unicity should also be achieved for types. But I find the following duplicates with @webref/css@^2.0.7.

• content() defined in css-content-3 and css-gcpm
• element() defined in css-images-4 and css-gpcm
• dasharray defined in SVG2 and strokes (the SVG2 definition should be preferred according to this resolution)
• fit-content() defined in css-grid-2 and css-sizing-3
• path() defined in css-shapes and motion-1
• position defined in css-backgrounds-4 and css-values-4

[tidoust]

I suppose that properties duplicated in a higher version level of the same specification, eg. background-clip in css-backgrounds and css-backgrounds-4, are filtered out from your above list, because it is obvious that specification-name-level-x > specification-name-level-y? (where x > y) will have to be checked to achieve unicity.

Yes, the css folder in webref only contains extracts for the latest "full" level in the series (plus extracts for "delta" levels when they exist). I generated the above list from that folder.

You write that css-position > css-logical in a comment in another issue. Can you confirm it?

Yes, see w3c/csswg-drafts#6434 (comment)

I'm not sure that unicity should also be achieved for types. But I find the following duplicates with @webref/css@^2.0.7.

Thanks, I had not yet looked at valuespaces :)

Unicity may be less critical there but it seems at least valuable to have only one definition of function-like constructs not to confuse developers. For types such as <position>, it probably matters less: the name is more internal to the spec. Some of the items you report may naturally disappear from the specs once duplicate property definitions get fixed.