Comments

[frenic]

Started with link to MDN and a simple browser compatibility table for "standard" properties only. Some initial thoughts:

• The file size almost doubled. The problem is that all comments are repeated four times for all the different variations (camel case, kebab case and fallback). Will there by some kind of performance issue? Should the typings be spitted into several files?
• mdn-browser-compat-data is a working project by MDN, but still very incomplete. Some data i lacking and in some cases inaccurate. Should the compatibility table be removed until it's more stable?
• What data from either mdn-data or mdn-browser-compat-data is also interesting to have included? There's things like syntax, status, initial value, computed value, what's animatable etc.

[pelotom]

So cool!

[pelotom]

My 2 cents:

• The file size almost doubled. The problem is that all comments are repeated four times for all the different variations (camel case, kebab case and fallback). Will there by some kind of performance issue? Should the typings be spitted into several files?

I'm not too worried about a doubling of the file size, particularly since types don't affect bundle size. When playing with it did it seem to affect performance? (I would be surprised if it did)

• mdn-browser-compat-data is a working project by MDN, but still very incomplete. Some data i lacking and in some cases inaccurate. Should the compatibility table be removed until it's more stable?

My feeling is that this is very useful and should be added even if incomplete. As with the missing properties and keywords, having it out there and people using it is good because we find gaps faster that way, and also it creates more encouragement for the gaps to be closed.

• What data from either mdn-data or mdn-browser-compat-data is also interesting to have included? There's things like syntax, status, initial value, computed value, what's animatable etc.

Maybe just initial value, and let people follow the link for anything else?

[frenic]

Thanks for commenting 💗 I was really hoping for you to show up. Otherwise I would look stupid talking to myself. 😆

I'm not too worried about a doubling of the file size, particularly since types don't affect bundle size. When playing with it did it seem to affect performance?

Haven't noticed anything with TypeScript. Flow in the other hand worries me. But I've skipped the comments for those typings (I've even have no clue if they support it). The index.d.ts file is now 17k+ lines of code and 600KB+. And when combined keywords drops in it will certainly explode in size again. I'm just curious if there's any limit when it starts to hurt. I mean, csstype is special in that way that it's built by machine. It's quite rare that you bump into typings made by humans in this size. Right?

My feeling is that this is very useful and should be added even if incomplete. As with the missing properties and keywords, having it out there and people using it is good because we find gaps faster that way, and also it creates more encouragement for the gaps to be closed.

Yeah, I feel this is really useful too. Lets keep it.

Maybe just initial value, and let people follow the link for anything else?

I added initial value. That probably the most useful for now. It's quite often you encounter code where they style explicitly with the initial value even though it doesn't inherit anything. This would help out a bit in that area.

[pelotom]

I'm just curious if there's any limit when it starts to hurt. I mean, csstype is special in that way that it's built by machine. It's quite rare that you bump into typings made by humans in this size. Right?

Yeah, I'm not really sure. I think the only way to find out is to try it out and see 😀 But anecdotally I've only seen significant slowdowns with the (TS) type system when doing fancy type level computation, and in theory jsdocs should have no affect on that.

[frenic]

Hopefully not. Let's find out 😉 🎉