-
Notifications
You must be signed in to change notification settings - Fork 142
[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
Comments
Yes, they definitely all need one, or at least all the "numeric" ones. |
So there are several cases here:
This all sound good? Any cases I'm missing? |
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.) |
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:
|
That certainly makes things easier to define. I'm only really concerned about #5 - I don't see a good reason to distinguish between |
We decided to stick to strict equality for now (i.e. #5 distinguishes because they're different classes) |
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.) |
@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. |
Need to add the text to make sure that we recurse over all our children here. |
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. |
Closing this since the last bit of the text was added in PR #452 |
Could be useful for some calculations
e.g. someLengthValue.equals(otherLengthValue)
@shans
The text was updated successfully, but these errors were encountered: