Page MenuHomePhabricator

Consider having <big> in wikitext output a styled <span> in HTML
Closed, DeclinedPublic

Description

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/big

<big> was removed in HTML5, however it is prevalent in wikitext (included in VisualEditor and WikiEditor toolbars) and easy for editors to use. As of rGPARbc46bcb16105: Linter: Fix obsolete tags linting + ignore BIG, Parsoid/Linter no longer warn about <big> being deprecated.

We should consider rewriting these tags to use a <span> with the appropriate styling. An extension tag won't work since that has issues with PST, but I think @tstarling suggested doing it in the Sanitizer on IRC. This would allow <big> to continue being supported in wikitext, without outputting deprecated/obsolete HTML elements.

Event Timeline

ssastry triaged this task as Medium priority.Jan 4 2017, 6:29 PM

Change 334990 had a related patch set uploaded (by Legoktm):
Sanitizer: Rewrite <big> in wikitext as a styled <span> in HTML

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

OK, I took a stab at this. Mostly straightforward, except this will break any CSS that explicitly targeted <big>. It shouldn't be too hard to update the CSS to also support .mw-big.

Hmm. As a short-term measure alongside warning about it in wikitext?

I was thinking it would be relatively long-term. <big> is pretty convenient to use, well known, and we "encourage" it by having it in the various toolbars. Personally I think removing it from HTML5 while keeping <small> was a mistake (either both go or both stay). But I think this will give us the best of both worlds - big is OK for editors to use, but we maintain compliance with HTML5.

I'm not really convinced that deprecating and removing <big> in wikitext would be worth the effort (technical and social) - do we know of any browsers that are planning to remove support for it anytime soon?

I was thinking it would be relatively long-term. <big> is pretty convenient to use, well known, and we "encourage" it by having it in the various toolbars. Personally I think removing it from HTML5 while keeping <small> was a mistake (either both go or both stay). But I think this will give us the best of both worlds - big is OK for editors to use, but we maintain compliance with HTML5.

Eh. Maybe we should re-write <small> too in advance of the spec?

I'm not really convinced that deprecating and removing <big> in wikitext would be worth the effort (technical and social) - do we know of any browsers that are planning to remove support for it anytime soon?

Fair.

With this change, will Tidy continue to process

<big/>

reasonably? There are still articles on multiple WM installations with that invalid self-closed tag present.

We currently are removing center because it is removed in HTML 5 (and the other obsolete elements). I don't entirely understand why big is getting a different treatment. "Common" doesn't really fly for me (most/many obsolete elements are common, especially center) nor does "the toolbars support it" (they shouldn't--don't let the cart lead the horse).

I would rather see big removed than encouraged or allowed implicitly, especially because its use is not always as an inline element in wikitext.

Removal of the various other obsolete errors has not caused anyone to have an issue, so the "large social cost" mostly doesn't exist.

There's the semantic non-value of big as well. Why is it big? It basically shouldn't be used in mainspace because the semantics aren't there. (For everything else, there's MasterCard Template Styles.)

See also T40487#1148389

We currently are removing center because it is removed in HTML 5 (and the other obsolete elements). I don't entirely understand why big is getting a different treatment. "Common" doesn't really fly for me (most/many obsolete elements are common, especially center) nor does "the toolbars support it" (they shouldn't--don't let the cart lead the horse).

I would rather see big removed than encouraged or allowed implicitly, especially because its use is not always as an inline element in wikitext.

Removal of the various other obsolete errors has not caused anyone to have an issue, so the "large social cost" mostly doesn't exist.

There's the semantic non-value of big as well. Why is it big? It basically shouldn't be used in mainspace because the semantics aren't there. (For everything else, there's MasterCard Template Styles.)

See also T40487#1148389

Good thoughts. This ticket s from before we had Linter operational, before wikis worked on pages to fix them and when we didn't know how that was all going to be received. The other reasons were (a) there is <small> and it seemed people would assumed <big> would also exist and continue using it "intuitively" (b) editor toolbars still allowed the big tag. So, overall deprecating <big> seemed heavily disruptive from the 2016 lens.

In any case, as of July 2018, we should reconsider this in the light of the successful Tidy removal and how actively wikis seem to have embraced the changes as well as the successful deploy of template styles.

Change 334990 abandoned by Legoktm:
Sanitizer: Rewrite <big> in wikitext as a styled <span> in HTML

Reason:
Needs more discussion if this is ever to happen

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

Not currently working on this.

As further reason to decline this task, core has previously had similar functionality for align which was removed nearly a decade ago. See T42329: Don't use hacks to replicate a browser function, either let align="" pass through or not; in HTML5 and child task T42632: Kill $wgCleanupPresentationalAttributes from MediaWiki core.

If <big> is ever removed by browsers, it would still be in the DOM so all we'd need to do is add some CSS styling to restore it (or choose not to!), so as written this task is declined. But it seems very likely that will never happen, or we'll have significant time to discuss what to do.