Skip to content

[css-typed-om] .equals methods for CSSStyleValue subclasses #325

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wilddamon opened this issue Oct 18, 2016 · 11 comments
Closed

[css-typed-om] .equals methods for CSSStyleValue subclasses #325

wilddamon opened this issue Oct 18, 2016 · 11 comments

Comments

@wilddamon
Copy link
Contributor

Could be useful for some calculations

e.g. someLengthValue.equals(otherLengthValue)

CSSCalcLength({px: 5}).equals(CSSSimpleLength(5, 'px')) // returns true

@shans

@tabatkins
Copy link
Member

Yes, they definitely all need one, or at least all the "numeric" ones.

@tabatkins
Copy link
Member

So there are several cases here:

  1. Both UnitValues, equal unit: just compare values
  2. Both UnitValues, different but compatible units: convert values, compare?
  3. Both CalcValues, all terms pair up with equal-unit terms: just compare values
  4. Both CalcValues, all terms can group by canonical unit, then can all pair up: convert values, compare?
  5. UnitValue & CalcValue, Calc has same unit: just compare values
  6. UnitValue & CalcValue, Calc has compatible units: convert values, compare?

This all sound good? Any cases I'm missing?

@tabatkins
Copy link
Member

Should we drop 0-valued units from the comparison, so "calc(1px + 0em)" is equal to "1px"?

What if the 0-valued units aren't compatible - is "calc(0px)" equal to "calc(0rad)"? (I assume no; we'll probably check that they have the same CSS type before checking the individual units.)

@shans
Copy link
Contributor

shans commented Apr 3, 2017

I think .equal should be pretty strict equality. We can add a less strict version that does things like unit conversion and 0-valued unit elision if necessary.

So in other words:

  1. yup
  2. nope, they're different.
  3. yep.
  4. nope, they're different.
  5. nope, they're different.
  6. nope, they're different.

@tabatkins
Copy link
Member

That certainly makes things easier to define.

I'm only really concerned about #5 - I don't see a good reason to distinguish between 5px and calc(5px).

@shans
Copy link
Contributor

shans commented Apr 4, 2017

We decided to stick to strict equality for now (i.e. #5 distinguishes because they're different classes)

@tabatkins
Copy link
Member

Unifying idea behind strict equality is "what would a Value Object do for ==, if/when that exists?" - it'll type-check then check for equality of the bytes in the underlying typed array. That gives us our current answer.

Loose equality can be achieved today by casting both to a known type and then calling .equals(), so it's almost just sugar. (Not quite - comparing non-trivial calcs can't be done that way.)

@nainar
Copy link
Contributor

nainar commented Jul 25, 2017

@tabatkins merged in a change from me (#412) and said that they would finish this up themselves. Just posting a status update since we are working on some of the Typed OM spec issues.

@nainar
Copy link
Contributor

nainar commented Aug 16, 2017

Need to add the text to make sure that we recurse over all our children here.

@tabatkins
Copy link
Member

That is to say, currently the last steps assume the children of the functions are all unit-values; it just needs to do a proper recursion instead.

@nainar
Copy link
Contributor

nainar commented Oct 17, 2017

Closing this since the last bit of the text was added in PR #452

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants