Publish CSS bits as @webref/css

[foolip]

As a follow-up to #63 we should also have a @webref/css package.

@saschanaz needs it for saschanaz/types-web#66, and I'm also still using webref directly in https://github.com/foolip/mdn-bcd-collector because I get CSS properties from it.

What should be in such a package? Is it simply the JSON files in ed/css/?

[saschanaz]

Autogenerating IDL per CSSOM could be a good additional touch.

[foolip]

Do you think that should go in this package, or in @webref/idl?

[saschanaz]

Hmm, maybe it should go to the IDL package.

[tidoust]

For linking purpose, autogeneration of IDL per CSSOM is tracked in #51.

[saschanaz]

I wonder whether directly synthesizing AST for IDL would make more sense than generating IDL text and then parse it, since in that case I think it fits better in /css as /idl is about IDL text.

[tidoust]

The direction we've chosen so far is more to export raw material and provide some parsing guarantees. That's not perfect. We still need to use a JSON structure for CSS extracts because that is the raw-est option, and the guarantees somewhat impose to use a JS runtime, whereas data could be useful in other runtimes. I would still prefer to stick to that for the time being.

If I understand CSSOM correctly, each property essentially generates one, two, or three attributes on the CSSStyleDeclaration interface. I'm wondering whether the following solution could fit all needs:

1. In CSS extracts included in the CSS package, add a styleDeclaration key to property definitions that contains an array with the IDL attribute names that the property generates. For instance, leaving aside other keys:

    {
      "properties": {
        "align-content": {
          "styleDeclaration": ["align-content", "alignContent"]
        }
      }
    }

2. Create an additional ed/idl/cssom-generated.idl file that gets included in the IDL package, and that contains a large partial interface CSSStyleDeclaration block with all the CSS properties. Or are there scenarios where it would be useful to have the CSSOM generated IDL per spec?

The information in the CSS extracts would tell where specific attributes in the additional IDL file come from. It would also allow one to easily generate the IDL text (and AST) for a given CSS property if needed.

How about it?

[saschanaz]

Sounds good enough to me 👍

Or are there scenarios where it would be useful to have the CSSOM generated IDL per spec?

Not in my mind.

[foolip]

For my purposes, an implementation of https://drafts.csswg.org/cssom/#css-property-to-idl-attribute would suffice. That's what I use in https://github.com/foolip/mdn-bcd-collector/blob/3fe6959d582d7daac229969fd72586352db2ea1f/build.js#L592-L610 and given that it's easy to generate the IDL as text, or just generate tests which is what I do.

[foolip]

Or are there scenarios where it would be useful to have the CSSOM generated IDL per spec?

Not in my mind.

I also don't think having all the generated IDL as a single block would be useful.

[saschanaz]

I also don't think having all the generated IDL as a single block would be useful.

You mean you want multiple blocks? 👀

[foolip]

I misread what I responded to. I don't have a need for the IDL-as-text at all, but having it all as a single block seems less useful than having a block per spec.

The main reason I don't need the IDL-as-text is that mdn-bcd-collector also adds lots of non-standard CSS properties, and I want to generate the same kinds of tests for those. Thus I need to start with property names and generate IDL or tests from those.

[saschanaz]

Sounds reasonable. I'm okay with properties only as I already have machineries to generate IDL.