Closed Bug 56702 Opened 24 years ago Closed 24 years ago

Should highlight any element with a TITLE attribute

Categories

(Core :: Layout, enhancement, P3)

enhancement

Tracking

()

VERIFIED FIXED
mozilla0.8

People

(Reporter: mpt, Assigned: attinasi)

References

Details

(Keywords: polish, Whiteboard: have fix)

Attachments

(1 file)

An interesting point was raised in <news:comp.infosystems.www.browsers.mac>: iCab applies a dotted underline to an ABBR or ACRONYM element with a TITLE attribute, so users know that hovering the cursor over the element will produce a tooltip with more information. Mozilla should do this too, and I see no reason why it shouldn't be done for *any* element with a TITLE attribute. Implementation note: Remember that such a rule placed in html.css should go before the one which specifies underlining for links, so that the solid link underlining overrides the dotted TITLE underlining.
To see if you really want this behaviour, check out my website, which has had something similar for over 2 years now, waiting for a browser to support it: http://www.bath.ac.uk/%7Epy8ieh/ Do we like this? I'm not convinced that we should do this as default behaviour. You just know people will complain that "mozilla renders page oddly, small dots in random places" or some such. This is trivially easy to add to a user stylesheet, if users want it, and to an author stylesheet, if authors want it. Anyway, if we do want something like this, it is easy to do (although we don't have any way of doing dotted underlines yet). [title] { border: dotted; } ...would do it, for instance. Note that it is not only text elements that may get this attribute.
Ok, I give up. Using 2000100919 build, I don't see any TITLEs on your home page, let alone borders. I do see them on <http://www.euronet.nl/~tekelenb/>, though, which uses { border-bottom: dotted 0.1em #999999; cursor: help }, and it looks quite groovy (though the use of border rather than underline is a bit spacey). [title] { border: dotted; } would be bad because it would look like keyboard focus, and because it would make images with TITLEs look ugly. I'm thinking instead of [title] { -moz-underline: 1px dotted }. As for whether users would like it, it would take them about three seconds to mouse over the first such item they saw (because at first they would be wondering if it was a link), whereupon a tooltip would pop up and they'd realize what the underlining was for.
Actually I thought iCab dot-underlined all ABBR and ACRONYM elements regardless if they had a title or not. I don't think visually marking every single element that contains a title attribute would be a good idea. For those that really get into micro-content (say, technical papers with lots of definitions) all the underlining (or whatever notation is used) would amount to visual spamming. However, dot-underlining ABBR and ACRONYM like iCab does _is_ a good idea. I like Tekelenburg's style rule alot, and have adopted it for my own sites' style sheets. These elements are useful enough in their own right to be distinguished somehow, IMO.
mpt: On my site the title'd elements have a green fuzzy background, instead of dotted underline. (My bad, I should have said this. However, since I can't seem to find an example right now, I'll shut up...) Tim: dotted underlines on acronyms and abbreviations is likely to amount to "visual spam" even more on technical papers with lots of definitions than the dotted underlines for title attributes idea. Of course, as I mentioned before, you could add this to your user stylesheet if you wanted it.
Reassigning to Attinasi and marking future.
Assignee: clayton → attinasi
Target Milestone: --- → Future
Pages that have title attributes should decide for themselves how they want to clue in the user, like the referenced website <http://www.euronet.nl/~tekelenb/> . I'm very tempted to mark this WONTFIX - here is a chance to convince me otherwise ;)
Status: NEW → ASSIGNED
I can think of two reasons right now. The first is that the TITLE attribute is content which is useful to the user, so the user should have access to it even if they have author style sheets turned off. Having access to it means knowing that it exists; and if you do not highlight TITLEd elements in the UA style sheet, the user will not know that such elements have a TITLE except if they hover over them for an extended period by accident. Secondly, by providing a default style for TITLEd elements, rather than relying on authors to highlight them (or not) in their own idiosyncratic ways using author style sheets, you increase consistency of appearance for TITLEd elements across the Web as a whole -- in the same way that providing a default style (blue and underlined) for links increases consistency of appearance for links across the Web as a whole. And consistency is good because it increases usability.
Depends on: 59109
Hixie and mpt both have good points. We don't want to "spam" the reader by cluttering the page with lines, colors, and doodles all over (the author/user can do that himself if he really wants to); but a consistent UI is extremely useful, especially when used to point out potentially important information. The problem is that I can't think of a uniform way to do this for each and every element. For text, a small trailing superscript of some sort might work. I'm thinking similar to 02D9 (a high dot) maybe, as it's a character I've not seen used to mark footnotes. Assuming the glyph was actually available, it would be just enough to make the curious look closer, and unobvious enough to gloss over when reading casually. *shrug* Go ahead, discuss. :)
Sounds like we need a pair of prefs: Highlight Elements with TITLEs? [Y|N] Title Highlight [wavy|dotted|solid|outline] This way, users could turn off the spam if they want, and if they like it, they could specify the look of it themselves. The prefs above don't allow the user to use a background color as a highlight though, but I'm not sure if that is reasonable for a default since the background color of the page won't be known. Personally, I think some form of underlining or outlining is sufficient. Any takers?
Oh, come on. Of the ~100 most usefully preffable items (i.e. the items which should be present in the prefs dialog), this sure ain't one of them. If implementing this would entail adding new prefs, then forget it and I'm sorry I ever asked. Really, if the user wants more sophisticated styling than a simple dotted underline, then they can go and edit user.css in their favorite style sheet editor. We don't need to offer explicit prefs for it any more than we need to offer explicit prefs for how many ems high an H1 heading is.
mpt: maybe a pref is overkill, but I cannot ignore the notion that loads of dotted underlines will look like so much spam on pages that use lots of titles, especially since some browsers won't decorate those elements and the author my not even see what it looks like when the elements are decorated. Maybe the simplest approach is to just do as suggested by Tim Larson (2000-10-16 06:36) and put the decoration on ABBR and ACRONYM elements with titles only. If the author wants to use the title attribute for other elements then they can put in their own rules, but since ABBR and ACRONYM are naturals for using the title and associated tooltip display, automatically styling them seems the most useful and provides some consistency across pages with no overriding rules for title'd elements. Try this text to the top of your html.css and see what you think: /* titles */ abbr[title],acronym[title] { border-bottom: dotted 1px #999999; cursor: help; } This is mostly the same as Tekelenburg's rules. I particularly like the use of the cursor, in fact I wonder it that is enough of a hint to the user? I'm proposing that we use the above rules in html.css to implement this feature request. Please provide feedback - as if I have to ask ;)
looks good r=rods
Will this bug be left open (with the dependency on bug 59109) after that patch goes in so that once Mozilla has a real "dotted underline" capability, the abbr/acronym stuff can use it instead of border-bottom?
Good question. If there is a compelling reason why we should use underline instead of the dotted border, then I think it probably should. If we apply the decoration to more element types then it might make sense, but for ABBR and ACRONYM what is the advantage to using underline vs. border-bottom? BTW: if we do implement the new CSS3 styles, I'd prefer to use the wavy underline...
sr=buster
I have three issues with the patch: 1. Could we insert this block at the end of the /* inlines */ block (just before the /* lists */ comment) instead of in the /* leafs */ section? I don't see the logic of putting those styles in the leafs section. 2. I would prefer if we used the coding style of the rest of the stylesheet and so had a space after the comma in the selector. 3. It would IMHO be much neater to not specify the colour, that way the colour of the border would match the colour of the text instead of being hardcoded to grey and thus potentially making colour clashes. Otherwise, looks great. I suggest someone open a new bug on switching to using underlines when that becomes available. Here is the modified patch assuming the above is ok with everyone: Index: html.css =================================================================== RCS file: /cvsroot/mozilla/layout/html/document/src/html.css,v retrieving revision 3.117 diff -u -r3.117 html.css --- html.css 2000/12/01 08:26:36 3.117 +++ html.css 2000/12/13 04:17:27 @@ -271,6 +271,12 @@ white-space: nowrap; } +/* titles */ +abbr[title], acronym[title] { + border-bottom: dotted 1px; + cursor: help; +} + /* lists */
Keywords: patch, polish
Whiteboard: have fix
Target Milestone: Future → mozilla0.8
This is great, BTW. Try the patch out on a page like http://www.htmlhelp.com/reference/html40/phrase/acronym.html The cursor thing works well too IMHO. Marc, rods, buster: Could you r=/sr= my modified version of the patch, assuming you prefer it to the original? cc'ing Ben since this is a CSS change.
Ian, I'll take your changes and check 'em in. The r and sr apply to it as well - I'm sticking my neck waaaay out here ;) Thanks!
Fix checked in: html.css
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Reopening should not mean that the fix doesn't work. It does and it is great! But there are more ideas for enhancements: What about continuing this idea for all elements with a title attribute by including [title] {cursor: help;} to html.css? This is quite different from the original idea of underlining them all. The problem with the tooltips is that they are too slow to do mouse-pointer-searching on a whole website if you try to find them. But they should not be faster either because the normal mouse moovement might pop up doezends of tooltips on some sites. In the contrary a slight cursor change doesn't harm. It tells the user: "if you stay here for a second there will be some action". But this leads to the next question: is {cursor:help} adequate for this purpose? iCab uses another cursor style for saying "attention". It doesn't add a question-mark to the arrow but a small exclamation-mark. Implementing this {-moz-cursor:attention} might give more room for using this little hint without making {cursor:help} uninteresting for places where _help_ is really needed (what _are_ places where {cursor:help} is used?). Third point: wasn't abbr[title], acronym[title] {outline-bottom: dotted 1px; cursor: help;} a more conforming solution than the currently used abbr[title], acronym[title] {border-bottom: dotted 1px; cursor: help;} ? I know that outline is not fully functional yet, but to keep the idea in mind...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Reopening DOES mean that the fix doesn't work :-) Please file new enhancement requests.
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
Yes, those seem like great ideas, but they each deserve their own RFE. VERIFIED. Looks gorgeous on Mac 2001-01-04-08.
Status: RESOLVED → VERIFIED
Blocks: 62050
Using border-bottom causes the line to be very low. In fact, when printed (PostScript print to file on 0.9.1), the line can be as low as the dot on the 'i' of the next line. The printed result is a bit ugly.
SPAM. HTML Element component deprecated, changing component to Layout. See bug 88132 for details.
Component: HTML Element → Layout
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: