• (cs) in reply to Spudley
    Anonymous:
    Far me it from me to point out how utterly retarded it is to (ab)use JS like that to make a link submit a form, whether using the javascript: pseudoprotocol, or on an onclick event. Seriously, people, use a proper friggin' form button! For the sake of a demo, here's a page on my wiki: http://talideon.com/wiki/?doc=WikiEtiquette. See the use edit version link at the bottom? That's no link, it's a form button, and it's a form button because clicking it changes the wiki's view state. See how it looks like the links to each side: CSS.

    Okay. I can agree with you up to a point. However:
    1. Your button doesn't get styled as intended in the Konqueror browser (which is my default).


    Fair and reasonable. I'd like to have tested it on Konq and Safari, but there's nobody I know who runs either, and the best I'd be able to do is an old version on a Knoppix CD I've lying around here somewhere.


    2) The button text can't be copied+pasted, and breaks the flow of your text, so if you need to include something like this within your page's body text, it won't look right, and will probably choke search engines.


    The former is regrettable, but unavoidable. However, if the browser supports inlining of block elements and styling, this shouldn't be a problem, and it could be argued that the copy & paste problem is more a browser issue than an issue with buttons. That, and it degrades more gracefully than a JS/hidden form based solution: at least it always works.

    The latter isn't a problem. Clicking it triggers a HTTP POST, which no search engine should do anyway.

    3) If you're writing an Ajax app, you're going to be using Javascript anyway, so I don't see anything wrong with an onclick event in that case. (not all onclicks result in a call to the server; eg treeviews and menus just make other elements (dis)appear).


    Yup, but I personally like to make that kind of thing an enhancement rather than a requirement. With trees, JavaScript is unavoidable, but can be made unobtrusive. With menus, on the other hand, you only need JS if you need to hack around IE's poor support for :hover.

    K.
  • (cs) in reply to whatever
    Anonymous:
    I actually think you've got this the wrong way round. I don't think that a programmer should jeopardise security (or standards for that matter) for the sake of the designer's 'freedom'. The case in point is not merely a question of programming style, but a programming error resulting in not only a breach of security, but the loss of large amounts of data. Are you willing to accept these risks for the designer's 'freedom'?


    Usually it's neither designer nor programmer who has the last say in this, but a manager, salesperson or, ultimately, the customer.  Unfortunately, all of these tend to have little understanding of security and the benefits of standards, and instead get hung up on GUI details.
  • (cs) in reply to tehsuck
    tehsuck:
    1) Would this all have been avoided if they used HTTP Authentication? I know it's not entirely secure, but correct me if I'm wrong: robots can't view anything in a pw protected dir since they're not authenticated?

    HTTP Authentication would have helped, but no more than a cookie based method. The real problem here is the abuse of HTTP GET.
    Does anyone have any suggestions on validating form input. I am currently using a onClick="checkform();" type of javascript, and I realize this isn't ideal. Should I send all information via POST to a script that checks it and re-writes header data based on if it's cool or not?

    Validate on the client first, then revalidate on the server. Client-based validation makes your forms more usable, but server-based validation is essential for security. How you do it isn't important, just so long as you don't abuse HTTP.

    K.
  • (cs) in reply to notromda
    notromda:
    Anonymous:

    Give them some guidelines, and hard rules where they really are needed, but seriously if a designer can come up with a richer and more appealing interface that use links to submit form posts, there is no reason in the world they should be forced to dumb-down their design.

    Give me one instance where you think you're right, and I'll show you you're wrong.


    That's easy.  I need a picture and text together in one solid link.  The text needs to be able to be different languages, so making a solid image with every language is not acceptable.   For example, a big red X next to the word delete. 

    How do I solve it?  Using Ruby on Rails, it's pretty easy.   I use link_to_remote to do a javascript POST  action .  If the user has ajax capability, it updates the page dynamically, otherwise it redirects to a new page load.

    If the user doesn't have javascript, it triggers the same URL via GET, but instead gets a confirmation page with the data in a form and a regular submit button. (Which submits back to the same action as before)
     


    Throw up a small demo somewhere so I can be absolutely clear, and I'll see what I can do.

    K.
  • ren (unregistered) in reply to Omry Yadan

    lol

  • (cs)

    This WTF has made my day.

  • (cs) in reply to Keith Gaughan
    notromda:
    That's easy.  I need a picture and text together in one solid link.  The text needs to be able to be different languages, so making a solid image with every language is not acceptable.   For example, a big red X next to the word delete.

    <snip ajaxified hackaround>


    Well, if you thought about the problem a bit, the issue is that you're throwing away the correct solution as "not acceptable".  And no, I'm not suggesting that you get wizzy with the photoshoppery, what I'm suggesting is that you use the stuff that you've already done.

    I assume as you have to deal with multiple languages already, you are using rgettext, and you thus have messages.po and friends set up.  So, what you do is this:

    1: Install RMagick
    2: Generate and cache your various messages server side using RMagick's handy compositing tools

    Something like this:


    require 'RMagick'
    Module ImageCompositingHelper
      def render_link_image_href(which_action)
        language = @lang || 'en_EN'
        final_image = File.join(RAILS_ROOT, "public", "generated_images", language, "#{which_action}.png")
        unless File.exists? final_image
          path_to_image_to_composite = File.join(RAILS_ROOT, "hidden", "tags", "#{which_action}.png"
          string = _(which_action)
          # Do RMagick compose here and save the result to final_image ...
          # Don't forget to do a GC run here as RMagick is a bit naughty
          GC.start
        end
        # Now render the path to the created file as a url, and you're done
      end
    end



    Of course, if you're not happy with a single hit to the rendering engine on the first time you hit an action / language combination, you could use the same code (near enough) to do this for a selection of keywords as part of your localisation script.

    FFS.  Ajax.  what will these kids think of next?

    Simon
  • (cs) in reply to tufty

    Fucking forum software.  obviously all the &nbsp; looked good in my browser.  Grrrr.

    Simon
    <snip ajaxified="" hackaround=""></snip>

  • fgilcher (unregistered) in reply to Keith Gaughan
    Anonymous:
    Far me it from me to point out how utterly retarded it is to (ab)use JS like that to make a link submit a form, whether using the javascript: pseudoprotocol, or on an onclick event. Seriously, people, <font size="6"><font style="font-style: italic;" size="5">use a proper friggin' form button!</font><font size="3"> For the sake of a demo, here's a page on my wiki: http://talideon.com/wiki/?doc=WikiEtiquette. See the use edit version link at the bottom? That's no link, it's a form button, and it's a form button because clicking it changes the wiki's view state. See how it looks like the links to each side: CSS.

    Seriously, if you're going to do something, do it right and don't abuse the browser's other facilities just because it might seem easier. Don't fight the browser, use it as it's intended to be used. If you don't, you'll just end up with an app that little more than a mountain of hacks.
    </font></font>


    yes, shure. but tell me how to put a mouseover effect on that button in Internet-Explorer (any version up to and including 6.x) without using javascript. oh, wait, IE doesn't get the :hover right on anything but link elements. Hmm, problem - if the customer really want it, I'll explain the problems to him, but place an javascriptwhatever link in there, so they get the mouseover for their toy - in the end, it's them who pay my wages.

    However, I'd rather place a javascript for the mouseover effect ;)

  • (cs)

    You gotta love the "Just don't do that" solution from managment.

    They probably even blamed the client, making them think it was their fault.

  • Kiss me, I'm Polish (unregistered) in reply to fgilcher
    Anonymous:
    Anonymous:
    Far me it from me to point out how utterly retarded it is to (ab)use JS like that to make a link submit a form, whether using the javascript: pseudoprotocol, or on an onclick event. Seriously, people, <font size="6"><font style="font-style: italic;" size="5">use a proper friggin' form button!</font><font size="3"> For the sake of a demo, here's a page on my wiki: http://talideon.com/wiki/?doc=WikiEtiquette. See the use edit version link at the bottom? That's no link, it's a form button, and it's a form button because clicking it changes the wiki's view state. See how it looks like the links to each side: CSS.

    Seriously, if you're going to do something, do it right and don't abuse the browser's other facilities just because it might seem easier. Don't fight the browser, use it as it's intended to be used. If you don't, you'll just end up with an app that little more than a mountain of hacks.
    </font></font>


    yes, shure. but tell me how to put a mouseover effect on that button in Internet-Explorer (any version up to and including 6.x) without using javascript. oh, wait, IE doesn't get the :hover right on anything but link elements. Hmm, problem - if the customer really want it, I'll explain the problems to him, but place an javascriptwhatever link in there, so they get the mouseover for their toy - in the end, it's them who pay my wages.

    However, I'd rather place a javascript for the mouseover effect ;)


    The customer hires a web designer to design for him. If you can't manage to convince him that you're right, then you end up with your pride in your ass. It's you who's supposed to know what's right. Imagine driving lessons steering to the wrong side of the road just because the customer wants to. Show your customers w3c or some other stuff that says in large, friendly letters "Don't do javascript links". If you still can't convince them to do the Right Thing, quit the customer or the job. It's not worth damaging your nerves.
  • fgilcher (unregistered) in reply to Kiss me, I'm Polish
    Anonymous:
    Anonymous:
    Anonymous:
    Far me it from me to point out how utterly retarded it is to (ab)use JS like that to make a link submit a form, whether using the javascript: pseudoprotocol, or on an onclick event. Seriously, people, <font size="6"><font style="font-style: italic;" size="5">use a proper friggin' form button!</font><font size="3"> For the sake of a demo, here's a page on my wiki: http://talideon.com/wiki/?doc=WikiEtiquette. See the use edit version link at the bottom? That's no link, it's a form button, and it's a form button because clicking it changes the wiki's view state. See how it looks like the links to each side: CSS.

    Seriously, if you're going to do something, do it right and don't abuse the browser's other facilities just because it might seem easier. Don't fight the browser, use it as it's intended to be used. If you don't, you'll just end up with an app that little more than a mountain of hacks.
    </font></font>


    yes, shure. but tell me how to put a mouseover effect on that button in Internet-Explorer (any version up to and including 6.x) without using javascript. oh, wait, IE doesn't get the :hover right on anything but link elements. Hmm, problem - if the customer really want it, I'll explain the problems to him, but place an javascriptwhatever link in there, so they get the mouseover for their toy - in the end, it's them who pay my wages.

    However, I'd rather place a javascript for the mouseover effect ;)


    The customer hires a web designer to design for him. If you can't manage to convince him that you're right, then you end up with your pride in your ass. It's you who's supposed to know what's right. Imagine driving lessons steering to the wrong side of the road just because the customer wants to. Show your customers w3c or some other stuff that says in large, friendly letters "Don't do javascript links". If you still can't convince them to do the Right Thing, quit the customer or the job. It's not worth damaging your nerves.


    Well, I don't see a javascriptonclick() link as 'damaging my nerves'. I try to be standards compliant wherever possible and make my pages as accessible as possible, but if the customer decides that they prefer 'the wrong way' of using a javascript link and is aware that in turn, they'll loose some visitors, I'll place the javascript link because apart  from the above mentioned  side-effects, no harm is done. They pay me to design and develop an application for the they way _they_ want it to be. I make proposals and tell them what's right, but the last call is theirs.

    If the change request could jeopardize the safety of the application, that would be a different story.

    captcha: doom and enterprise. is this forum trying to tell me something?

  • BlenderStyle (unregistered)

    Same thing happened to me! I created a simple PHP program with a MySQL backend to keep notes for various things. I didn't really care if it wasn't secure so I didn't implement any authentication. I used an edit and delete link next to each entry for quick administration. That's when Google's spider came through and visited all my links. I'll never make that mistake again. Also, I've never relied on JavaScript for security.

  • Aspie (unregistered) in reply to NancyBoy
    NancyBoy:
    Hubert Farnsworth:
    your mom:
    what about links such as this?


    You know what? I've got noscript installed in Firefox. Usually, when I encounter submit links that do nothing, I even take the trouble of looking at the source code. Doesn't work because of javascript? There's an easy solution.

    1. click on that little cross on the right top of the window
    2. go to the competitor's website

    That easy.

    You're not missed. Seriously, if I were designing a site so that only malcontents with Asperger's were happy, I'd keep your comment in mind. Since no one else cares...

     

    You, NancyBoy, are rather bigoted to say such a thing, as well as ignorant.  I'd suggest you shutup while you're ahead.

  • (cs) in reply to NancyBoy
    NancyBoy:
    Hubert Farnsworth:
    your mom:
    what about links such as this?


    You know what? I've got noscript installed in Firefox. Usually, when I encounter submit links that do nothing, I even take the trouble of looking at the source code. Doesn't work because of javascript? There's an easy solution.

    1. click on that little cross on the right top of the window
    2. go to the competitor's website
    That easy.

    You're not missed.

    Seriously, if I were designing a site so that only malcontents with Asperger's were happy, I'd keep your comment in mind. Since no one else cares...



    I do not have Asperger's Syndrome.

    We do care.  We just do not usually make a fuss.  It just will not show up in your log that we can not be bothered to fight your Website.  Of course we are not missed.  It is very difficult to spot an absence.

    I am not under any obligation to use any particular Website.  I do have a sense of what I like, what I will put up with, and what I will not tolerate.  If a Website is difficult/awkward/intrusive/bothersome in any way, it is much easier to simply go to another.  If the other Website has what I want, I have no reason to ever come back to yours.

    Sincerely,

    Gene Wirchenko

  • (cs) in reply to Angstrom

    Angstrom:
    If I could slap you over the internet, I would.

    You, sir, are my hero.

    Not that I thought that he deserved such a put-down. I just liked the turn of phrase.

  • Jon (unregistered) in reply to notromda

    notromda:
    That's easy.  I need a picture and text together in one solid link.  The text needs to be able to be different languages, so making a solid image with every language is not acceptable.   For example, a big red X next to the word delete. 

    How do I solve it?
    I don't see any mention of buttons in your post. Is there a reason you can't use buttons? I'm going to use parentheses instead of angular brackets here, since blah blah forum software WTF.

    (form action="delete.foo?id=bar")(button type="submit")(img src="bigredx.png" alt="" /)Delete(/button)(/form)

  • (cs) in reply to Keith Gaughan
    Anonymous:

    I forgot IE doesn't support inherit, so sue me :-) It's fixed now, so check again. See what I mean now?

    I'm not saying it's an elixer, just that it's not used as well as it ought to be.

    K.


    Sweet. I'll shut up. Er... does this work in Safari as well?
  • grkvlt (unregistered) in reply to hack-o-matic
    Anonymous:
    Wow, I just learned something. I realize that I am opening myself up to much criticism by by posting this but I myself have created a few sites which contain pages such as DeleteClient.asp?id=123 where 123 is the client to delete. I always check a session variable to make sure they are logged in before doing the action, but sounds like that was a Very Bad Idea. The problem is how do I get the action to spawn via hyperlink where I can only pass values in the QueryString?

    by doing exactly the same as you are right now. i assume that the default behaviour of your application is to do nothing/error if there is no session data available, or no cookies set? if so, no problem, it's just not the "Right Way" but it's still secure.

  • (cs) in reply to tufty
    tufty:
    notromda:
    That's easy.  I need a picture and text together in one solid link.  The text needs to be able to be different languages, so making a solid image with every language is not acceptable.   For example, a big red X next to the word delete.

    <snip ajaxified="" hackaround="">


    ...

    1: Install RMagick
    2: Generate and cache your various messages server side using RMagick's handy compositing tools



    Yeah, I thought about that, but my skills with rmagick are not all that good.  

    What this debate is coming down to is a puristic vs pragmatic approach.   According to the old standards, a submit input or button is the only way to go for POST operations.   Well, technology advances, and I think the ajax way, despite the silly name, is the better way to solve this problem.   For those few of you who turn off javascript...  deal with it.
    </snip>
  • Brendan (unregistered)

    Next time I hope that guy includes a "Delete Retarded Programmer" link aswell.

    With that kind of skill, sounds like its not out of the scope of reality.

  • (cs) in reply to Gene Wirchenko

    Gene Wirchenko:
    We do care.  We just do not usually make a fuss.

    Good, because there aren't enough of you to matter.  Good luck with your noscripting!

  • (cs) in reply to NancyBoy
    NancyBoy:
    Gene Wirchenko:
    We do care.  We just do not usually make a fuss.

    Good, because there aren't enough of you to matter.  Good luck with your noscripting!

    I am so happy to hear that you are so rich you can afford to ignore potential customers.  Other people are unfortunate enough to have to care about all customers, not just the easy ones.

    Sincerely,

    Gene Wirchenko


  • (cs) in reply to d4ddyo
    d4ddyo:
    Anonymous:

    I forgot IE doesn't support inherit, so sue me :-) It's fixed now, so check again. See what I mean now?

    I'm not saying it's an elixer, just that it's not used as well as it ought to be.

    K.


    Sweet. I'll shut up. Er... does this work in Safari as well?


    Not a clue. I've no way to test it.

    K.
  • (cs) in reply to fgilcher
    Anonymous:
    Anonymous:
    Far me it from me to point out how utterly retarded it is to (ab)use JS like that to make a link submit a form, whether using the javascript: pseudoprotocol, or on an onclick event. Seriously, people, <font size="6"><font style="font-style: italic;" size="5">use a proper friggin' form button!</font><font size="3"> For the sake of a demo, here's a page on my wiki: http://talideon.com/wiki/?doc=WikiEtiquette. See the use edit version link at the bottom? That's no link, it's a form button, and it's a form button because clicking it changes the wiki's view state. See how it looks like the links to each side: CSS.

    Seriously, if you're going to do something, do it right and don't abuse the browser's other facilities just because it might seem easier. Don't fight the browser, use it as it's intended to be used. If you don't, you'll just end up with an app that little more than a mountain of hacks.
    </font></font>


    yes, shure. but tell me how to put a mouseover effect on that button in Internet-Explorer (any version up to and including 6.x) without using javascript. oh, wait, IE doesn't get the :hover right on anything but link elements. Hmm, problem - if the customer really want it, I'll explain the problems to him, but place an javascriptwhatever link in there, so they get the mouseover for their toy - in the end, it's them who pay my wages.

    However, I'd rather place a javascript for the mouseover effect ;)


    You can't because IE's :hover support is broken before IE7. If you really need to compensate for this brokenness, attaching handlers to the button's mouseover and mouseout events is ok. But you see, that's a bit of a strawman that has nothing whatsoever to do with my point. There's still no need to use links.

    If you want to argue with me, come up with a cogent one.

    K.
  • HR (unregistered) in reply to Keith Gaughan

    This is really a case of  "anal-retentive do-it-by-the-book-goddamit" vs. "let's give the user the best experience while keeping the code clean". It's obvious that when people use tools such as web accelerator one should prefer POST, however it is equally aparent that if you wish to have a certain look on your web page you might very well put yourself in a maintenance nightmare trying to make your buttons look like the ordinary links in all common browsers. I'd rather spend that time on testing the application or implementing some other functionality giving my customers a good application on time.

    It is also slightly amusing that it seems like the original idea behind having buttons for POSTs was to alert the user visually that something might acctually happen when you click that button, but this thread is mostly about how to make the user not knowing it.

  • (cs) in reply to HR
    Anonymous:
    This is really a case of  "anal-retentive do-it-by-the-book-goddamit" vs. "let's give the user the best experience while keeping the code clean". It's obvious that when people use tools such as web accelerator one should prefer POST,


    No, this isn't as you put it 'a case of  "anal-retentive do-it-by-the-book-goddamit" vs. "let's give the user the best experience while keeping the code clean"'. It's a case of "give the user the best experience without breaking the cornerstone of the web's scalability" vs. "who gives a damn, this kinda works and it looks right".

    Do you think HTTP would have GET and POST if it wasn't necessary? No, that'd be bad protocol design. Each satisfies differing constraints and implies different things about the response. HTTP GET is for getting things. That's why it's called GET and not CHANGE_STUFF or, um..., POST. This implies that GET is idempotent, so it's possible for its responses to be momentarily cached to spread load, which is important because it turns out that getting stuff is by far the most common thing people do on the web, so caching, even for a very short amount of time is a Good Thing and why it doesn't cause awful problems if somebody accidently double-clicks a link, and some pretty small servers that have been tuned properly can appear remotely to take loads that more powerful but untuned servers can't.

    POST implies non-idempotence; they always go to your server. For what POST does, this is also a Good Thing as it's far less common to modify stuff, but you want the network to do its best to move that request from you to the target host.

    It's no more possible to replace GET with POST than it is to replace POST with GET. That's like saying that you can do without protein and fat in your diet completely and just live off of carbohydrates. Of course, any dietician will tell you that while you can do that for a while, eventually such a diet will kill you. Using GET when you should be using POST, and vise versa, might not lead to the same extremes, but the former will lead to silent data loss of all kinds, and the latter will kill your server's scalability.

    however it is equally aparent that if you wish to have a certain look on your web page you might very well put yourself in a maintenance nightmare trying to make your buttons look like the ordinary links in all common browsers. I'd rather spend that time on testing the application or implementing some other functionality giving my customers a good application on time.


    If you do it properly, there's absolutely no reason why it should be a maintenance nightmare. That is, after all, the whole point of CSS: to keep a site's styling in one canonical place to ease maintenance. Apart from that, I agree with you: I prefer to focus on providing a good application on time, but part of that is about ensuring that it doesn't abuse fundamental properties of HTTP and, therefore, the web.

    It is also slightly amusing that it seems like the original idea behind having buttons for POSTs was to alert the user visually that something might acctually happen when you click that button, but this thread is mostly about how to make the user not knowing it.


    For me, it's been about two things: disabusing people of the idea that non-idempotent state change on HTTP GET is dumb idea--which is directly related to the post's topic--and disabusing people of the notion that using a javascript: link or the onclick event on a link to trigger a form post is a good idea, and that there are alternatives that work and work cleanly without sacrificing aesthetics.

    K.
  • Belcat (unregistered) in reply to kipthegreat

    That's funny, it's almost as bad as the original.  So if I want to hack your website all I have to do is add a cookie called "isLoggedOn" to my cookies?  Wow, easy!


  • An apprentice (unregistered) in reply to NancyBoy
    NancyBoy:

    Gene Wirchenko:
    We do care.  We just do not usually make a fuss.

    Good, because there aren't enough of you to matter.  Good luck with your noscripting!

    Please see Most Popular Downloads on Firefox extension page. Then think of all the corporate Explorers with Javascript turned off for external websites because of security reasons. Then calculate, how many visitors you might have lost.

    I strongly suggest that your site needs Javascript only for additional functionality. If your website gets unusable, people just go away, as Gene Wirchenko says, leaving you under the illusion that there are so few of them. Really, are you so crappy a designer to be incapable of adding simple href to your a tags?

  • bystander (unregistered) in reply to An apprentice
    Anonymous:
    Really, are you so crappy a designer to be incapable of adding simple href to your a tags?

    a element, or beginning tag of an a element.

  • captain damage (unregistered) in reply to Keith Gaughan

    Another reference:
    http://www.37signals.com/svn/archives2/the_google_web_accelerator_is_back_with_a_vengeance.php

  • ben (unregistered) in reply to Keith Gaughan

    Keith:
    Is the tag line on top of your site cached ?
    Or does my browser reload the whole freaky page just for the tag line ?

  • HR (unregistered) in reply to Keith Gaughan
    Keith Gaughan:

    is a Good Thing and why it doesn't cause awful problems if somebody accidently double-clicks a link, and some pretty small servers that have been tuned properly can appear remotely to take loads that more powerful but untuned servers can't.


    We're talking about replacing POST with GET, not the other way around. Get-requests that works like posts should of course have the apropriate cache-control set and thus, pages that can be cached will be cached, making your servers run with good performance and requests that can't be cached won't, just as before.

    Since you mention double-clicking I'm inclined to agree that a button might be a slightly better choice, when looking like a button, but how many sites have you seen that says "please only click once"? I've seen more than I can remeber. To a user there is no difference between a link or a button that looks like a link, except that the button refuses to open in a new tab, can have it's text copied and some other small annoyances that might ruin the user experience.


    If you do it properly, there's absolutely no reason why it should be a maintenance nightmare.


    No, of course it isn't... You haven't had to do lots of modifications to make it acctually work for everyone after you thought you were finished? Will your "hacks" work in the next version of browser foo? You don't know, and will constantly have to check your page against browsers to ensure it works, possibly tweek your css some more, since doing this kind of stuff with css isn't on the top of things that should work in a browser, unlike anchors.
  • Helge Jensen (unregistered) in reply to kipthegreat

    Ohhhhh. you nearly got me there :)

  • Charly (unregistered) in reply to ParkinT

    They have the money.

  • Matt (unregistered)

    Happened to a colleague of mine. He had written a CVS web interface for a project, and one day he woke up and all files had been removed... by the GoogleBot :-)

  • Anonymous (unregistered)

    That reminds me of CUPS's "print test page" button.

    Which is a GET link.

    I found once a CUPS system somewhere where the only things ever printed were test pages. Most of them, printed by googlebot.

  • koning_robot (unregistered) in reply to ben
    Anonymous:
    Keith:
    Is the tag line on top of your site cached ?
    Or does my browser reload the whole freaky page just for the tag line ?

    Why did this reply kill the discussion?
  • (cs) in reply to gwenhwyfaer
    gwenhwyfaer:
    Remember, it's not just me and my twisted preference for browsers that don't support JavaScript. What about users dependent on screen readers? Should blind people not be allowed to submit forms? (In a day and age where anti-discrimination legislation is springing up all over the place, this could turn into a legal issue too, before too long.)

    Too late, it's already a legal issue now. Cases have been brought (in the US) against many web companies for their lack of support for disabled and handicapped people. The ADA is a powerful piece of legislation. The short of it is that so-called "web designers" who fail to design to the proper standards are being criminally negligant in doing so, and leaving themselves open to lawsuits. It won't be too long before companies start to realize that they can be liable for not designing to proper standards... At least then they would have a legitimate defense to this sort of thing, in that designing to standards is the only real way to allow all people to have equal access to the content they're making available. That's the whole point of having standards.

    Remember kiddies, implementing to standards isn't just for fun, it's the law.

  • (cs) in reply to HR
    HR:
    We're talking about replacing POST with GET, not the other way around. Get-requests that works like posts should of course have the apropriate cache-control set and thus, pages that can be cached will be cached, making your servers run with good performance and requests that can't be cached won't, just as before.

    Assuming that your cache parameters are honored by the intervening servers, of course. POSTs simply cannot be cached by anything anywhere, whileGETs can be, they can just ask not to be. But asking and having it actually done are two different things.

    HR:
    Since you mention double-clicking I'm inclined to agree that a button might be a slightly better choice, when looking like a button, but how many sites have you seen that says "please only click once"? I've seen more than I can remeber.

    Yes, I've seen these a lot. Many now use javascript to disable the button after the first click, and I consider that usage perfectly acceptable since it is an addition, not actual necessary functionality. The server component still has to detect stupid users doing stupid things, like double clicking buttons.

    But that's sorta the whole point. Double-clicking links had damn well better be okay, *by definition*. That's what "idempotent" actually means. Double clicking buttons doesn't have to be okay, although it would be a good idea to detect it anyway.

    HR:
    To a user there is no difference between a link or a button that looks like a link, except that the button refuses to open in a new tab,

    Interesting point, since having "javascriptform.submit()" links in an anchor tag doesn't open in a new tab particularly well either. It usually gives you a javascript error on pages that are broken in this specific way.

    HR:
    Will your "hacks" work in the next version of browser foo? You don't know, and will constantly have to check your page against browsers to ensure it works, possibly tweek your css some more, since doing this kind of stuff with css isn't on the top of things that should work in a browser, unlike anchors.

    If you have to use any "hacks" that are anything but trivial little bug fix issues (most of those being for IE), then you horked up your initial design in the first place. Do back to the drawing board and do it properly next time.

  • nonidempotent (unregistered) in reply to Otto

    Ah, what joy this thread has been. In fact, I think a number of people who've posted to this thread deserve a huge WTF themselves.

    I've never seen so much misunderstanding associated with idempotency since I started programming twenty years ago. Anyone who's actually developed a proper distributed system will understand that idempotency has absolutely nothing to do with caching.

    An action is said to be idempotent if, no matter how many times you perform it, the action only occurs once. Thus, a form that is posted to, say, transfer money from one account to another can be idempotent if implemented properly, and non-idempotent if implemented incorrectly. How many poorly developed systems do you come across which say things like "please don't click this button more than once, no matter if it seems to be taking a long time, otherwise your credit card might be billed multiple times?"

    Similarly, killing a cat is idempotent (the cat can only die once). The on-going torture and punishment of arbitrary cat killers, however, should definitely be non-idempotent (IMHO the pain they receive should be repeated time after time after time).

    POST and GET operations can therefore both be idempotent, or both be non-idempotent. I would surely agree that GET operations should be idempotent, but please don't confuse that with their ability to be cached.

    But, of course, in the days of dynamic web applications, very few GET operations are idempotent (in terms of the results generated), because so many organisations feel the need to keep their site "alive" by changing the content of their pages continuously.

  • CalliArcale (unregistered) in reply to HR
    Anonymous:
    Since you mention double-clicking I'm inclined to agree that a button might be a slightly better choice, when looking like a button, but how many sites have you seen that says "please only click once"? I've seen more than I can remeber. To a user there is no difference between a link or a button that looks like a link, except that the button refuses to open in a new tab, can have it's text copied and some other small annoyances that might ruin the user experience.


    The phrase "user experience" is something that I find causes tremendous frustration.  I believe strongly in good, intuitive GUI design.  The user experience is important to me.  However, I've come to realize that very few people who use the phrase "user experience" care about anything else.

    Your user experience goes far beyond the GUI.  Your links, your buttons, your general site design are the most visible parts of the GUI (literally so) but they are not all of it.  Googlebot accidentally deleting your entire website will lead to an extremely bad user experience, so if you really and truly care about "user experience" and not just pretty GUIs, you will care about proper implementation of standards.  Remember, a pretty GUI will not save you if your site is pathetically slow, dangerously insecure, or produces behavior which an end user could not reasonably expect.

    The standards are not arbitrary lunacy dreamt up by sadistic software engineers or (god forbid) requirements engineers.  They exist for a reason, were created by experts, agreed upon by industry representatives, and have endured considerable real-world testing.  Furthermore, they define an essential contract between you and your clients.  You implement a standard so that your clients can have confidence in what the end product will do because that's what the standard says it will do.  Violating that standard should only be done when absolutely neccesary and with the deviation explicitly documented in your product's requirements spec, approved by your client.  (And odds are, if your client knows you're consciously violating a standard, they will not easily be made comfortable with that.  But it's better than them finding out later on.)  Even then, it should be avoided.  If you find an accidental violation of standards, you should document it as a bug and determine whether or not it is appropriate to fix it given the strictures of the contract (time, budget, other things to change/fix, etc) and with the understanding of your customer.  That is, if you want to have more customers later on.

    As far as maintainability goes, it'll be easier if you follow standards and avoid hacks.  Anytime you deviate from what you'd normally expect to do, make sure you document exactly where and why you did so lest you forget about it before you have to make changes to the product months or even years down the road.  You can also take pity on any third party who might be stuck maintaining your code later on and explain why you felt it neccesary to do it this non-standard way, because you can't expect somebody else to understand your design decisions if they aren't standard.
  • Dan K. (unregistered) in reply to Keith Gaughan

    Um, yeah. The story is frightening enough, but what's doubly frightening is that the writer didn't zero in on the true problem. This ain't google's fault, and it's got nothing to do with cookies.

  • (cs) in reply to Keith Gaughan
    Anonymous:
    The true muppetry of this is that the idiots who implemented it used GET requests (and get is meant to be side-effect free and idempotent) to implement a destructive actions.


    Thank you so much for actually using the word idempotent.  I don't know how many people use this word (correctly or incorrectly) but here it is exactly what I've been trying to convince people of for years.  For example: "make foo" and then "make foo" should _not_ build foo twice -- the second make should do nothing :-)
  • http://thedailywtf.com/forums/AddPost.aspx?PostID=66047&amp;Quot (unregistered) in reply to kipthegreat

    Unfortunately, the script is banned, it's made illigal!

  • MrBester (unregistered) in reply to Keith Gaughan

    Write the page properly in the first instance and if the dumb client wants javascripty links, then use JavaScript on DOM load to rewrite all your nice stuff into their stupid crap ONLY if you can't persuade them otherwise (probably because they've seen too many .aspx pages that do exactly that, this forum being a case in point). Page remains accessible, so you don't get your arse handed to you by compliancy lawyers, which is exactly why I never use the native SystemWeb.UI.Page but something that actually works properly.

    Token extra WTF: Currently at over 1300 errors in Firebug whilst making up this post, and 2 captchas.

  • Toni Ylisirniö (unregistered) in reply to Keith Gaughan
    Anonymous:
    Seriously, people, <font size="6"><font style="font-style: italic;" size="5">use a proper friggin' form button!</font><font size="3"> For the sake of a demo, here's a page on my wiki: http://talideon.com/wiki/?doc=WikiEtiquette. See the use edit version link at the bottom? That's no link, it's a form button, and it's a form button because clicking it changes the wiki's view state. See how it looks like the links to each side: CSS.</font></font>


    It looks exactly unlike the links on each side. Opera has grey background box, you can't select the text, you can't drag the link, the text moves as if it was a button. Safari shows a button, period. Camino shows a button, period.

    Only firefox shows it visually like the links near it. And even there it behaves nothing like the links. You don't get link context menu  if you right/control click it to open it in new window or tab, and you can't middle click to open it in new tab. And you can't drag the link in FF either or select the text.

    So, 1 out of 4 browsers on Mac OSX shows it with any resemblence to links, and that's the least Mac-like of the bunch even.

    Here's a screenshot
  • Mushuweasel (unregistered)

    This reminds me of when the Texas DMV had their database (their WHOLE database) online, searchable, and protected by ... wait for it ... javascript authentication.  Turn off js in your browser, and suddenly you had access to home addresses and other personal info for anyone who had the audacity to drive in Texas.  I found a friend from cub scouts who had moved to Abilene.  A friend of mine still has contact info for many a Bush family member lying around somewhere...  Sigh.

  • (cs)

    I myself is SEO but I was not knowing till date that spider can be such a notorious thing. Though frequent crawling has some bad effects but this is something unimaginable damage to the CMS site.

  • anonymous (unregistered) in reply to loneprogrammer
    loneprogrammer:
    No, that violates the HTTP standard!
    Quote RFC 2616:
    13.9 Side Effects of GET and HEAD

       Unless the origin server explicitly prohibits the caching of their
       responses, the application of GET and HEAD methods to any resources
       SHOULD NOT have side effects that would lead to erroneous behavior if
       these responses are taken from a cache.

    Please read RFC 2119 (SHOULD and MUST).

    It might violate the spirit of the RFC, but it doesn't violate it. It's just an instance of WTF and failure to RTFM/RT(RFC).

    Also note that even this quotation has a caveat about headers under which it could be OK to have side effects. No one has mentioned whether the instances mentioned had such things.

    That said, having worked on a spider that got trapped in a calendar maze, I hate calendars. Oh, and I hate wikis too, since in development it would get stuck there too. In the end, good spider(m developer)s develop an algorithm for deciding that they aren't getting anything from following links (down whatever maze you provide) and move on with life.

    Note that unfortunately the spider in question was required to operate buttons too, not just links -- It had to be able to submit posts and run JavaScript. It would also carry out authentication, but it was generally configured to be given tokens by a real person and was designed not to wander too far afield. I don't remember what warnings were included in the documentation/user guide, but the product was marketed for testing web applications.

    All in all, I hate web applications, and I hope people have sympathy for me (not that I care). Spiders and anything from Google, OTOH, I like and sympathize with.

Leave a comment on “The Spider of Doom”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article