Not exactly a new issue but an empty ASP.NET ImageUrl tripped us up today. In this case there were no visible symptoms but two requests were coming through when Fiddlering the page view: the first initiated by the user and the second initiated by the page itself towards the end of the trace. In development with a debugger attached, this was manifest with Page_Load, CreateChildControls, etc being called twice for no obvious reason.
Because I initially thought I introduced the problem with the control I was working on, I first attempted to convince ASP.NET CreateChildControls was complete; I did so by clearing the Controls collection before unleashing my own code and setting the ChildControlsCreated property true once done. Neither of these tricks had any affect and the Fiddler trace had me convinced something beyond the ASP.NET pipeline and IIS had to be at fault.
That turned out to be the case but ASP.NET was still to blame ;-)
Specifically, we were adding a server-side ASP.NET image control but not initialising its ImageUrl property; the image src was later being set by jQuery at runtime on the client side. As mentioned, there were no visible symptoms of the double request: the image src was set as expected by jQuery and everything appeared okay on the surface. The IE dev toolbar also showed image src as being correctly set and there were no 404s in the mix.
It wasn't until we looked at the raw HTML that our ever-faithful admin extraordinaire noticed the empty src="" attribute. Removing the attribute removed the problem so I can only conclude IE is helpful enough to attempt to interpret a request for an empty image as a request for the parent directory of the current page while parsing the HTML before any Javascript runs. Thanks again, IE!
Notably this problem wasn't reproducible in Firefox or Chrome.
To fix the problem, we first set a default value for the ImageUrl property but that left me feeling dirty since it was still resulting in an unnecessary request. When I realised the server-side Image tag wasn't actually being used for anything server-side anyway, I replaced it with a boring old HTML img tag with no src. Microsoft has other, equally lame workarounds for this if you're interested; note they also don't plan to fix this bug.
I assume you are loading images later for performance. However, serving an image without a SRC attribute is invalid, as both SRC and ALT are required. Also, by serving empty SRC attributes, you are not following best practices in terms of progressive enhancement. You are essentially blocking image to all users with javascript disabled (which includes some screen readers and most bots)... which is not ideal.
ReplyDeleteA better, but less than ideal fix is to use a blank image or placeholder image. This results in only 1 request that can be cached on the client on the first page view.
A even better, but still less than ideal solution is to wrap your images in a NOSCRIPT tag, and then using javascript (jQuery), you can remove the NOSCRIPT tags... leaving behind the actual content of the NOSCRIPT. This would be indexable, accessible, and gracefully degrade when javascript is disabled.
Hi Ryan,
ReplyDeleteSome good thoughts and an interesting use of NOSCRIPT.
The majority of the site in question is probably invalid so it's not something I worry about very often but a valid point nonetheless. In terms of JS support, we've made that call based on the percentage of visitors with JS *enabled* (99%+). The accessibility issue bothers me but I'm not sure having an empty image would address that.
Btw, this image is is getting set client-side for functional reasons, not for performance (it's a weather forecast icon which may change as the user changes the current town selection). I did consider setting a default image (eg. sunny) but decided not to due to the possibility of one more unnecessary request on top of the 90+ requests the homepage already makes... we've recently changed this control to use a sprite so I may revisit that decision.