• Klint-psk (unregistered)

    Frist! Tipical Youtube, to be honest. Always striving to make everything uglier and less functional.

  • bvs23bkv33 (unregistered)

    memcpy((char*)black, "black", 6);

  • Josef Hahn (unregistered)

    When particular companies got strong enough to just completely do what they want, instead of keeping some interoperability alive... But even the introduction "like any reasonable video service" tries hard to hide, what YT/Google actually is: US mega club (like FB, Amazon) looking for world domination....

  • (nodebb)

    But XML isn't cool, so YouTube rolled out a new JSON format.

    Sorry, but "working" beats "cool" into a cocked hat. This seems to be a case of "if it ain't broke, break it".

  • P. Wolff (unregistered)

    In the old times (tm) of 8 colors, color index 0 was used for "transparent", so no need to take it into account.

    And then there was the tester who thought, hey, we have to test at least one strange color (and why more than the bare minimum), and filed a ticket for 0x080808. (Or this was added as a second thought to introduce something black-y.)

    And if the rule were "hey, we only support a single hex digit per color channel," Well, it is more like "hey, we only support a single hex-digit coded bit per color channel."

  • Factory Improvement (unregistered)

    Good to know even the folks at Google have their WTFs

  • P. Wolff (unregistered) in reply to Steve_The_Cynic

    Replace "cool" with "enterprise-y", and the case is closed.

  • Simon (unregistered) in reply to Steve_The_Cynic

    "if it ain’t broke, break it" -- quickly

  • Robin (unregistered)

    Long time reader, but this is my Frist ever comment.

    This is a barely believable WTF. Notwithstanding the actual stupidity stupidity of that code, then unless I'm very much mistaken all it needed was pen.color = "#" + jsonPen.fcForeColor.toString(16) - with I guess some left padding and a bit of input validation. No idea what possessed them to hardcode a very limited set of values, let alone completely failing to do that part properly.

  • my name is missing (unregistered)

    So this is the type of code the vaunted google interview process results in? Not to mention the quality of testing at a trillion dollar company. It's not like youtube is some obscure website from the 90's either, or one of those things google gives us on like google finance (which is the most useless website ever).

  • El Dorko (unregistered)

    Do people actually watch youtube videos? Why?

  • Stu (unregistered)

    For some reason, whatever the user inputs isn't propogated to this as a hex triplet, like #FF0000, but instead as a hex value- 0xFF0000

    Huh? #FF0000 is 0xFF0000. That's almost certainly how the colour value is stored in the browser's memory and exactly what you have to write to video memory (in 24-bit mode or 32-bit mode with the appropriate alpha byte; byte-order and colour corrections notwithstanding) to get that colour. Virtually all graphics APIs can take 32-bit values and directly use them as colours in this way.

  • (nodebb) in reply to Steve_The_Cynic

    Sorry, but "working" beats "cool" into a cocked hat. This seems to be a case of "if it ain't broke, break it".

    Ah. I see the interns are back.

  • James (unregistered) in reply to Simon

    Quickly has the best quotes.

  • (nodebb) in reply to Stu


    When storing a color value as a string, browsers support a condensed format for simple colors - using three characters instead of six - by eliminating the duplicated characters.

    These pinheads took the condensed text representation and converted it back to a number. This resulted in a meaningless value that is actually larger than the value it represents. If they really cared about payload size, they should have simply left the RGB string. If they really cared about having an easy to use interface, then they would have used the proper number. They cared about nothing, so they got this.

  • (nodebb) in reply to Stu

    No, #FF0000 is a string, while 0xFF0000 is a number. And numbers have the problem that 0x000F00 and 0xF00 are the same, while #000F00 and #F00 very much aren't.

  • (nodebb)

    I talk to my friends in JSON, because English isn't cool anymore.

  • P. Wolff (unregistered) in reply to Mr. TA


    I hope I didn't forget any parentheses

  • (nodebb) in reply to P. Wolff

    I hope I didn't forget any parentheses

    Well, all the symbols in your thing were braces and square brackets, so you forgot all the parentheses.

  • (nodebb) in reply to P. Wolff

    ["word":"Yeah, ", "word":"but ", "word":"I ", "word":"think ", "word":"it'", "word":"s ", "word":"more ", "word":"likely", "word":"to ", "word":"be ", "word":"implemented ", "word":"like ", "word":"this."]

  • sizer99 (google)

    This isn't JSON's fault - there's no reason the JSON version shouldn't be as functional and more readable than XML (though if the XML version was working fine...). But apparently they gave an intern who's the boss's kid the job to write the shim for it and the kid knew neither XML, JSON, or JS.

  • (nodebb)

    Could the #080808 be a typo (or misremembered value that nobody bothered to look up) for #808080 grey?

  • Ulysses (unregistered) in reply to my name is missing

    Yup, I lost mucho respect for Google when they hired one of my coworkers. Her resume had nothing worthwhile, and her scripts and markup were crap, yet she landed a front-end role with them. I'm on the fence as to whether she's capable of this WTF.

  • NoLand (unregistered)

    Is this an early indication for hex-triplet strings being on Google's list, to be addressed right after they have done with URLs? (For sure, you do not want to be an RGB-string then.)

  • gnasher729 (unregistered)

    I think it's a victim of "test driven design". Someone wrote the unit test first with half a dozen colours. Then someone wrote the code to pass the unit tests - and nothing else.

  • P. Wolff (unregistered) in reply to gnasher729

    Anything not necessary to pass the given tests would be premature optimization.

  • MHinson (unregistered)

    To give some context for the almost-black-but-not-quite #080808 entry: this is the background color used by regular black-and-white subtitles. So while this "YouTube black" was supported, real black wasn't.

  • Sole Purpose of VIsit (unregistered) in reply to P. Wolff

    I don't think "meeting customer requirements" can be described as premature optimisation. (But you're joking, of course.)

  • P. Wolff (unregistered) in reply to Sole Purpose of VIsit


    And then there's still the question what does "customer requirements" mean?

    • what the users-to-be think they'll need
    • what the guy in control of the client's finances thinks the users-to-be will need
    • what the producer's teamlead thinks ...
    • what the developer thinks ...
    • what the coder ... well, not exactly "thinks" ...
    • what two months later is obvious to everyone what is needed
    • what is really needed

    (plus the stuff we KNOW the client will demand in the near future (and we told them so) - my pre-previous boss told me to build it in, while I'm at it, but to deactivate it, so that we can bill the double amount of hours when the client demands it)

  • MiserableOldGit (unregistered) in reply to P. Wolff

    Ah you missed "What the business analyst presented as a functional requirements document".

    Probably for the best, less informed than the coder and the users if my experience is anything to go by.

  • markm (unregistered) in reply to gnasher729

    So management wanted test-driven design in the worst possible way - and got it.

  • Some Ed (unregistered) in reply to Jaime

    More precisely, these "pinheads" as you put it (more likely one person who wasn't really thinking their best, and a few reviewers who were just literally checking to see if the code was syntactically correct, rather than trying to determine if it was a good idea.) converted the short form to the 12 bit number that is explicitly referenced by the short form.

    Everything would've been fine if they decided to translate the short form to a number that happened to match up to the right number... and also, of course, load all 16781312 possible options into the table.

    Now, don't look at me like that. I fully get that's a bad design. But it would've been fine, because of course google has reviews, and any reviewer should've seen that was a bad design, and then gone back to having the strings translated like any numeric strings are translated, except with some logic to shift the bits of the short form number out to their respective places. (It does occur to me that I have not heard of a machine language instruction that moves bits 8-11 to 20-23, 4-7 to 12-15, and 0-3 to 4-7. So that last bit might be more than one opcode. But it could be done in one line of C or C++ or Java or C# or Perl or ..., even so.)

Leave a comment on “A Splash of Color”

Log In or post as a guest

Replying to comment #:

« Return to Article