Re: Title attribute and css selectors

On Mar 16, 2008, at 9:41 AM, David Woolley wrote:

>
> Brad Kemper wrote:
>>> out what the browser's relevant user agent style sheet said and  
>>> put in appropriate overrides for that, or you would need to  
>>> essentially completely redefine that fragment.  The latter is  
>>> particularly undesirable because it may be completely  
>>> inconsistent with the user's browser's way of handling title.
>> Undesirable? So? Authors have the power to control what text, if  
>> any, is used in the title attribute, or can leave it blank and  
>> generate pseudo-tooltips of their own using some other means. It  
>> may be undesirable for you, but fortunately authors do not need to  
>> consult you before implementing their choices.
>
> I know you don't believe in the principle of following platform  
> user interface guidelines,

Its not a matter of whether or not I am going to create a design that  
you like, its about whether or not I will be able to make design  
decisions on this bit of UI that are commensurate with the sort of  
design decisions I can make (to a degree, depending on UA) with other  
UI elements such as buttons, form fields, etc.

When I design a page, I am balancing many different considerations  
with each design choice, and UI familiarity is one of those  
considerations. If I assign a background color (or image) to a  
button, for instance, I am balancing the desire for it to be  
recognized as a UI button against other considerations, such as how  
well it fits in or stands out from the page design in general, how  
well it fits in with various visual "brands" (an OS brand, a "Web  
2.0" brand, a company brand, etc.), how it affects legibility, etc.  
This is not that different from decisions made for other elements of  
the page. For instance, if legibility was my only consideration for  
everything, then I would use 14px type for everything (heck, I might  
even use 30px type, since I no longer have to consider how well  
things fit or how much you have to scroll).

The point is, the more flexible elements are to being styled, the  
more choices I will have in designing the page to present the way I  
want it to, while keeping all considerations for the design in mind,  
including how well it fits in with user interface guidelines. As a  
designer, that is within my purview. The fact that there is an  
"appearance" value of "tooltip" [1] suggests than this is something  
that is reasonable to style (just as something with an appearance of  
"button" can be given a different background color).

I might want to change the background color of a tooltip to fit in  
better with the tone of the design, or to stand out better against a  
mostly yellow design. If I had a series of horizontally arranged  
elements, I might want to adjust the position of the tooltip a bit so  
that it did not cover up important elements. If I wanted the tooltip  
to be a more important visual guide, I might want to make it larger  
and have the fade-in animation occur sooner and quicker. I might want  
to have more control of the max-width, so that a long tooltip did not  
stretch across the whole screen as a single line (as it does in some  
browsers). Even if I wanted to be a bit more radical, and have the  
LABEL titles appear to the right of the INPUTs or something, this is  
not going to confuse anyone who is used to the normal positioning of  
tooltips per user interface guidelines (especially since so many  
elements do not have title attributes at all).

If I was designing a page for the elderly or for those with poor eye  
site, then that may be a more important consideration in my design  
choices than otherwise. In such a case, I might want the tooltip to  
be in larger, bolder type with more contrast (white on black, for  
instance). I guess that you don't care about that audience enough to  
let them see these tooltips as anything other than tiny text on a  
colored background.


> but the point was that if the platform normally displays title  
> attributes, and maybe tool tip like content in general, in the  
> bottom left margin of the window, users will expect to find it  
> there, not to have the odd web site try and pretend that they are  
> really using IE/Windows.
>
> I'm not expecting to get any consensus between us.
>
> -- 
> David Woolley
> Emails are not formal business letters, whatever businesses may want.
> RFC1855 says there should be an address here, but, in a world of spam,
> that is no longer good advice, as archive address hiding may not work.
>

[1] http://www.w3.org/TR/css3-ui/#appearance-val

Received on Thursday, 20 March 2008 17:41:22 UTC