Everything resolves to strings

[christianalfoni]

Hi there!

It seems to me that all typing resolves to string?

Example:

export type BorderStyleProperty = Globals | LineStyle | string;

Since it can be a string that will override both Globals and LineStyle, not giving intellisense on the possible properties of the border style.

Is this intentional?

I did some more research: microsoft/TypeScript#29729 (comment)

[christianalfoni]

Btw, this is the proper way to use it:

export type LiteralUnion<T extends U, U = string> = T | (U & {});

[christianalfoni]

Actually best approach wouod just to use (string | {}) where there is a string now, to not conflict with types having a number in them

[zanona]

A 'opt-out' type would be great, actually. Such as CSS.PropertiesStrict which wouldn't fallback to string and require assertion of pre-defined values.

I don't use autocompletion, but allowing a strict value set, would certainly help to keep projects under control as tests would fail if using any value type which is not provided by either csstype or extended within the project itself. Commits that use new values types, would have to be declared on the extension file itself, making the reviewing process a breeze.

[remorses]

Adding the string type to the union does not make much sense imo, you lose auto completion and type validation

[thdxr]

Second adding strict properties - a lot is lost with | string

[sjohnsonaz]

I agree, I'm also losing validation and intellisense because of the | string additions.

[kylemh]

@frenic would you be okay with the introduction of a CSS.PropertiesStrict that doesn't allow non-standard values for properties?

[frenic]

CSSType v3 new uses the (string | {}) hack which solves the autocomplete problem for properties having union string (| string).

You have to know that not all properties fallbacks with union string. Just the ones that needs it for obvious reasons like multiple values, lengths, URLs, functions etc. So the problem of having a separate "strict" version that doesn't fallback to union string at all is that it will result in lots of type errors for simple style like any of these:

{
  color: '#ffffff',
  backgroundImage: 'url(path/to/an/image.jpg)',
  fontSize: '10px',
}

There's lots of examples like this were it will be more of a problem not having union string.

[frenic]

I'm closing this because the original post was related to the autocompletion issue that is now fixed

[kylemh]

Should I open a new issue? My qualm is with properties like display allowing any string.

[frenic]

@kylemh display can have combinations of values https://drafts.csswg.org/css-display/#the-display-properties so it would be wrong to remove | string from that property. I've given it some attempts to combine different values into multiple string literals and in that way be able to skip | string but it's really complicated to do problematically and the type definitions exploded in size and performance issues became a concern so the progress halted.

I may give it another try soon thanks to this which will make things a bit easier. At least support a fragment of different combinations so display becomes complete without | string would be really nice. I'm well aware of the issue but you're welcome to submit a separate issue if you'd like.

[kylemh]

Understood. Thanks so much for the full context. Is there an issue or PR I can follow regarding the potential new attempt with contexts + template literals.