Recently, I've found a rant from 2004 about Internet Explorer's color parsing. Turns out, MS made sure that just about anything will be parsed as a color somehow and I think it makes for a neat challenge.
Well, how does IE parse colors?
Let's give it an input with a length of...
- ...less than 4 chars:
- Replace chars not matching
[0-9a-fA-F]
with "0" - Append "0" until the length is 3 chars
- Split into 3 parts, 1 char each
- Prepend each part with "0"
- Replace chars not matching
- more or equal than 4 chars:
- Replace chars not matching
[0-9a-fA-F]
with "0" - Append "0" until the length is divisible by 3
- Split into 3 parts of equal size
- Remove chars from the front of each part until they are 8 chars each
- Remove chars from the front of each part until one of them starts with something that isn't "0" or until all parts are empty
- Look at the length of the parts: Are shorter than 2? If so, prepend each part with a "0" until each part is 2 chars long. If not, remove characters from the back of each part until they are 2 chars each
- Replace chars not matching
... w h a t
It's true! Here are some examples (irrelevant steps omitted):
F
--> F00 // append "0" until length is 3
--> F, 0, 0 // split into 3 parts
--> 0F, 00, 00 // prepend 0
--> #0F0000 // done
FLUFF
--> F00FF // replace invalid chars with 0
--> F00FF0 // pad to length that is divisible by 3
--> F0, 0F, F0 // split into 3 parts
--> #F00FF0 // done
rADioACtivE
--> 0AD00AC000E // replace invalid chars with 0
--> 0AD00AC000E0 // pad to length that is divisible by 3
--> 0AD0, 0AC0, 00E0 // split into 3 parts
--> AD0, AC0, 0E0 // remove "0"s from the front of each part
// until one part doesn't start with a "0"
--> AD, AC, 0E // remove chars from the back of each part until
// each part is of length 2
--> #ADAC0E // done
1234567890ABCDE1234567890ABCDE
--> 1234567890, ABCDE12345, 67890ABCDE // split into 3 parts
--> 34567890, CDE12345, 890ABCDE // remove chars from the front until
// each part is of length 8
--> 34, CD, 89 // remove chars from the back of
// each part until each part is of length 2
--> #34CD89 // done
rules
--> 000E0 // replace invalid chars with "0"
--> 000E00 // pad to length divisible by 3
--> 00, 0E, 00 // split into 3 parts
--> 0, E, 0 // remove "0"s from the front of each part until one part
// doesn't start with a "0"
--> 00 0E 00 // parts are too short, prepend a "0"
--> #000E00 // done
GHIJKL
--> 000000 // replace invalid chars with "0"
--> 00, 00, 00 // split into 3 parts
--> , , , // remove "0" from the front of each part until empty
--> 00, 00, 00 // parts are too short, prepend "0" until they are length 2
--> #000000 // done
Rules
- This is code-golf, shortest answer wins
- No standard loopholes
- Expect any input matching
[a-zA-Z0-9]*
. Yes, empty input as well (results in #000000). - Output any representation of the resulting RGB color (including but not limited to the actual color, tuples, hex codes, with or without
#
, any case, ...) - For the sake of this challenge, special color names are not respected but instead processed according to the rules. Hence, "red" will result in #000E0D and not #FF0000
Test cases
Note that the #
is completely optional
red -> #000E0D
rules -> #000E00
1234567890ABCDE1234567890ABCDE -> #34CD89
rADioACtivE -> #ADAC0E
FLUFF -> #F00FF0
F -> #0F0000
-> #000000
zqbttv -> #00B000
6db6ec49efd278cd0bc92d1e5e072d68 -> #6ECDE0
102300450067 -> #100000
GHIJKL -> #000000
000000 -> #000000
EDIT
These are the longest Jelly and Vyxal answers I've seen on this site up to this point :o
EDIT 2
Lecdi pointed out that the specification had a flaw that caused undefined behaviour if the input turned into 000000
at some point, such as GHIJKL
. As of now, all answers seem to handle this with the exception of lyxal's 64 byte Vyxal answer.
The flaw in the spec should now be fixed. Sorry!
#100000
. \$\endgroup\$v=>((s=document.body.style).color=v,s.color)
, but the last rule "special color names are not respected" would make it fail anyway... \$\endgroup\$