Looking for collaborators about css-values

[davidtheclark]

Thanks for the confirmation. Will probably dig in pretty soon. Meanwhile, just ran across this: http://www.slideshare.net/maxdesign/understanding-the-mysteries-of-the-css-property-value-syntax. You probably already reviewed that information when making the parser. Helped me.

[ben-eb]

This is also a good resource. 😄

https://developer.mozilla.org/en/docs/Web/CSS/Value_definition_syntax

[delorge]

@ben-eb okay, I will take a look today or next week

[davidtheclark]

The thing that I think would help the most in bringing me or some other potential contributor up to speed on the intentions module would be an example how it would get used. How would a tool like stylelint use this? Would stylelint have to run acquire and run itself and then use the built functions? Or would the built functions be published somehow?

[ben-eb]

css-values is a tool to create modules (or other things). So if we wanted to make a plugin for stylelint, we would install css-values as a development dependency, and then run the generator to output that plugin. Then, consumers of that plugin download the built functions and not the methods used to generate them.

I haven't decided on acquire, other than we should run that periodically to catch updates to the dataset - that's a good task that a bot could do. I think it will be good when we reach 1.0.0 to publish dataset updates with semantic versioning - new properties are minor versions, changes to existing properties are major versions.

[davidtheclark]

Ok, I'd like to try to talk through some details and you correct me if I'm wrong :)

• acquire simply gets the latest JSON data from MDN.
• When you run, you parse the values of that JSON data (so css-values includes an MDN-spec-syntax parser) to generate an tree of nodes.
• Using that node tree, you generate a bunch of functions that can check whether a property-value pair matches the spec.
• The end-user, then, has access to the generated functions (if they want to validate property-value pairs) and also to the node tree itself (if they want to, say, generate a document or do something else).

So if stylelint made a rule that uses generated functions to check for invalid values, it would

• Pull in CSS-values as a dev dependency.
• Run CSS-values and put the output into a directory that is part of the repo, versioned & released.
• Reference those generated functions from its value-no-unknown rule.

Does the above sound right? This kind of practice really helps me understand new things.

[ben-eb]

Spot on, yeah. Note that in addition to acquire, we supplement that data with Autoprefixer (this is just for vendor specific keywords). At the moment that is pulled in via whatever Autoprefixer version the module is currently using.

[delorge]

@ben-eb I can be an collaborator :) Atm I'm not familiar with API yet, but I can help with property coverage for a first time.

[ben-eb]

@delorge I've sent an invite so you can contribute directly to this repo if you would like! I think there are a few more simple tasks in this format (#10), if you would like to take those also it would be really great;

• <url>; for properties that use <uri> instead of the <url> identifier, we can provide an override in https://github.com/ben-eb/css-values/blob/master/src/data.js#L10. More details here: https://developer.mozilla.org/en-US/docs/Web/CSS/url
• <single-animation-iteration-count>; the syntax is infinite | <number> so we can re-use the isNumber validator again here. More details here: https://developer.mozilla.org/en/docs/Web/CSS/animation-iteration-count
• <track-size>; slightly more complicated, but not by much. There are patterns that you can follow for function validation in both isColor and isRepeatStyle. More details here: https://developer.mozilla.org/en-US/docs/Web/CSS/grid-auto-columns
• <geometry-box>; we can re-use the isBox validator for this. More details here: https://developer.mozilla.org/en-US/docs/Web/CSS/mask-origin