This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 12471 - Please consider changing the expected rendering of abbr[title] and acronym[title] to use border-bottom instead of text-decoration: dotted underline, which has much more limited support (being in CSS3 Text, not CSS 2.1), conflicts with existing browser def
Summary: Please consider changing the expected rendering of abbr[title] and acronym[ti...
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-11 11:07 UTC by contributor
Modified: 2011-08-09 22:32 UTC (History)
7 users (show)

See Also:


Attachments

Description contributor 2011-04-11 11:07:25 UTC
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html
Section: http://www.whatwg.org/specs/web-apps/current-work/#punctuation-and-decorations

Comment:
Please consider changing the expected rendering of abbr[title] and
acronym[title] to use border-bottom instead of text-decoration: dotted
underline, which has much more limited support (being in CSS3 Text, not CSS
2.1), conflicts with existing browser defaults, and tends to disturb character
shapes when there are descenders. If the currently suggested rendering is
implemented, many pages will have both bottom border and dotted underline
(effectively, double underline), as authors have specified border-bottom to
achieve better consistency across browsers (IE does not show border bottom or
underline of any kind by default, even in IE 9).

Posted from: 88.114.29.18
User agent: Mozilla/5.0 (Windows NT 6.0; rv:2.0) Gecko/20100101 Firefox/4.0
Comment 1 Tab Atkins Jr. 2011-04-11 16:45:51 UTC
The recommended UA stylesheet uses many features which are not widely implemented (or implemented at all) yet.  It is meant to reflect how elements *should* look, as far as CSS can define; it is not meant to actually be used in toto by any browser yet.
Comment 2 Aryeh Gregor 2011-04-11 22:18:27 UTC
We don't *have* to use only widely-implemented CSS features, but if browsers mostly agree on the current rendering, that's what we should standardize -- unless they want to change.  Compat with pages that have added border-bottom is exactly the sort of reason why we shouldn't go around changing preexisting default rendering (or anything else) without good reason.
Comment 3 Anne 2011-06-24 10:25:06 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: <http://dev.w3.org/html5/decision-policy/decision-policy.html>.

Status: Rejected
Change Description: no spec change
Rationale: text-decoration is way better for decorating text than border is. If this cannot be implemented we will find out then.
Comment 4 Aryeh Gregor 2011-06-24 18:12:15 UTC
I disagree.  The spec should reflect reality unless we know browsers want to change.  If at least one major browser (>5-10% market share) changes its behavior to match the spec and can confirm there's no compat risk, then I agree the spec should change too, because the spec is better.  But until then, the spec should reflect reality.  In practice this is a minor thing, so it's very possible browsers won't bother to change for years if ever, and the spec will have been wrong in the interim.

Hixie said if we can't agree we should reopen and let him decide:

http://krijnhoetmer.nl/irc-logs/whatwg/20110624#l-954
http://krijnhoetmer.nl/irc-logs/whatwg/20110624#l-995

So that's what I'm doing.  Note that he doesn't get bugmail for resolved bugs, so if the bug is resolved he'll never see it.
Comment 5 Michael[tm] Smith 2011-08-04 05:01:17 UTC
mass-moved component to LC1
Comment 6 Ian 'Hixie' Hickson 2011-08-09 22:32:15 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: I'm with Tab and Anne here. The spec should lead on this kind of thing. This doesn't conflict with the goal of matching reality; it's just that the reality we are trying to match is the one we expect the spec and all implementations to converge on. (It can't be the present reality, since implementations often disagree with each other.)