Base elements cause text selection problems in IE

I recently ran into one of the most bizarre Internet Explorer bugs yet. I was asking a colleague for help with a completely different IE problem when he said “Did you know that you can’t select any text on this site in IE?”. A quick test in IE confirmed this. Actually the problem wasn’t that text was completely unselectable, just that it was very difficult and tricky to select.

Text selection problems aren’t too unusual to run into with IE when you use absolute positioning, but in this case there wasn’t any of that going on, so I didn’t really know where to look for a fix. Since it took me a while to find the solution I thought I’d share it in case there are others banging their heads against this one.

It’s quite easy to fix really: just remove the base element from the document. You are probably wondering what on earth a base element was doing in the code, and so am I. I sure didn’t put it there, but for some reason the CMS we’re using did.

We’re using the latest version of EPiServer for this site, and it has a “search engine-friendly Web address” feature that seems great at first. I was really looking forward to finally being able to stop EPiServer from exposing page template names and adding a bunch of cryptic numbers to the end of URLs. But unfortunately the feature is implemented in a very strange way. I don’t know whether ASP.Net, Microsoft IIS or developer ignorance is to blame, but there has to be a better way.

For some reason the search engine-friendly URL feature requires the addition of a base element in combination with a JavaScript that changes the action attribute of the search form for the built-in search engine to work. That obviously breaks the search function for people without JavaScript, which is completely unacceptable. And, as I now have found out, when a base element is used in a document containing text in floated elements, a IE bug that causes text to become more or less impossible to select is triggered.

The solution, as I mentioned earlier, is to get rid of the base element. For sites based on EPiServer that means either turning off the search engine-friendly URL feature or do what we did: do a bit of server side regexp filtering and on-the-fly rewriting to fix the search form’s action attribute in an accessible way, with no need for either base elements or ugly JavaScript hacks.

I’m tired of us client-side developers always having to clean up the mess caused by back-end developers who think they know front-end coding.

Posted on August 8, 2006 in CSS

