(In reply to comment #0)

• It doesn't cover Lua modules, because the Scribunto extension doesn't use

the
mw-code class (it probably should).

Filed bug 57825.

• The SyntaxHighlight extension seems to convert tabs to eight actual spaces,

so this rule would have no effect on <source> tags.

Filed bug 57826.

Is there a minimal testcase somewhere available?

How about [[mw:MediaWiki:Gadget-oldeditor.js]]? An example on a wiki that uses tab-size is [[wikt:vi:MediaWiki:Gadget-headers.js]].

I think it would be better to simply set the tab-size property to 4 on the entire document (the body element). Tabulations equivalent to 8 spaces are never desirable, so I can't think of any reason to not set it to 4 on everything.

tab-size is still a CSS3 draft. There is no support in IE (not even 11). Such a rule would cause some inconsistencies across browsers.

There’s already an inconsistency in every browser between the view and edit actions, which leads to confusing indentation in scripts and modules. In IE and older versions of Safari, tab-size degrades gracefully, in that tabs continue to appear eight spaces wide. I wouldn’t consider that a regression.

(In reply to Erwin Dokter from comment #5)

I think that would be a problem if it caused a regression, but, as Minh Nguyễn mentioned, it degrades gracefully since it does not cause problems. That it is inconsistent is not really a problem: it is still an improvement to have a decent tab size on modern browsers even if the old behavior is kept on browsers that do not implement it.

Any reason why this should not be applied to every pre-formatted text? Or all text for that matter?

I’m not opposed to applying it everywhere. Those Wikipedia articles that depend on the default eight-column tab size would be able to override the tab-size properties inline.

It seems to me that there is now a CSS rule like

.mw-highlight pre {
	-moz-tab-size: 4;
	-o-tab-size: 4;
	tab-size: 4;
}

but no one has reported that on this task. Maybe this can be closed now?