-
Notifications
You must be signed in to change notification settings - Fork 47
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
Color parser is both strict and loose #357
Comments
I will send the PR after merging #356. BenchmarkSince the latency characteristics of string operations are quite different between Windows (MinGW) and Linux, it is hard to satisfy both sides. Linux (x86_64-linux-gnu) - Debian 10 on WSLJulia v1.0.3
Julia v1.2.0
Windows (x86_64-w64-mingw32) - Windows 10Julia v1.2.0
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The following styles are generally valid according to the CSS Level 3, but are rejected in Colors.jl.
Although we do not have to support parsing the all numerical notations, I think it is worth supporting the former because the former is shorter than something like
+5e-1
.On the other hand, the following styles are accepted without errors or warnings.
The former is potentially dangerous since Colors.jl does not support parsing the 8-digit or 4-digit hex notation yet, as mentioned in #353.
The latter is not so dangerous, but the
replace()
is slightly slow.Colors.jl/src/parse.jl
Line 50 in d64fb1a
In the cases where the regex matching is used, there is no need to
replace
the input string. In the case of the named colors,strip()
, which returnsSubString
, may be helpful.The text was updated successfully, but these errors were encountered: