-
Notifications
You must be signed in to change notification settings - Fork 100
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
Implement CSSNumericValue.parse() #206
Conversation
I think we might have come at a point where it might be a good idea to split off the CSSOM polyfill into its own repo with its own tests? I mean, feels like this could become its own library. |
It still limited to implementing the parts needed for this library.. But I’ve been thinking we should start by moving the implementation into its own folder to make it more explicit that the code is meant for polyfilling parts of the typed cssom. As it is right now it could be tempting to use internal functions directly without going through the public api when implementing scroll driven animations. Then we would end up with too tight a coupling. I can create a refactoring PR once the open PRs are merged. |
Yeah, sounds like a good plan. Which PRs specifically – other than this one – definitely need to be merged? |
I was wrong. I looked through the other PRs, and it looks like none of them are touching the cssom implementation, so we should be fine after this PR is in. We could do it as part of this PR as well, if that's preferable. |
I think it’d be best to do this refactor as part of a separate PR. |
8bcc515
to
e64a826
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some minor nits to address (changes suggested).
d2a0a83
to
ef9eb58
Compare
@bramus Thank you for the review 🙏 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow, this is a lot! I'm a bit concerned about the size increase. We'll have to think about what parts of this could be removed for a reduced build. Also, do we skip this parsing code if the browser supports CSSStyleValue.parse?
To be clear, I'm ecstatic to see such a precise implementation following the spec steps! I just think the extra kilobytes will be too much for some sites, and we'll want to have a light version of the polyfill where you have to construct the CSSOM value instead of parsing it from a string. |
Yeah, I know it's a lot 😅, and by all means we don't have to use it. It's been an interesting exercise :) If we had a build system that could build two targets, we could build one with a full implementation of The current solution though (that I'm at fault for), supports some math functions but can fail in more complex calculations. And there's no clear definition of what it will support or not. It also fails in browsers without regex lookahead support (Safari < 16.4). |
20ae1ed
to
8e7cf38
Compare
src/numeric-values.js
Outdated
return tokenizeString(input); | ||
} | ||
// Assert: Only the preceding types should be passed as input. | ||
throw new TypeError(`Invalid input type git${typeof input}`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the text "git" prepended before the type may have been unintentional?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh.. that's embarrassing 😅
I'm having an issue where the focus is delayed when switching between the IDE and the terminal 😞
src/tokenizer.js
Outdated
let position = this.index | ||
for (let i = 0; i < 3; i++) { | ||
const nextCodePoint = this.input.codePointAt(position); | ||
if (typeof nextCodePoint !== 'undefined') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to the MDN docs, codePointAt only returns undefined if the index is out of range. I think it would be cleaner to change the for loop condition to i < 3 && position < this.input.length
, then if the loop runs we always expect it to find a codepoint.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah.. That looks cleaner:
Fixed here: https://github.com/flackr/scroll-timeline/compare/8e7cf381430bd1d2c7511debec7d954ebaccaf66..4ed64d0898c93a488381f6ad35c42033b39698a8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🙏
8e7cf38
to
4ed64d0
Compare
4ed64d0
to
cf22c2b
Compare
Update src/simplify-calculation.js Co-authored-by: Bramus <[email protected]> Update src/simplify-calculation.js Co-authored-by: Bramus <[email protected]> Update src/numeric-values.js Co-authored-by: Bramus <[email protected]> Update src/numeric-values.js Co-authored-by: Bramus <[email protected]> Update src/numeric-values.js Co-authored-by: Bramus <[email protected]> Update src/numeric-values.js Co-authored-by: Bramus <[email protected]> Reify e and pi, rename to transformToCSSNumericValue and add jsdoc
cf22c2b
to
0ff6f35
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the changes, looks good to me!
Add proper tokenization and parsing for CSSNumericValue.parse().