WebForm Gripe - Getting LinkButton to work without Javascript.

WebForms is a sort of love/hate thing for me. There are some things I love about WebForms and then there's quite a few things that really cause me a lot of pain. Sadly, the ones that cause me a lot of pain are the ones that stand out. I might turn these into a little series - depending on how many of these gripes show up and how many I can remember! Most of these gripes are probably me just not understanding WebForms correctly, I'm willing to learn so any pointers in the right direction would be good.

LinkButton or Button

The first one that I'm going to write about is the LinkButton control. For the most part it's a nice control, which allows a method to be called when a normal anchor link has been clicked. The problem occurs when the method is only called via a Javascript PostBack method in the href attribute. What this does is stop people who do not have Javascript running on their browser (for whatever reason that may be) from using the site.

There's always the argument of 'Why not use a Button control instead of a LinkButton control?' but the truth is a anchor link is much more customisable than a Button field when it comes to CSS or putting content inside of it.

Why should you care?

The reason you should care is that when you have, say, 500,000 people visit your site in a month and you left a LinkButton control as the main submit button for a contact form, if only 0.5% of those people don't have Javascript, then that's potentially 2,500 extra people missing out on submitting their information. It'd be nice to have a real study to show what percentage of people use Javascript but I don't have that, so I'd rather make a site work for everyone and not worry about people having Javascript than have something which only works with Javascript and potentially stop the website from functioning correctly for those people without Javascript.

How do we fix this problem?

The way that I have solved the problem of the LinkButton control is to use the built in noscript tags - which gets rendered when Javascript isn't avaliable. The problem with just using this straight in the code is that you can't have ASP.NET code inside of Javascript tags. One solution by Alex Papadimoulis was to use a control to render the server side code and then display the output with Javascript document.write() methods. Although the control is not perfect, it works pretty well to render out LinkButtons when needed and allows an alternative control, such as the Button control, when Javascript is not avaliable. Although the Button control won't be styled as nice, at least the functionality will still work (just don't show the designers what it looks like without Javascript!). 

The code for this control can be found over on Alex Papadimoulis' blog here - http://weblogs.asp.net/alex_papadimoulis/a...noscript.aspx

If anyone has a better solution then it'd be fantastic to hear about it,



  • This is an issue that bugs me as well. One thing that might be nice is if, instead of using the href attribute to do the JavaScript postback, it used the onclick attribute and the href could have the hosting page's URL with the command name and argumnets as query string parameters.

    Doing this would require overriding the LinkButton's Render method or creating a control adapter, plus playing nicely with any other onclick handlers that the LinkButton might have defined. Tricky.

  • I had this same gripe a few years back (when we had concerns with people on non JS enabled browsers using our ASP.NET apps). The solution I came up with back then was to use CSS on the buttons like so:

    background-color: transparent;
    border-style: none;
    color: #0033FF;
    cursor: pointer;
    font-family: Verdana,Arial,Helvetica,sans-serif;
    font-size: 12px;
    text-align: left;
    text-decoration: underline;


  • Add display:table-cell; to the CSS to fix the underline bug in Firefox

  • Good post! Glad to see web developers who are concerned about accessibility issues like this link button issue.

    In response to this comment:
    "instead of using the href attribute to do the JavaScript postback, it used the onclick attribute and the href could have the hosting page's URL with the command name and argumnets as query string parameters"

    The above idea would be bad if you have sensitive data in the form that you are trying to protect with SSL. In this case you really want a form post, not a link which makes a get request. If you build a link with query string params all your data is exposed in the url and is not encrypted even if using SSL. So be careful of using something like this even for a fallback.



  • Interesting - a big failing of many ASP.NET controls is that they require JavaScript to function.

  • @Joe Audette, i have never heard such rubbish. If you know anything about SSL you would know that the entire transport stream in encrypted, that includes the URL and headers (inc cookies), everything! Passing 'sensitive' data in the URL is perfectly fine, if you have questions about it being seen there, then maybe you should question why are you sending sensitive data to the browser in the first place.

Comments have been disabled for this content.