Failure via forward thinking



  • Today we got a call from a client that an app we wrote for them is giving validation errors. I can't repro it locally, so I ask for a bit more info. Eventually we discover the client's using IE 10... the last time dev, and hence testing, was done on this app, was when IE 10 didn't even exist. (It's a JSP webapp originally written when Hibernate was still new and cool.)

    Client doesn't want to downgrade to IE9 for various reasons, and I can't see any obvious reason why the app should break in IE 10, so I install IE 10 and fire up the app with the Developer Console running. Stepping through the validation methods, I see that the JavaScript is checking for min and max attributes when validating input boxes. But min and max were only added in HTML5... were the original coders prescient?

    Since this is TDWTF, you already know the answer. In their infinite wisdom, the devs decided to add custom attributes to HTML tags for validation purposes. Two of these validation attributes happened to be named the same as those made official by HTML5. The JavaScript that decides whether to validate fields does the following:

    if (typeof(textbox.min) != 'undefined' || typeof(textbox.max) != 'undefined') {
      var value = parseFloat(textbox.value), min = parseFloat(textbox.min), max = parseFloat(textbox.max);
    

    if ((!isNaN(min) && min > value) || (!isNaN(max) && max < value)) {
    // puke up validation error and die
    }
    }

    Unfortunately, IE 10's implementation of HTML5's min and max attributes ensures that ALL input fields have implicit min and max attributes. So "typeof(textbox.min) != 'undefined'" is always true, and the validation tries to validate EVERYTHING. But that's not the end! Because of JavaScript's loose typing, parsing an empty string as a float yields zero. Hence isNaN(min) and isNaN(max) always return false. The end result is the code evaluates to this:

    if (true || true) {
      var value = parseFloat(textbox.value), min = parseFloat(textbox.min), max = parseFloat(textbox.max);
    

    if ((!false && 0 > value) || (!false && 0 < value)) {
    // we always get here unless value == 0
    }
    }

    The fix? Ensure textbox.min and .max aren't empty strings, in addition to checking if they're undefined. Works on all versions of IE, client is happy, bug is closed. Well, at least I didn't have to change any of the Java code.



  • Not really any WTFs here.



  • an old doctype should be enough to return to the old behavior. no ?

     



  • @MustBeUsersFault said:

    an old doctype should be enough to return to the old behavior. no ?

    No; any valid doctype will still default to IE10 Standards mode. Setting the X-UA-compatible header may work, but that depends on whether or not the input validation additions are removed in IE10's IE{x < 10} Standards mode. Microsoft is unusually inconsistent on that front.

    The proper solution is to implement custom attribute markup with data-* attributes as per the HTML5 recommendation. These are guaranteed to never clash with new HTML functionality.

    @blakeyrat said:

    Not really any WTFs here.

    There are 2 in fact:

    1. The original developers not using data-* attributes and inviting the name-clash.
    2. The TS 'fixing' things by piling on more detection instead of fixing the original problem.


  • @Ragnax said:

    The proper solution is to implement custom attribute markup with data-* attributes as per the HTML5 recommendation.

    But could the original developers have known that, or did they write the code before this recommendation existed?



  • @Gurth said:

    @Ragnax said:
    The proper solution is to implement custom attribute markup with data-* attributes as per the HTML5 recommendation.

    But could the original developers have known that, or did they write the code before this recommendation existed?
    The implication is one should refactor instead of adding to the mess.



  • @Ragnax said:

    The TS 'fixing' things by piling on more detection instead of fixing the original problem.
     

    This.

    Although I admit not being aware of the recommended data- attributes.



  • @Ragnax said:

    1. The original developers not using data-* attributes and inviting the name-clash.
    2. The TS 'fixing' things by piling on more detection instead of fixing the original problem.
    I see two more:
    1. IE10 deciding to add meaningless values to the min and max attributes
    2. Javascript deciding that the empty string is 0.0 instead of NaN

    I also see that loose typing is an endless source of WTFs.



  • @Ragnax said:

    The original developers not using data-* attributes and inviting the name-clash.

    The WTF is your developers aren't time-travelers?

    I have high standards for software, but that's just a tad ridiculous.

    Hey, here's a WTF for you: how about a company delivering a web-based solution that doesn't bother to test new web browsers as they come out? And instead just waits for their clients to experience brokenness? Then when pressed for a fix by the clients, they recommend *downgrading*? How's that for a WTF?

    @Ragnax said:

    The TS 'fixing' things by piling on more detection instead of fixing the original problem.

    Meh. His fix works, yes? And it works with the HTML5 spec, yes? So what's the issue?



  • @Planar said:

    I also see that loose typing is an endless source of WTFs.
     

    There's nothing that reflection cannot fix, and in Javascript reflection is really simple.

    /sobsobsob

     



  • @Planar said:

    I also see that loose typing is an endless source of WTFs.

    Strict typing doesn't get rid of WTFs, it just makes them better-hidden.



  • @blakeyrat said:

    Hey, here's a WTF for you: how about a company delivering a web-based solution that doesn't bother to test new web browsers as they come out? And instead just waits for their clients to experience brokenness?
    Normally I would agree with that.  But in this case, right in the very first paragraph, the OP says (assuming that he is telling the truth) that development and testing of this app was done back when IE10 didn't exist.  So that would mean the app was developed, tested and delivered, then, later, the client switched to IE10.  If IE10 has some new behavior that doesn't work with the app, that's hardly the developers fault, at least in this case.



  • @blakeyrat said:

    @Ragnax said:
    The original developers not using data-* attributes and inviting the name-clash.

    The WTF is your developers aren't time-travelers?

    Mea culpa. When copy pasting a slice of text with the colored code markup for "data-*" I messed up and pasted over a bit too much text I had already written. I'll go ahead and blame that one on CS's incredibly poor excuse for a forum post editor requiring me to input a fucked up mix of BBCode and raw HTML.

    Anyway, it should have stated:
    The original developers not using data-* or similarly prefixed attributes and inviting the name-clash.

    @esoterik said:

    The implication is one should refactor instead of adding to the mess.

    The implication is indeed that one should refactor rather than add to the mess.



  • @El_Heffe said:

    Normally I would agree with that. But in this case, right in the very first paragraph, the OP says (assuming that he is telling the truth) that development and testing of this app was done back when IE10 didn't exist. So that would mean the app was developed, tested and delivered, then, later, the client switched to IE10. If IE10 has some new behavior that doesn't work with the app, that's hardly the developers fault, at least in this case.

    Well derp, but Ragnax's team supports the app, right? If they support the app, wouldn't they take the initiative to test new browsers that come along? I mean you're going to get the tickets eventually, you might as well try to pre-empt them.

    Even if you disagree with that, you have to agree that telling the client to downgrade a security-critical piece of software like a web browser for your app is a WTF.

    @Ragnax said:

    The original developers not using data-* or similarly prefixed attributes and inviting the name-clash.

    What would a developer, pre-HTML5, use a prefixed attribute? Can you point to some guidance (again, written pre-HTML5) that recommends doing that?

    I still think you're being grossly unfair to the original developer. Adding your own custom attributes is not and has never been a WTF in HTML. The only WTF here is that HTML5, for the first time in-- ever?, added some new ones that just happened to conflict with ones you had been using previously. That's not your developer's fault. That's really not HTML5's fault, since they had no alternative. So there's no WTF.



  • @blakeyrat said:

    @El_Heffe said:
    Normally I would agree with that. But in this case, right in the very first paragraph, the OP says (assuming that he is telling the truth) that development and testing of this app was done back when IE10 didn't exist. So that would mean the app was developed, tested and delivered, then, later, the client switched to IE10. If IE10 has some new behavior that doesn't work with the app, that's hardly the developers fault, at least in this case.
    Well derp, but Ragnax's team supports the app, right? If they support the app, wouldn't they take the initiative to test new browsers that come along? I mean you're going to get the tickets eventually, you might as well try to pre-empt them.

    It depends on how the webapp generates money.  If it is something open to the internet in general then of course, but if it is something so one customer (company not individual) then maybe.  For example I had ones that were in the later category and the spec (from said customer) said IE6 so when I got complaints about things not working quite right with newer versions it was "pay us to do the work or downgrade".



  • @Ragnax said:

    The implication is indeed that one should refactor rather than add to the mess.

    Except the meaning actually does match, so using min and max with HTML5 is fine here and handling the slightly different treatment of the attributes in JavaScript actually seems sensible.



  • @Ragnax said:

    Anyway, it should have stated:

    The original developers not using data-* or similarly prefixed attributes and inviting the name-clash.
    That still would have required an inpressive amount of prescience to know beforehand pretty exactly what attributes a future HTML spec will one day officially define.

    Anyone being able to predict the future with such precision would probably not bother working as a coder in IT and rather go straight for making a fortune by winning lotteries repeatedly.



  • @Ragnax said:

    I also see that loose typing is an endless source of WTFs.
    A personal favourite:

    ['3'] == 3; // true
    

    (partial blame due to ECMAScript 5th Ed.'s Array.prototype.toString, which calls join when available)

    Remember kids: be safe; use strict equality.



  • @Zecc said:

    A personal favourite:

    ['3'] == 3; // true

     

    fuuuuuuuuuck

     

    @Zecc said:

    Remember kids: be safe; use strict equality.

    No. I only do that with 0. No well-written code has a comparison like yours by design.



  • @dhromed said:

    @Zecc said:

    A personal favourite:

    ['3'] == 3; // true

     

    fuuuuuuuuuck

    And fuuuuuuck^N

    > [['3']] == 3
    true

    > [[['3']]] == 3
    true
     

     





  • @Anonymouse said:

    @Ragnax said:
    Anyway, it should have stated:

    The original developers not using data-* or similarly prefixed attributes and inviting the name-clash.
    That still would have required an inpressive amount of prescience to know beforehand pretty exactly what attributes a future HTML spec will one day officially define.

    Which is why you would prefix all user-defined attributes, or in case of XHTML: put them in their own namespace. Any developer worth his/her salt should have recognized the problem with forward compatibility and could easily have coded defensively and guarantee forward compatibility that way. (I've certainly been doing so since ca. 2003, for one.)

    Sadly, almost no-one did this back in the day though and worse: nobody had a problem with it. Even authors of major frameworks like Dojo invited this practice and it continues to <href="http://www.codestore.net/store.nsf/unid/BLOG-20121210-1448">screw people over. It took them until 2011 and Dojo 1.6 to finally fix this, almost 3 years after John Resig made one of the first big blips on the radar for awareness of the existence of data-* attributes in the HTML5 drafts.

    So as for blakey's request:
    @blakeyrat said:

    What would a developer, pre-HTML5, use a prefixed attribute? Can you point to some guidance (again, written pre-HTML5) that recommends doing that?

    I don't have a source, because nobody really thought of it as a problem. And anyone that did happen to care enough to produce documents conforming to the HTML DTDs (meaning no use of custom attributes) or to use XML namespacing and custom namespaes was quickly denounced as a "standards nazi". Web development practices around the turn of the century are probably the real WTF; nobody really stopped to think about what they were doing.

    @The_Assimilator said:

    Client doesn't want to downgrade to IE9 for various reasons, and I can't see any obvious reason why the app should break in IE 10, so I install IE 10 and fire up the app with the Developer Console running. Stepping through the validation methods, I see that the JavaScript is checking for min and max attributes when validating input boxes. But min and max were only added in HTML5... were the original coders prescient?

    ...

    if (typeof(textbox.min) != 'undefined' || typeof(textbox.max) != 'undefined') {
      var value = parseFloat(textbox.value), min = parseFloat(textbox.min), max = parseFloat(textbox.max);
    
      if ((!isNaN(min) && min > value) || (!isNaN(max) && max < value)) {
        // puke up validation error and die
      }
    }

    Huh. that's funny. I hadn't noticed this before, but: have you actually tested the validation to work as expected in IE9? I think it's already broken there, as Microsoft stopped creating IDL attributes (aka 'DOM expandos') from user-defined content attributes back then. That means those typeof(x) != 'undefined' guard conditions would never be satisfied because the min and max properties would not be created. You'd need to use the getAttribute method instead.



  • @StephenCleary said:

    Relevant
     

    +1 relevant would repost



  • @Ragnax said:

    Microsoft stopped creating IDL attributes (aka 'DOM expandos') from user-defined content attributes back then. That means those typeof(x) != 'undefined' guard conditions would never be satisfied because the min and max properties would not be created. You'd need to use the getAttribute method instead.
     

    I don't understand why anyone would expect custom attributes-- any attributes really -- to turn into expandos automatically.

    I also don't understand why you typed "typeof()" when I'm 100% certain you know it's an operator.

     



  • @TGV said:

    And fuuuuuuck^N

    > [['3']] == 3
    true

    > [[['3']]] == 3
    true

    Yep, because ofcourse Array.prototype.join calls toString on all its constituents and Array.prototype.toString calls Array.prototype.join internally.

    Personally, I was always partial to:

    []].map.call( "Batman", function( x, y, z ) { return x ? +y : z }).reverse().join( " " );
    

    @dhromed said:

    @Ragnax said:

    Microsoft stopped creating IDL attributes (aka 'DOM expandos') from user-defined content attributes back then. That means those typeof(x) != 'undefined' guard conditions would never be satisfied because the min and max properties would not be created. You'd need to use the getAttribute method instead.
     

    I don't understand why anyone would expect custom attributes-- any attributes really -- to turn into expandos automatically.

    I also don't understand why you typed "typeof()" when I'm 100% certain you know it's an operator.

     

    Ask the original developers of the TS's code then, for answers to both questions.



  •  



  • @Ragnax said:

    [].map.call( "Batman", function( x, y, z ) { return x ? +y : z }).reverse().join( " " );
     

    ..that reminds me of a bit of super-clever experimental WTF code that performed all sorts of operations without using string-, boolean, or number literals.

    It was a long time ago. Don't quite remember. I think it produced Hello World output or something.



  • @Ragnax said:

    @Anonymouse said:
    That still would have required an inpressive amount of prescience to know beforehand pretty exactly what attributes a future HTML spec will one day officially define.
    Which is why you would prefix all user-defined attributes
    Then you still need to know beforehand which prefixes will eventually be defined at some later point down the time line so you can avoid using them now.

    Sure, you can always come up with something that you think noone else will ever use - but you'll never be able to guarantee it.

     



  • @Ragnax said:

    []].map.call( "Batman", function( x, y, z ) { return x ? <font color="#800080">+</font>y : z }).reverse().join( " " );
    You don't trust map to send you a numerical index, or is that just for extra flare?



  • @Zecc said:

    @Ragnax said:

    [].map.call( "Batman", function( x, y, z ) { return x ? <font color="#800080">+</font>y : z }).reverse().join( " " );
    You don't trust map to send you a numerical index, or is that just for extra flare?


    No, I derped and switched the x and y.

    Actually, if dhromed wanted 'clever'; I can do that and work around the ternary by abusing type conversion even further:
    []].map.call( "Batman", function( x, y, z ) { return !y && z || +x }).reverse().join( " " );

    Needless to say; if you actually pull this kind of crap in production then you deserve to be thrown out on your ass.



  • @Ragnax said:

    Yep, because ofcourse Array.prototype.join calls toString on all its constituents and Array.prototype.toString calls Array.prototype.join internally.

    But then also

    > [3] == [3]

    false

    Personally, I was always partial to:
    [].map.call( "Batman", function( x, y, z ) { return x ? +y : z }).reverse().join( " " );
    Nice

     



  • @blakeyrat said:

    Hey, here's a WTF for you: how about a company delivering a web-based solution that doesn't bother to test new web browsers as they come out?
     

    No, TRWTF is that the company didn't put browser compatability support details into the contract with the client.  "We will test and guarentee full compatability on Internet Explorer 8,9, Firefox 2 - Firefox 20, Google Chrome v??? and Safari (Mac) v???"

    Otherwise, you will get the following support tickets:

    1) The drop down lists look wrong in IE10 FIX THEM!

    2) I can't upload a file from my iPad's browser FIX IT!

    3) Bob in Accounting can't use IE6 on your site FIX IT!

    4)  Basement-dweller/IT Rockstar Mike says the photosharing site doesn't work on Lynx. FIX IT!

    Not to say that a web-development company SHOULDN'T respond to a client's needs when new browser/OS versions come along. But that should be extended support and, most likely, paid for.  Just as it would be unreasonable for the solution to be "downgrade", it's just as unreasonable to expect a company to code for the entire browser ecosystem, past, present and future.



  • @TGV said:

    @Ragnax said:

    Yep, because ofcourse Array.prototype.join calls toString on all its constituents and Array.prototype.toString calls Array.prototype.join internally.

    But then also

    > [3] == [3]

    false

    You are comparing two objects and not an object and a primitive. When comparing two objects, type conversion is not applied. Instead, the objects are compared directly using reference equality.

    And since we're halfway there already, let's complete this micro-lecture on the caveats of JavaScript's typing system with the following:

     0  == false
    "0" == true
    "0" == 0
    

    In other words: weakly typed comparisons are not transitive.



  • @dhromed said:

    @Ragnax said:

    [.map.call( "Batman", function( x, y, z ) { return x ? +y : z }).reverse().join( " " );
     

    ..that reminds me of a bit of super-clever experimental WTF code that performed all sorts of operations without using string-, boolean, or number literals.

    It was a long time ago. Don't quite remember. I think it produced Hello World output or something.

    CS kinda hoses the script, but I think I got it:

    ([][[]]+[])[!+[]+!![]]+([]+[][(![]+[])[!+[]+!![]+!![]]+([]+{})[+!![]]+(!![]+[])[+!![]]+(!![]+[])[+[]]][([]+{})[!+[]+!![]+!![]+!![]+!![]]+([]+{})[+!![]]+([][[]]+[])[+!![]]+(![]+[])[!+[]+!![]+!![]]+(!![]+[])[+[]]+(!![]+[])[+!![]]+([][[]]+[])[+[]]+([]+{})[!+[]+!![]+!![]+!![]+!![]]+(!![]+[])[+[]]+([]+{})[+!![]]+(!![]+[])[+!![]]]((!![]+[])[+!![]]+([][[]]+[])[!+[]+!![]+!![]]+(!![]+[])[+[]]+([][[]]+[])[+[]]+(!![]+[])[+!![]]+([][[]]+[])[+!![]]+([]+{})[!+[]+!![]+!![]+!![]+!![]+!![]+!![]]+(![]+[])[!+[]+!![]]+([]+{})[+!![]]+([]+{})[!+[]+!![]+!![]+!![]+!![]]+(+{}+[])[+!![]]+(!![]+[])[+[]]+([][[]]+[])[!+[]+!![]+!![]+!![]+!![]]+([]+{})[+!![]]+([][[]]+[])[+!![]])())[+[]]+(!![]+[])[+!![]]+([]+{})[+!![]]+[][(![]+[])[!+[]+!![]+!![]]+([]+{})[+!![]]+(!![]+[])[+!![]]+(!![]+[])[+[]]][([]+{})[!+[]+!![]+!![]+!![]+!![]]+([]+{})[+!![]]+([][[]]+[])[+!![]]+(![]+[])[!+[]+!![]+!![]]+(!![]+[])[+[]]+(!![]+[])[+!![]]+([][[]]+[])[+[]]+([]+{})[!+[]+!![]+!![]+!![]+!![]]+(!![]+[])[+[]]+([]+{})[+!![]]+(!![]+[])[+!![]]]((!![]+[])[+!![]]+([][[]]+[])[!+[]+!![]+!![]]+(!![]+[])[+[]]+([][[]]+[])[+[]]+(!![]+[])[+!![]]+([][[]]+[])[+!![]]+([]+{})[!+[]+!![]+!![]+!![]+!![]+!![]+!![]]+([][[]]+[])[+[]]+([][[]]+[])[+!![]]+([][[]]+[])[!+[]+!![]+!![]]+(![]+[])[!+[]+!![]+!![]]+([]+{})[!+[]+!![]+!![]+!![]+!![]]+(+{}+[])[+!![]]+([]+[][(![]+[])[!+[]+!![]+!![]]+([]+{})[+!![]]+(!![]+[])[+!![]]+(!![]+[])[+[]]][([]+{})[!+[]+!![]+!![]+!![]+!![]]+([]+{})[+!![]]+([][[]]+[])[+!![]]+(![]+[])[!+[]+!![]+!![]]+(!![]+[])[+[]]+(!![]+[])[+!![]]+([][[]]+[])[+[]]+([]+{})[!+[]+!![]+!![]+!![]+!![]]+(!![]+[])[+[]]+([]+{})[+!![]]+(!![]+[])[+!![]]]((!![]+[])[+!![]]+([][[]]+[])[!+[]+!![]+!![]]+(!![]+[])[+[]]+([][[]]+[])[+[]]+(!![]+[])[+!![]]+([][[]]+[])[+!![]]+([]+{})[!+[]+!![]+!![]+!![]+!![]+!![]+!![]]+(![]+[])[!+[]+!![]]+([]+{})[+!![]]+([]+{})[!+[]+!![]+!![]+!![]+!![]]+(+{}+[])[+!![]]+(!![]+[])[+[]]+([][[]]+[])[!+[]+!![]+!![]+!![]+!![]]+([]+{})[+!![]]+([][[]]+[])[+!![]])())[!+[]+!![]+!![]]+([][[]]+[])[!+[]+!![]+!![]])()([][(![]+[])[!+[]+!![]+!![]]+([]+{})[+!![]]+(!![]+[])[+!![]]+(!![]+[])[+[]]][([]+{})[!+[]+!![]+!![]+!![]+!![]]+([]+{})[+!![]]+([][[]]+[])[+!![]]+(![]+[])[!+[]+!![]+!![]]+(!![]+[])[+[]]+(!![]+[])[+!![]]+([][[]]+[])[+[]]+([]+{})[!+[]+!![]+!![]+!![]+!![]]+(!![]+[])[+[]]+([]+{})[+!![]]+(!![]+[])[+!![]]]((!![]+[])[+!![]]+([][[]]+[])[!+[]+!![]+!![]]+(!![]+[])[+[]]+([][[]]+[])[+[]]+(!![]+[])[+!![]]+([][[]]+[])[+!![]]+([]+{})[!+[]+!![]+!![]+!![]+!![]+!![]+!![]]+([][[]]+[])[!+[]+!![]+!![]]+(![]+[])[!+[]+!![]+!![]]+([]+{})[!+[]+!![]+!![]+!![]+!![]]+(+{}+[])[+!![]]+([]+[][(![]+[])[!+[]+!![]+!![]]+([]+{})[+!![]]+(!![]+[])[+!![]]+(!![]+[])[+[]]][([]+{})[!+[]+!![]+!![]+!![]+!![]]+([]+{})[+!![]]+([][[]]+[])[+!![]]+(![]+[])[!+[]+!![]+!![]]+(!![]+[])[+[]]+(!![]+[])[+!![]]+([][[]]+[])[+[]]+([]+{})[!+[]+!![]+!![]+!![]+!![]]+(!![]+[])[+[]]+([]+{})[+!![]]+(!![]+[])[+!![]]]((!![]+[])[+!![]]+([][[]]+[])[!+[]+!![]+!![]]+(!![]+[])[+[]]+([][[]]+[])[+[]]+(!![]+[])[+!![]]+([][[]]+[])[+!![]]+([]+{})[!+[]+!![]+!![]+!![]+!![]+!![]+!![]]+(![]+[])[!+[]+!![]]+([]+{})[+!![]]+([]+{})[!+[]+!![]+!![]+!![]+!![]]+(+{}+[])[+!![]]+(!![]+[])[+[]]+([][[]]+[])[!+[]+!![]+!![]+!![]+!![]]+([]+{})[+!![]]+([][[]]+[])[+!![]])())[!+[]+!![]+!![]]+([][[]]+[])[!+[]+!![]+!![]])()(([]+{})[+[]])[+[]]+(!+[]+!![]+!![]+!![]+!![]+!![]+[])+([][[]]+[])[!+[]+!![]])+([][[]]+[])[!+[]+!![]+!![]]+([][[]]+[])[!+[]+!![]]


  • @Ragnax said:

    Which is why you would prefix all user-defined attributes, or in case of XHTML: put them in their own namespace. Any developer worth his/her salt should have recognized the problem with forward compatibility and could easily have coded defensively and guarantee forward compatibility that way. (I've certainly been doing so since ca. 2003, for one.)

    Well aren't you a special little snowflake.

    But wait, you're the one supporting this app, yes? So why didn't you fix it back when you took over? Slacker.

    @Ragnax said:

    Sadly, almost no-one did this back in the day though and worse: nobody had a problem with it.

    Why would they have? It's perfectly valid in HTML, and everybody who wasn't a dumbshit knew out-of-the-gate that XHTML was a loser format that wouldn't survive 5 years.

    Nobody had a problem with it, because it was perfectly valid. Guess what? So was putting ActiveX in a script tag. HTML did a lot of things that we realize in retrospect were bad ideas.

    Shit happens. Get over it.

    @Ragnax said:

    I don't have a source, because nobody really thought of it as a problem.

    Except you, the special little snowflake. Aw.

    @Ragnax said:

    Web development practices around the turn of the century are probably the real WTF; nobody really stopped to think about what they were doing.

    I like how you blame the users of web formats and not the progenitors. The problem with web development at the turn of the century is the same problem it has now: the W3C is fucking terrible. People ignore the standards because it's fucking 2013 and HTML/CSS still doesn't have fucking columns. People have good reason to throw the W3C specs in the trash and use what works-- the W3C doesn't meet their needs and never has.



  • @Lorne Kates said:

    2) I can't upload a file from my iPad's browser FIX IT!

    2a) Every single file I upload from my iPad to the web-based file manager is named image.jpg! Even if I upload multiple files in the entry box, they're all called image.jpg!



  • @Ben L. said:

    @Lorne Kates said:
    2) I can't upload a file from my iPad's browser FIX IT!

    2a) Every single file I upload from my iPad to the web-based file manager is named image.jpg! Even if I upload multiple files in the entry box, they're all called image.jpg!

     

    [b]image.png[/b]

    Bugfixed.



  • @Lorne Kates said:

    @Ben L. said:

    @Lorne Kates said:
    2) I can't upload a file from my iPad's browser FIX IT!

    2a) Every single file I upload from my iPad to the web-based file manager is named image.jpg! Even if I upload multiple files in the entry box, they're all called image.jpg!

     

    image.png

    Bugfixed.

    My actual real bugfix was to rename the second image to image.jpg_0, the third to image.jpg_1, and so on.



  • @blakeyrat said:

    HTML did a lot of things that we realize in retrospect were bad ideas.

    No. HTML didn't. Cowboy-coders trying to shoehorn stuff into HTML did. And why were they bad ideas? Because said developers didn't think them through all the way and didn't weigh essential pros and cons such as forward compatibility. (Come on; the notion that the web was an evolving platform existed back then as well.)

    @blakeyrat said:

    People ignore the standards because it's fucking 2013 and HTML/CSS still doesn't have fucking columns.

    I agree that the W3C's process is slow. (And I mean; slooooooo-------w.) Its more or less inherent to sticking representatives of the world's most powerful tech corporations in committees and expecting them to standardize on features "for the good of the user". Everyone wants his/her say and when push comes to shove everyone will still want things to conform to their business views and interests. This is not helped at all by the fact that specifications being submitted for standardization are almost exclusively formalizations of already existing implementations; the original developer will always try to railroad everyone into accepting with as little change as possible, because that means no more changes required to their implementation. (Seriously; the mailing lists contain verbatim reasoning along the lines of "we don't want to do this, because it would be hard to implement in WebKit".)

    However, if you attack the W3C, please atleast attack them on valid points that are actual issues (such as the lethargic design-by-committee in general and the underlying conflict of interest). Multi-column layout and complex box layout are a done deal:

    (Why the hell these recommendations are still stuck at 'candidate' level, I do not know. Probably, the fact that they haven't been promoted yet is the real WTF here because there are certainly two independent implementations in the latest versions of Chrome and IE.)

    And for good measure; complex flowing of continuous content through sets of differently shaped regions is being worked on:

    @blakeyrat said:

    Except you, the special little snowflake. Aw.

    [...]

    Well aren't you a special little snowflake.

    I'm going to be the better person here and ignore the blatant ad hominem.



  • @Ragnax said:

    No. HTML didn't. Cowboy-coders trying to shoehorn stuff into HTML did. And why were they bad ideas? Because said developers didn't think them through all the way and didn't weigh essential pros and cons such as forward compatibility. (Come on; the notion that the web was an evolving platform existed back then as well.)

    Why do you think the SCRIPT tag has (had, I guess) a type attribute if you weren't supposed to be able to use different types of scripting? Why do you think DOM went out of its way to be language-neutral?

    HTML was designed to be extensible, those companies extended it. It wasn't "cowboy-coding", it was "using the format in the way it was originally intended to be used".

    @Ragnax said:

    Multi-column layout and complex box layout are a done deal:

    (Why the hell these recommendations are still stuck at 'candidate' level, I do not know. Probably, the fact that they haven't been promoted yet is the real WTF here because there are certainly two independent implementations in the latest versions of Chrome and IE.)

    So when you say "are a done deal" what you mean is "aren't yet a done deal." Gotcha.

    Look, CSS3 is fine and all, but why the fuck wasn't something as widely-used as COLUMNS in CSS 2? Or fucking CSS 1? EVERY SITE HAS COLUMNS. Why the fuck doesn't CSS have variables you can shove (say) colors into? So you don't have your border color listed 47 times in the CSS file? Why the shit doesn't CSS allow you to do math between design-time and run-time measures? (For example, why can't I set a measure to 5px + 5em?) CSS was designed by retards and after 3 versions it's still designed by retards. (BUT OH HEY rollover effects were important enough to have in 1.0! Because obviously your LAYOUT LANGUAGE needs rollover effects long before it needs columns!)

    @Ragnax said:

    I'm going to be the better person here and ignore the blatant ad hominem.

    Aw.

    I'm just joshin' ya Ragnax. Ain't nothing personal. You precious little snowflake.

    BTW you kind of ignored my point there: if you always used your own prefix for attributes since 2003, why hadn't you fixed this app long before IE10 came around?



  • @blakeyrat said:

    People ignore the standards because it's fucking 2013 and HTML/CSS still doesn't have fucking columns.
     

    I can easily make a column-based layout via css. Let's say the class I want to use is column .  Here's how you make it work, 100% of the time in every browser:

    @See, Roland? said:


    <table><tr>

       <td class='column'>Look I'm a column styled by css!</td>

       <td class='column'>I too am a column styled by css!</td>

    </tr></table>




  • @blakeyrat said:

    BTW you kind of ignored my point there: if you always used your own prefix for attributes since 2003, why hadn't you fixed this app long before IE10 came around?

    Because I'm not the TS and it's not my app. Duh?

    @blakeyrat said:

    Why the fuck doesn't CSS have variables you can shove (say) colors into? So you don't have your border color listed 47 times in the CSS file? Why the shit doesn't CSS allow you to do math between design-time and run-time measures?

    Also being worked on:

    @blakeyrat said:

    So when you say "are a done deal" what you mean is "aren't yet a done deal." Gotcha.

    From the side of the W3C it's a done deal. Moving a candidate recommendation into a full recommendation requires a minimum of two independent browser implementations. So the ball's probably in the court of the browser vendors now. That or there's still a last call for editors comments active. (Not that unlikely for the flexbox module, actually.)



  • @Ragnax said:

    Also being worked on:

    Wow an obvious shortcoming from version 1 is being worked-on only 15 years later. Well you've certainly changed my mind about the W3C!



  • @Ragnax said:

    In other words: weakly typed comparisons are not transitive.

    Which matters fuck-all. Why are you comparing a string to a boolean in the first place? What is wrong with you?



  • @morbiuswilters said:

    @Ragnax said:
    In other words: weakly typed comparisons are not transitive.

    Which matters fuck-all. Why are you comparing a string to a boolean in the first place? What is wrong with you?

    It was to illustrate the fact that weak comparison is non-transitive. This means that even a simple piece of code that has to check whether a, b and c all have equal value (though possibly not of the same type) can not in all cases be written using transitivity:

    if ( a == b && a == c ) {
      // b == c may be a false assumption here
    }

    Yes, I have seen bugs caused by this and it is one of those very 'fun' things a non-aware developer can spend hours on, trying in vain to correct a bug in his/her code.



  • @Ragnax said:

    It was to illustrate the fact that weak comparison is non-transitive.

    Yeah, I know. Which is why I said it matters fuck-all.

    @Ragnax said:

    This means that even a simple piece of code that has to check whether a, b and c all have equal value (though possibly not of the same type) can not in all cases be written using transitivity:

    if ( a == b && a == c ) {
      // b == c may be a false assumption here
    }

    They don't have the same value since they don't have the same type. There are rules for how they are coerced if you're doing comparison between different types, you just fail to understand these rules. Is this, like, the first time you've ever encountered a type system before? If you're expecting 0 == false, "0" == true and "0" != 0 then, I dunno, you must be insane. A better question is why you're trying to do a three-way comparison between three different types in the first damn place.

    @Ragnax said:

    ...it is one of those very 'fun' things a non-aware developer can spend hours on, trying in vain to correct a bug in his/her code.

    That's true of any language feature: if you don't understand how the fucking tool works, you have no business using it. (This is normally said by Morbs when he has someone kneeling before him and is slapping that person back-and-forth across the face.)



  • @morbiuswilters said:

    There are rules for how they are coerced if you're doing comparison between different types, you just fail to understand these rules.

    No, I know and understand those rules. Others though, who are caught off guard by how type conversion interplays with comparison operators, probably do not know or understand those rules. (Maybe TGV, who posted some comparison results he found "fuuuuucked"...) My previous posts attempted to clarify why those exact results popped out of the comparisons and I tossed in the non-transitivity bit myself.

    @morbiuswilters said:

    if you don't understand how the fucking tool works, you have no business using it.

    Absolutely true. Sadly it's still a problem that only a small group of the developers active with JavaScript really understand how the language works. The others just try to tackle it as if it were C-family language or Java and fail hard on concepts like type conversion (or prototypal inheritance).



  • @The_Assimilator said:

    [...] originally written when Hibernate was still new and cool.
    Does that mean it's no longer cool? Every man and his dog appears to be using it. Well, that would kind of make it no longer cool, I suppose.

     


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.