By default, in all major browsers, when you hover your mouse over text on a web page, the cursor changes from the regular arrow (the “default” cursor) to a “text” cursor. You can see this demonstrated in the GIF below or by simply testing it out on just about any web page:
To be more precise, the “default” cursor is not technically required by the spec to be the default. The initial value of the cursor property is actually “auto”, meaning that, as the spec says, “the UA determines the cursor to display based on the current context.”
When defining the “text” value for the cursor property, the spec explains: “Indicates text that may be selected. Often rendered as a vertical I-beam.”
But, as you probably know, this can be overridden in CSS, so you can display whatever cursor you want, any time you want. Notice, for example, on SitePoint that the CSS is overriding the behaviour on plain text:
I can’t think of another site at the moment that does this no-text-cursor thing on text. I remember when A List Apart was redesigned, they had originally done the same thing that SitePoint is now doing, using the default cursor on text, but that’s been changed back to the default behaviour.
What’s the Correct Behaviour?
If you go by the spec, the “text” cursor (the vertical I-beam) is the correct one to use. And if you go by what people are accustomed to, then you’d also have to go with the “text” cursor.
I think at this stage there would be no point in trying to change the way browsers and developers handle this, especially since all browsers do this by default, thus making it easy to have the same behaviour basically everywhere — even if it is the wrong behaviour.
But I can’t help but think: Doesn’t this go against the behaviour in native apps?
Here’s what happens in every browser when you move your cursor to the address bar:
This happens, not because it’s text in the address bar, but because it’s editable text. What about elsewhere in Chrome, like in the Chrome settings page:
Notice that Chrome’s settings page (which is just a web page, within which you can inspect elements and view source) they’ve overridden the default behaviour to use the “default” cursor when the cursor is hovered over text.
They probably do this to keep the settings page as “native” as possible, even though it’s still just a web page. The user can therefore see that the text on that page is not editable, but the text in the search box is.
This is generally the pattern with native apps: Editable text uses the vertical I-beam cursor while regular, non-editable text uses the default arrow.
Conclusion
I don’t know the history of why browsers use the “text” cursor on non-editable text. Some websites, like SitePoint, have recognized that maybe it would be better to go with the native experience in this regard.
On any web page, I think it makes more sense if the text cursor is reserved for editable elements like textarea, input, and even elements with the contenteditable attribute.
What do you think? Have browser been doing this wrong all along? I don’t think we can do anything to change this, but I suppose if we got to the point where all in-use browsers auto-updated, the vendors could agree to use the more intuitive native behaviour in this regard.
Oh and sorry for all the animated cursors. I’m sure that wasn’t annoying at all. :)
For me the I-beam also tells me that I can select the text and thus copy and paste it. Selecting text with an arrow just feels weird and less accurate. But maybe that’s only because I’m not used to it.
I agree – text cursors are for selecting text, not just an editing aid.
There should be I-beam cursor on every selectable content-text. For example I should know I can select and copy text from Wikipedia, so there should be I-beam cursor there.
The whole point of the text cursor is to allow you to select text easily.
So this is not about whether content is editable or not. You may want to select non-editable text. So I’m afraid the points you’ve raised are incorrect.
See my comment below.
Also, I don’t really agree that “the whole point” is for selectable text, I think it’s for both.
No, the whole idea behind the I-beam is to allow you to select text easily, and editable fields just happen to be selectable by default and therefore use the I-beam. It is NOT used to indicate tha the text is editable, that is not the idea behind it, it’s just a consequence of the fact that editable text is also selectable. You’ve even mentioned the definition of the
textcursor yourself: “Indicates text that may be selected“. That’s the only reason.What I’m saying is that the message that you’re trying to convey in your article is based on an invalid assumption, but it’s not a bad thing to be wrong every now and again. Keep learning and posting, it’s a nice blog.
Yes, I understand what you’re saying, and I definitely was wrong to point out the native behaviour. So, yes, that was a mistake, and I’ve added a comment about that in my article.
But not everyone agrees with the spec’s assumption that “selectable text” should be indicated via the I-beam. Google Chrome, for example, doesn’t (as I showed in the article), and SitePoint’s developers also felt this could be changed.
I guess my point is: Editable text always uses the I-beam, whereas selectable text does not. So I guess in some cases it’s a matter of taste, even though we’ve grown accustomed to (as you’re saying) the assumption that selectable text should use the I-beam.
I think it’s fine to use the arrow for selectable text, but not everyone agrees, so that’s kind of the point I as trying to bring up, but it was clouded by my poor example in using the native experience. :)
Perhaps we would have to clarify which text is “selectable”.
From my experience selectable text is content. UI elements and complementary UI text (e.g. messages, UI explanations) don’t need to be selectable (at least this is the distinction made in most interface design literature). I guess when it comes to long UI text, as per your Chrome example, it becomes less clear whether it is “content” or “complementary text”. To me that’s not “content” per say and doesn’t need to be selectable.
I think you’ve raised many valid points, the main one being (I’ll be paraphrasing) that perhaps not all text on one’s website should be selectable (i.e. using the I-beam pointer). I’m sure that when you choose the areas where the I-beam appears cleverly, you can improve the user experience. Thanks for the article.
Personally: I use “default” arrow cursor everywhere except editable fields but I would accept the “select text” argument for a website (not for a webapp).
Native apps use I-beam cursor on every text that is selectable, not only on what is editable. See: PDF readers. So, You point is entirely invalid.
Yes, you’re right, so that part about the native apps is not quite valid, as you pointed out. However, IIRC, PDF readers were not always like that. I distinctly remember PDF (at least on Windows) using the arrow cursor for some time, even on editable text. Also, a document reader is different from say a multi-window UI where there could be various pieces of text that are selectable (like in the Chrome settings).
And I don’t think it’s 100% universal that all selectable text in native apps uses the I-beam cursor.
But definitely a good point that I should have mentioned. I’ll see about making an adjustment or addition to the article later on.
I guess my main point here should have been: Should various UI features use the arrow cursor even when the text is selectable?
Thinking about PDF readers, which also show the text cursor for non-editable content, I think that it may have more to do with a “content vs UI” distinction.
The thinking being:
* UI is there to inform the user, but by itself is not really important;
* Content is the thing that the user is interested in. If the content is text, then the user may be interested in selecting it.
For example, I have Outlook 2010 opened right now with an email, and it shows this text in the header:
Date: Wed, March 19th 2014 17:36
The “Date:” part shows a regular arrow cursor on hover and cannot be selected, while the “Wed, March 19th 2014 17:36” shows an I-beam on hover and can be selected.
Personally, I find myself constantly annoyed by the fact that non-content elements, such as button labels and header logos, are selectable on websites. It makes the web feel kludgy for the reasons you describe in your article. On the other hand, I think it’s fine for content areas to be selectable, and I mostly agree with the other commenters that if an area of text is selectable, it should probably have the selection cursor. (For the most part, the kind of text you see in native apps is of the non-content variety — and content areas, such as help pages, are generally selectable.)
I remember that old Opera (before Blink) used to have the
defaultcursor on a text in version … 9 or 10, but then they switched it totextand if I remember correctly the reason was something like “to make the looks consistent with other browsers”Having a text cursor in non-editable text would be just confusing. After all, people are already trained to see the cursor as signifying an area that can be edited. That will only mislead people and they may even resent the website developer for it.
Thanks for the sharing this information.
This is very useful. I’ll keep remember about that. Thank you for sharing!
It’s only very recently that I’ve seen a small number of websites changing the default cursor away from the Ibeam over text. It’s so disconcerting that I just wrote a Stylish script to override it when it happens:
body, p {cursor:auto;}
I beam cursor should be for editable text. Though personally wouldn’t mind a different cursor for non-editable text. Good post.
I think there should be an I beam cursor when I see text with just an arrow over it I assume that the text is an image.
Having a text cursor in non-editable text would be just confusing. I assume that text is an image.
Nice article, I really enjoyed the animations as well.
There should be I-beam cursor on every selectable content-text. For example I should know I can select and copy text from Wikipedia, so there should be I-beam cursor there.
Many thanks for that piece of informatio
Is this the only discussion of this topic over the last seven years? It seems to me that there really should be some way to distinguish selectable text from editable text from the cursor. I-beam for selectable text is fine, but couldn’t we have something else for editable?