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.
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
input, and even elements with the
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. :)