Complement vendor prefixed properties by compatibility data from MDN

[frenic]

It's satisfying to see the amount of important properties this adds to the definitions. 🎉

EDIT
Question: The last line here removes vendor prefixed properties that's no longer supported. Without this line it will add a couple of dozen prefixed Moz and O properties like MozBoxShadow and OTransform. Do we want them or should they be removed?
Removed and deprecated properties are separated into a ObsoleteProperties interface marked as @deprecated. This enables warnings through TSLint and enables the possibility to manually exclude that interface.

Some tasks needs to be completed before this is done:

• Reuse property type from original property (right now they are duplicated)
• Add vendor prefixed keywords

[pelotom]

Do we want them or should they be removed?

My vote would be to remove them if they're known to be no longer supported. Thus these typings can serve a valuable function of notifying people that they're using unsupported properties. It's important to remember that people can always choose to circumvent the type system with casts, but I would think 99% of users wouldn't want to be using deprecated properties.

[frenic]

Yeah, that's my vote too. The only problem I can think of is releasing a patch release with updated MDN data where, lets say, a Webkit prefix for a new iOS version is suddenly removed and you get type errors in your project. But you want to keep the prefixed property over a certain period of time until end users has updated their iOS device.

At least there should be information about this in the README with examples of how to use module augmentation to extend interfaces with properties using TypeScript.

Not sure if something similar works with Flow though. But it could be possible to preserve them for Flow definitions not for TypeScript definitions.

[meyer]

Perhaps you could leave them in but prepend a /** @deprecated */ docstring comment?

[pelotom]

Perhaps you could leave them in but prepend a /** @deprecated */ docstring comment?

That would be nice if it resulted in warnings for the users, but AFAIK it has no semantic meaning.

[pelotom]

At least there should be information about this in the README with examples of how to use module augmentation to extend interfaces with properties using TypeScript.

This seems like a good approach to me 👍

[frenic]

It doesn't feel like early drafts belongs in StandardProperties. They are not "standard" anymore. Should they be included in VendorProperties instead?

[frenic]

That would be nice if it resulted in warnings for the users, but AFAIK it has no semantic meaning.

Well TSLint actually warns usage of identifiers marked with /** @deprecated */. So maybe that's a good idea.

[pelotom]

Oh interesting, I didn’t know about that!

[frenic]

I separated the removed and deprecated properties into a ObsoleteProperties interface marked as @deprecated. In that way it enables warnings through TSLint and enables the possibility to manually exclude that interface.

csstype/index.d.ts

Lines 588 to 596 in ef757f2

	export interface ObsoleteProperties<TLength = string | 0> {
	/** @deprecated */
	boxDirection?: BoxDirectionProperty;
	/** @deprecated */
	boxFlex?: GlobalsNumber;
	/** @deprecated */
	boxOrient?: BoxOrientProperty;
	/** @deprecated */
	boxPack?: BoxPackProperty;

[frenic]

I think I've got everything right now. I refactored some code so I hope I haven't introduced any bugs. I'll do some samples to verify.