Comments

  1. August 8, 2006 by Nathan Rutman

    While we’re on the topic of text selection oddities, did you know that in Thunderbird 1.5.0.5 and Firefox 2.0 Beta 1 (and thus perhaps in Firefox 1.5.x — all Windows builds), when you click anywhere to the left of the main content area, it selects everything contained in the main area and the sidebar? Talk about strange, but also very annoying.

    Just thought I’d bring it up. -Nate

  2. August 8, 2006 by Johan

    We’re using the latest version of EPiServer for this site, and it has a “search engine-friendly Web address” feature that seems great at first. I was really looking forward to finally being able to stop EPiServer from exposing page template names and adding a bunch of cryptic numbers to the end of URLs. But unfortunately the feature is implemented in a very strange way. I don’t know whether ASP.Net, Microsoft IIS or developer ignorance is to blame, but there has to be a better way.

    you can rewrite URLs to searchengine-friendly URLS in ASP.NET like this:

    Search Engine Friendly URLs using ASP.NET (C#.NET)

  3. August 8, 2006 by Johan

    Again (link got cut off)

    you can rewrite URLs to searchengine-friendly URLS in ASP.NET like this:

    link to article

  4. That’s really great to know. I hadn’t heard of this bug before, and we’re currently using code on a few of our sites — time to take care of that issue.

  5. I have the same problems that Nate does on Mac in Firefox 1.5.x, so it’s not just an isolated thing.

    I also have no idea what might be causing it — it’s very strange.

  6. August 8, 2006 by Roger Johansson (Author comment)

    I’m aware of the text selection thingy Firefox is doing, and I’m looking at it.

    Johan: Thanks for that link, it may come in handy.

  7. August 8, 2006 by Roger Johansson (Author comment)

    Ok, Firefox should now behave. It was caused by an “overflow:hidden” declaration on the outermost div.

  8. Does it occur in IE7 too? We have to all put $ and create a huge marketing campaign for alternative browser. IE needs to go away.

  9. Just to mention, there are more problems with selecting text and anything in IE having something to deal with either absolute positioning with/or transparent png’s hack in IE6. You can try fixing it with

    element { position:relative; z-index:1; }

    (barely found it somewhere under Brutal CSS Issues)

  10. Sorin-

    Who would we bash if they went away?

    I think my biggest gripe is a huge use of span and br tags. It can be horrific diving into the backend code! I think that is one of the biggest plusses of Ruby on Rails over other languages. You still have to edit .rhtml files sometimes, but I love how the templates are so explicitly separate from the application code.

  11. Roger, I know someone who removed that bug without removing base element.

    Here’s polish text, and quick summary in english: It affects only elements with position: relative and disables (or makes it very hard to do) text selection. Solution? Just put at the end of this tag. :-)

  12. „Just put </base>”, I mean

  13. August 8, 2006 by Chris

    We’ve had similar problems. We solved them by using a full base tag (<base></base>) instead of the short version (<base />).

  14. I’m tired of us client-side developers always having to clean up the mess caused by back-end developers who think they know front-end coding.

    Boy am I glad someone has actually said it. I am having problems with these issues with programers since forever.

  15. August 9, 2006 by zcorpan

    It seems like the BODY element is both a child of the BASE element and the HTML element in IE (i.e., the DOM is not a tree, as usual), unless you use the invalid </base> tag.

  16. It stops being invalid when you put it in conditional comment, like the site I linked to says. :-)

  17. August 9, 2006 by Chris

    I’m tired of us client-side developers always having to clean up the mess caused by back-end developers who think they know front-end coding.

    Amd there are back-end developers that are tired of dealing with some of the quirky markup they get from the client-side developers. Which is why I think the better developers in general know at least the basics of whichever one they don’t normally practice.

  18. Chris and Riddle are comment is correct.

    The reason for the bug is Internet Explorer does not even attempt to render XHTML, even with a valid DOCTYPE. IE’s rendering engine is smart enough to recognize some elements as not requiring closing elements, such as img, br, meta, and link, but base is not one of them. I am pretty sure that this is fixed in IE7 (or at least my I never saw this bug in it when I looked at my site, even before I fixed this).

    Truth to tell, I didn’t even know that this fixed the bug in IE until I saw your post and realized I had already applied the fix.

  19. That’s very interesting and probably explains a text selection issue I’ve been having on an admin page of a particular site.

    Thanks for the tip-off.

  20. Actually, we have the same IE bug without any base tags. Haven’t looked into it, though. Interestingly enough, when I coded the templates I never encountered it so it may be related to CSS coding?

    Thanks for bringing this up, though.

  21. August 9, 2006 by FlorentG

    An article about the element was posted on IEBlog a year ago : All your are belong to us

    the BASE element when defined in the HEAD element would end up being the container for the BODY tag

    It is now fixed in IE7…

  22. Okay, now that’s really weird. Is there a reason why IE composes the DOM tree this way?

  23. August 9, 2006 by Gayforck

    I’m probably on the wrong site saying this but, like .. do you really want to chase stupid bugs all your days? I know it’s only a cute anecdote, but doesn’t “to hell with bad browsers” apply here? IE is buggy with empty elements. Luckily, in this case, there’s a not-so-inelegant workaround. Fix it / refuse .. choose and move on.

  24. This is a known problem with IE. In fact, months ago I fixed it on the thousands of pages on the Mass.gov portal. Amazing how such a seemingly small problem can cause havoc when spread across many pages.

  25. I use <base> a lot because I use IBM Domino. Using <base> allows me to have the page know where all the elements and resources are located.

    I was wondering why on my site where I have an XHTML doc type I could select text but on a customer site where because of the CMS I ending using a 4.01 strict doc type, I could not select text in IE. I’ve added an IE conditional comment to add </base> and now I can select text. Thank you.

  26. I only scanned the post, I entirely skipped the comments, and I’m too lazy to test anything right now, but: I remember similar problems writing GMX’s prototype, and - I’m not sure anymore since it’s two years ago now - it can probably be fixed by writing “<base></base>” instead of “<base />”. Try and celebrate/blame the lazy man in front of this very computer.

  27. Thanks for clearing that out, Roger! I’ve noticed the same thing on a site we were developing, where the only difference in markup between the prototype and the production version was a base element. I suspected it had something to do with that, but it felt way to far-fetched… The CMS in question was not EPiServer, but Livelink/Obtree. Getting rid of the base element is hopefully the way to go there as well, can’t see any reason whatsoever for its existence.

  28. August 10, 2006 by Anonymous

    I’m tired of us client-side developers always having to clean up the mess caused by back-end developers who think they know front-end coding.

    Tell me about! In the past, I’ve worked in environments where I’ve had to integrate client supplied XHTML 1.0 templates with non-validating HTML 4 back-end generated content, and then had to explain why the required field * can’t be orange to match the rest of their site and brand simply becasue back-end developers had decided that all clients will want red, whilst still pimping the joy of the system they’ve just bought into.

    I’ve even, on one system, had to insert worthless JavaScript before the DOCTYPE on some pages to break them in the same way as the other pages in the system, the one’s that the back-end developers have inserted JavaScript before the DOCTYPE.

    What’s that all about?!

  29. This is an important finding. Tho we should try to remind anyone interested in accessibility to use alternative browsers. Text-selection problems? Use OpeFire. Can’t select text in absolute positioned element? Use OpeFire. Still can’t, or hate that green background? Disable author styles. People should be reminded about these alternatives. Of course, where possible ;)

  30. Back end devs that dont understand the principle of good web design and “web designers” that design by dragging things around in Dreamweaver should be rounded up and shot ;)

    Tapestry also has a nice separation of application logic and html templates, the upcoming version 4.1 will include support for AJAX as well.

  31. I run into this bug quite often. As I remember “body { position: relative; }” can fix this one :)

  32. Aloyzas… thanks for that short but effective solution. It solved my problem immediately… I don’t really understand why but I’m happy it did the trick. Very much appreciated!

  33. Roger,

    If you’re thinking of the bug I’m thinking of, it’s not always just the existence of element.

    Positioned elements via CSS are often at fault too, though I can’t say at what point. In any case, I came across this javascript workaround (ok fine, it’s a hack) that I’m not even sure why it works, but it do.

    function fixIEselectBug() {
    document.body.style.height = document.documentElement.scrollHeight + ‘px’;
    }

    addLoadEvent(fixIEselectBug); //or your favorite add load event script.

    There are of course variations of this you can do, not the prettiest of which is add it just before the tag or tacked to onload attribute of tag.

    Additionally, I would modify it to only run on IE, e.g conditional comments, objection detection, etc.

  34. Useful article! I hope IE7 fix this problems! Thanks

  35. Amazing, i just tried with position attribute making it relative..and it worked… can’t select in absolute positioned element…..

  36. Removing overflow:hidden fixed the problem for me in IE7. Thanks Roger Johansson - I’ve been trying to suss that out for days!

  37. fix for this IE6 bug: BASE element becomes parent for all following tags if it is not closed with </base>

    function fixIEBaseTagBug() {
        if (/*test for IE6*/) {
            var bases = document.getElementsByTagName('BASE');
            if (bases.length) {
                if(bases[0].innerHTML != '') {
                    //http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/reference/objects/base.asp
                    var theHeadNode = document.getElementsByTagName("head")[0];
                    var newBase = document.createElement('BASE');
                    newBase.href = bases[0].href;
                    bases[0].removeNode();
                    theHeadNode.insertBefore(newBase, theHeadNode.firstChild);
                }
            }
        }
    };
    

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.