Page MenuHomePhabricator

Do something about "cellpadding="
Closed, DeclinedPublic

Description

This trick is presumably heavily deprecated but still widely used on all public wikis. T26529: Incrementally remove support for HTML elements removed from or deprecated in HTML5

https://ko.wikipedia.org/w/index.php?search=insource%3A%2Fcellpadding%5C%3D%2F&title=%ED%8A%B9%EC%88%98:%EA%B2%80%EC%83%89&profile=advanced&fulltext=1&ns0=1&ns1=1&ns2=1&ns3=1&ns4=1&ns5=1&ns6=1&ns7=1&ns8=1&ns9=1&ns10=1&ns11=1&ns12=1&ns13=1&ns14=1&ns15=1&ns100=1&ns101=1&ns102=1&ns103=1&ns118=1&ns119=1&ns828=1&ns829=1&ns2300=1&ns2301=1&ns2302=1&ns2303=1

https://ko.wikipedia.org/w/index.php?search=insource%3A%2Fcellpadding%5C%3D%2F&title=%ED%8A%B9%EC%88%98:%EA%B2%80%EC%83%89&profile=advanced&fulltext=1&ns10=1

<table style="width:100%; background:transparent;" cellspacing="0" cellpadding="0">

Such a bad mixture of HTML3 and HTML5 usually works somewhat, but this is probably dependent of "goodwill" of maintainers of web browsers. Minor color inconsitencies can be observed.

There is the "modern" syntax with "padding:5px 3px;". Unfortunately it is (as opposed to "cellpadding=5") NOT inherited from <table> to <td>. It must be repeated for every cell, making an automatic mass migration impossible, and increasing code complexity as well as pre-expand bloat and post-expand bloat. This is not sane. Unsuprisingly people stick with "cellpadding=" then.

How to fix this?

.# Immediately remove support for "cellpadding=" and other HTML3 tricks. This will give more consistent HTML output, but break 10'000's templates on all wikis.

.# Do nothing. This will not break anything now, but exports the responsibitity to the maintainers of web browsers who can break many wikis at any time in an uncontrolled manner.

.# Create a new private HTML-like element, let's call it "tddefault" allowing such syntax:

<table style="float:right;">
<tr>
<tddefault style="background-color:#DDEEFF; border:2px solid #AAAAFF; padding:0.1em; text-align:center;">
<td>ABCD</td>
<td>WXYZ</td>
</tddefault>
</tr>
</table>

which would be converted to:

<table style="float:right;">
<tbody>
<tr>
<td style="background-color:#DDEEFF; border:2px solid #AAAAFF; padding:0.1em; text-align:center;">ABCD</td>
<td style="background-color:#DDEEFF; border:2px solid #AAAAFF; padding:0.1em; text-align:center;">WXYZ</td>
</tr>
</tbody>
</table>

This would avoid both pre-expand bloat and post-expand bloat, but still increase size of the generated HTML. And most notably, this would allow automatic mass-migration of templates with subsequent removal of support for HTML3.

.# Allow to use <style> with inline CSS from templates by means of a parser function or LUA function, or enhance <templatestyles> to allow inline definitions instead of a separate CSS file with all its risks and flaws (wrong protection level, bad edits, separation or loss, ...).

Event Timeline

Arbitrary uses outside templates and modules should simply be removed by editors (and/or replaced with wikitable). You just don't need arbitrary padding. Otherwise, TemplateStyles is the answer.

For identifying uses beyond a simple search (which is often trivial), T173944: Linter should lint for obsolete HTML attributes.

Tgr subscribed.

This would be a feature request for Parsoid / MediaWiki-Parser. I am pretty sure we don't want to add a new context-sensitive pseudo-HTML element for a fringe use case like this, though. Use predefined padding in TemplateStyles CSS; there is no good reason to control padding from inside the wikitext. Use <col>/<colgroup> if you are really desperate.

(Somewhat related and also unlikely to happen: T200632: Allow template parameters to provide CSS to a templatestyles stylesheet)

Use <col>/<colgroup> if you are really desperate.

Neither are available in wikitext or html... T2986 ...

T2986: [tables] Please implement COL, COLGROUP unresolved since year 2004

T155813: Decide on storage and delivery method for TemplateStyles CSS resolved but rejected embedded CSS

Ok, this seems to be resolved now. The final decision is 1B+2C+3A/3E, meaning:
Styles will be stored as separate pages with a "sanitized CSS" content model.
Styles will be used via a <templatestyles src="PAGENAME"/> tag, no magic inclusion of subpages.
Styles will be delivered to the browser by embedding <style> tags in the body HTML, with deduplication when that becomes feasible.

don't need arbitrary padding

Not arbitrary, I need just a padding. The default padding is ZERO and the default line color is invisible, far away from optimal.

Otherwise, TemplateStyles is the answer

I was not aware of T155813: Decide on storage and delivery method for TemplateStyles CSS. But separate pages complicate further the design, IMHO not preferable.

The vast use of "cellpadding=" on many wikis is a strong sign of the fact that people either don't know that "TemplateStyles" exists, don't know how to use it, or don't want to bother as long as "cellpadding=" is the simple solution that just works.

don't need arbitrary padding

Not arbitrary, I need just a padding. The default padding is ZERO and the default line color is invisible, far away from optimal.

wikitable class, available out of the box for use on arbitrary tables, has borders, a background color, and non-0 padding on both td and th.

Otherwise, TemplateStyles is the answer

I was not aware of T155813: Decide on storage and delivery method for TemplateStyles CSS. But separate pages complicate further the design, IMHO not preferable.

Part of the decision there was to wait for multi-content revisions to decide the ultimate fate of where styles live.

The vast use of "cellpadding=" on many wikis is a strong sign of the fact that people either don't know that "TemplateStyles" exists, don't know how to use it, or don't want to bother as long as "cellpadding=" is the simple solution that just works.

Or that TemplateStyles has been around for a couple years while cellpadding has been around for a few decades and accordingly there is a vast amount of wiki debt to deal with? :) And that people need to be educated in the general?