Page MenuHomePhabricator

<abbr> is double-underlined in Firefox 40
Closed, ResolvedPublic

Description

Firefox 40+ underlines <abbr> elements instead of using a bottom border. (This issue tracks doing the same in Chromium.) mediawiki.legacy/shared.css forces its own bottom border, causing a double-underline effect. Since only Firefox has added support for the text-decoration-style property, this compatibility rule should be added to shared.css:

@supports (text-decoration: underline dotted) {
  abbr[title], .explain[title] {
    border-bottom: initial;
    text-decoration: underline dotted;
  }
}

This rule restores the default bottom border (which would be none in most cases) and adds a dotted underline where supported.

Event Timeline

mxn created this task.Jul 31 2015, 9:41 AM
mxn raised the priority of this task from to Needs Triage.
mxn updated the task description. (Show Details)
mxn added a subscriber: mxn.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 31 2015, 9:41 AM

Thanks for taking a look at the code!

You are very welcome to use developer access to submit those code changes as a Git branch directly into Gerrit.
If you don't want to set up Git/Gerrit, you can also use the Gerrit Patch Uploader. Thanks again!

Change 229331 had a related patch set uploaded (by Mxn):
mediawiki.legacy: Use CSS3 underlining for <abbr>

https://gerrit.wikimedia.org/r/229331

Edokter added a subscriber: Edokter.Aug 5 2015, 4:04 PM
matmarex renamed this task from <abbr> is double-underlined in Firefox to <abbr> is double-underlined in Firefox 40.Aug 7 2015, 6:51 PM
matmarex closed this task as Resolved.
matmarex assigned this task to mxn.
matmarex triaged this task as High priority.
matmarex set Security to None.

Change 229331 merged by jenkins-bot:
mediawiki.legacy: Use CSS3 underlining for <abbr>

https://gerrit.wikimedia.org/r/229331

Edokter added a comment.EditedAug 8 2015, 7:46 AM

Oh dear, we just moved the problem from Firefox to Internet Explorer; IE does not support initial (and probably never will), but it will someday support text-decoration-style, which will cause the same problem we're trying to solve here. And it already supports @supports in the nightlies, where it will throw an unneeded CSS error in the console.

mxn added a comment.EditedAug 8 2015, 5:27 PM

Edoktor, what error is that? I agree that initial can be replaced by none, but the whole point of @supports is that it only affects browsers that support the specific property-value pair given in the conditional (text-decoration: underline dotted). Other CSS2-compliant browsers should ignore the at-rule entirely.

@mxn, IE does support @supports in the nighlies, but not initial. So this creates a problem is they decide to implement text-decoration-style.

All invalid propertiy values (like initial) trigger a CSS error, but that's not important, but it may cause a double underline in IE in the future.

mxn added a comment.Aug 8 2015, 11:26 PM
This comment was removed by mxn.
mxn added a comment.Aug 8 2015, 11:31 PM

@Edokter, if IE (Edge?) nightlies support @supports but not text-decoration: underline dotted, they won’t even parse the ruleset to see the initial keyword. So no errors there. But I agree that it would begin triggering errors if text-decoration-style support were added in a later build. Bartosz fixed the oversight in a followup commit. Another option would’ve been to say @supports (text-decoration: underline dotted) and (border: initial) {…}.

Glad you understand. We shouldn't use @supports for initial, there would be no end to it and we'd end up with duplicate rulesets everywhere. Just avoid initial where ever you can.