Do not convert hsl/hwb to RGB at parse time to not loose precision #326
Conversation
There was a problem hiding this comment.
So would there be any chance of getting more context on why the color component parsing changes are an improvement? At a glance, it makes parsing potentially slower for non-legacy colors, and the extra heap allocation during rgb color parsing seems unfortunate, we should be able to do better there.
Can we split that from the hsl/hwb changes? I assume the split you're doing makes sense when we start parsing none, but as is I fail to see why it's an improvement.
|
☔ The latest upstream changes (presumably #328) made this pull request unmergeable. Please resolve the merge conflicts. |
|
@bors-servo delegate+ |
|
✌️ @tiaanl can now approve this pull request |
|
@bors-servo r+ |
|
📌 Commit 2f56d1c has been approved by |
|
☀️ Test successful - checks-github |
Parsing is not done in 2 forms as per the spec. Legacy and new syntax. For rgb and hsl where both are valid, first one is tried and if it fails, we try the other.
We also store hsl and hwb values directly without converting them to rgba at parse time. The conversion only happens how before serializing.