[css-typed-om] What should CSSNumericValue.type() do?

[darrnshn]

Currently the IDL just says ??? type() and there's an issue saying " Figure out how we want to represent the type of an expression in JS, and define the type() method accordingly.", but there's no GitHub issue associated with it.

@shans Seems like we already have wording for the type of a numeric value, but just need to decide how to represent it in Javascript?

[tabatkins]

Yeah, the abstract "type" of a numeric value is a map of units to powers. We could simply reflect that, but it's not clear how useful it is.

[css-meeting-bot]

The Working Group just discussed What should CSSNumericValue.type() do?, and agreed to the following resolutions:

• RESOLVED: type() will be a map of units to powers

The full IRC log of that discussion

<nainar> Topic: What should CSSNumericValue.type() do?
<nainar> Github: https://github.com//issues/482
<nainar> TabAtkins: before calc stuff type was easy - returned string with unit or generic thing like length
<nainar> TabAtkins: difficult due to calc stuff. Map of type to power.
<nainar> TabAtkins: Q now is what form is type in JS. Simple answer: object literal from type to integer powers.
<nainar> dbaron: omitt things that are 0?
<nainar> TabAtkins: Not always. Type maps keeps track of 0 things. Cant add pixel to s/s
<nainar> TabAtkins: incompatible expression .
<nainar> TabAtkins: one type thaat is pixel. Other one is a mathdivide of s/s
<nainar> dbaron: its unitless?
<nainar> TabAtkins: its unit is still time?
<nainar> dbaron: ...
<nainar> TabAtkins: I remember preserving zero types for a reason...
<nainar> TabAtkins: If I can remember why there may have been zero types at one point.
<nainar> dbaron: will there be a simple way to access abstract dimension of unit?
<nainar> dbaron: eg px diided by em. Remember that px/em but abstractally itss unitless
<nainar> TabAtkins: yes that is what the type map tracks and returns
<TabAtkins> https://drafts.css-houdini.org/css-typed-om/#numeric-typing
<nainar> TabAtkins: describes how to produce a type from various things...
<nainar> TabAtkins: maps categories to powers
<nainar> TabAtkins: One limitaation - general caswe - where you are trying to handles % correctly. Hvave to do type inference to see if expression is avllid. There are some compocated div case that shoudl work but are rejected by my expression
<nainar> dbaron: this is becaue you arent converting % to what it si equivalent to
<nainar> TabAtkins: So i nedto checkthat if % wa converted to a valid typed would it be a valid type?
<nainar> TabAtkins: Just returning a map is simple and does job - in simple cases it is more complicated than needed. this addressed general case?
<nainar> fremy: Can we get a helper that gets type and returns whether the map is of that type?
<nainar> TabAtkins: Yes to and to Sum fucntion takes input and throws if it cant convert.
<nainar> RESOLVED: type() will be a map of units to powers

[nainar]

Seems like I suck as a scribe. The resolution should have read

RESOLVED: type() will be a map of types to powers. @tabatkins as FYI.

[darrnshn]

Thanks @nainar. @tabatkins are we also going to expose the percent hint? Not that there's much use for it.

[tabatkins]

Yeah, pretty much all the algos working on types need to look at the percent-hint; if anything in userland wants to work with types, it'll need it too. We shoudl just expose it as another key in the map, like "percent-hint".

[darrnshn]

Fixed in #546