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\$