Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Publish CSS bits as @webref/css #111

Closed
foolip opened this issue Feb 25, 2021 · 16 comments
Closed

Publish CSS bits as @webref/css #111

foolip opened this issue Feb 25, 2021 · 16 comments

Comments

@foolip
Copy link
Member

foolip commented Feb 25, 2021

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
Copy link
Member

Autogenerating IDL per CSSOM could be a good additional touch.

@foolip
Copy link
Member Author

foolip commented Feb 28, 2021

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

@saschanaz
Copy link
Member

Hmm, maybe it should go to the IDL package.

@tidoust
Copy link
Member

tidoust commented Mar 3, 2021

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

@saschanaz
Copy link
Member

saschanaz commented Mar 3, 2021

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
Copy link
Member

tidoust commented Mar 4, 2021

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
Copy link
Member

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
Copy link
Member Author

foolip commented Mar 8, 2021

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
Copy link
Member Author

foolip commented Mar 8, 2021

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
Copy link
Member

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

You mean you want multiple blocks? 👀

@foolip
Copy link
Member Author

foolip commented Mar 8, 2021

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
Copy link
Member

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

@tidoust
Copy link
Member

tidoust commented Mar 10, 2021

FYI, I just published @webref/css v1.0.0.

@foolip
Copy link
Member Author

foolip commented Mar 10, 2021

Yay!! I'll try using it right away and see how that goes :)

@tidoust
Copy link
Member

tidoust commented Mar 10, 2021

Closing this issue now that a first version of the package has been published. Bits on CSSOM generated IDL is tracked in #51. Other improvements tracked in #126 and #127. Feel free to raise further issues as needed.

@tidoust tidoust closed this as completed Mar 10, 2021
@foolip
Copy link
Member Author

foolip commented Mar 10, 2021

I had no trouble integrating this into mdn-bcd-collector, success! foolip/mdn-bcd-collector#1047

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants