• Edd (unregistered)

    Should have outputted js from inside noscript tags.

  • Sole Purpose Of Visit (unregistered)

    Well, that's just the programmer fat-fingering the noscript element into the wrong place. And then copying it at 1000 Hz. (Hz, in enterprisey terms, is short-hand for Heinz.)

    So it's more of a "What the fat finger" than a real WTF. Be nice if the editor in use worked off a schema, and could therefore catch internal elements with inappropriate tags, but still.

  • Andrew (unregistered)

    I'd love to see a test to verify that <noscript> works.

  • (nodebb)

    where exactly was the whitespace added in that? surely they didn't have 'tag1="value1"tag2="value2"' in there?

  • Naomi (unregistered)

    Well, that's just the programmer fat-fingering the noscript element into the wrong place.

    As Naegi Makoto once said, no, that's wrong! Look more closely at the <noscript>, and particulary at the src:

    <noscript><img src="https://i.ytimg.com/vi/ID/hqdefault.jpg" alt="" width="480" height="360"></noscript>

    Notice that ID in the URL? Well, at the very end of the function they return t.replace("ID",e)+a, where e is a parameter to the function. So, moving the <noscript> out of the <script> would leave you with a broken image, so it can't just be a copy-paste mistake.

  • Naomi (unregistered) in reply to Andrew

    If you're talking about <noscript> in general, it can be tested with browser automation pretty easily! If you're talking about this case, well... the fact that totally broken code got released to production should tell you how much they care about testing XP

  • jjrv (unregistered)

    Also worth noting that t.replace("ID",e) will replace only the first occurrence, leaving the ID inside the noscript element with an incorrect URL. Not that it matters of course, since that img element never gets rendered anyway.

  • The Incredible Holk (unregistered) in reply to Andrew

    Test parses HTML output. <noscript> is present. Test passed.

  • Klimax (unregistered)

    "See also: the Holodecks, which were for the USS Enterprise, and clearly were the buggiest most enterprise piece of software in history." Not that surprising. It is self-modifying code written with 90s practices...

  • Sole Purpose Of Visit (unregistered) in reply to Naomi

    But that's still just fat-fingering it and also not enclosing the whole thing in a &gtbr&lt& or a &grdiv&lt& or something. Granted, you'd have to think a teeny bit about what you're doing, so it's fat-brained as well as fat-fingered, but you probably only need to think it through once, and then rinse, wash and repeat 56,999 times.

  • No, Your Name (unregistered) in reply to Andrew

    Turn on JavaScript long enough for that part of the code to start then turn it off very quickly before it gets to the noscript.

  • (nodebb)

    Good thing the <noscript> will never run, since it wouldn't have the actual ID in the URL. "ID" appears twice in the string, but t.replace("ID",e) would only replace the first one. You need to pass a regex with a g flag to replace all. Even if they tested that <noscript> works, bet they would bother validating that the URL is real.

  • Naomi (unregistered) in reply to Sole Purpose Of Visit

    No. There's no way the <noscript> could have been intended to be outside the script block, because the src is nonsense otherwise. If it's outside the script block, reading the URL is enough to make it clear that it's nonsense. It's nothing to do with HTML escaping, and it's nothing to do with mistakenly putting the tag in the wrong place - the way the URL is (supposed to be) constructed makes it clear that the developer intentionally put it there.

  • Tim (unregistered)

    Sometimes I get pissed off with React, but then I see other people building HTML fragments with javascript string concatenation, and my world is OK again.

  • Brian (unregistered)
    I appreciate the use of a <noscript> tag. Providing a meaningful fallback for browsers that, for whatever reason, aren’t executing JavaScript is a good thing. In the olden days, we called that “progressive enhancement” or “graceful degradation”: the page might work better with JavaScript turned on, but you can still get something out of it even if it’s not.

    Oh, I miss those days. Back when web pages were straightforward, they loaded fast, and Javascript did little more than make fancy dropdown menus that anyone concerned with speed or security could easily turn off. Then somewhere along the line, it became all about the "experience", and web sites turned into bloated applications sitting atop a half-baked language that was never intended for that kind of complexity.

  • (nodebb) in reply to Naomi

    the way the URL is (supposed to be) constructed makes it clear that the developer intentionally put it there.

    Looks to me like ID part of the URL used to be fixed, and the snippet was just HTML. Someone told a developer to make the ID part variable, so he took the whole block, jammed it into a variable, replaced the URL segment with "ID", and did a string replace. The developer never bothered to think about the pointlessness of doing this to the noscript part, and no one ever tested the noscript behavior, so no one noticed he broke it.

  • Chris (unregistered) in reply to No, Your Name

    Sounds like the sort of job to give to a new intern.

Leave a comment on “Graceful Depredations”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article