Page MenuHomePhabricator

Remove "cols" user preference from MediaWiki core
Closed, ResolvedPublic

Description

Preferences always ask the number of colums for edit field, but only nostalgia and standard seem to use that preference. Either ask it only for those skins, or make those skins behave like the others.


Version: 1.17.x
Severity: minor

Details

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 11:11 PM
bzimport set Reference to bz24430.
bzimport added a subscriber: Unknown Object (MLST).

Good candidate for a preference to kill?

*** Bug 26815 has been marked as a duplicate of this bug. ***

This got discussed somewhere else I think, didn't you end up removing this in trunk chad because it wasn't actually setup to be used anywhere?

cdbapat92 wrote:

Patch to remove columns preference from user prefrences

Tested only with default skin. Applies on top of 1.17.

attachment remove_cols_preference.diff ignored as obsolete

I'd love to just drop that preference, though in a bit of quick testing in older skins eliminating the col= leads to it being unusably narrow.

I think we'll need to accompany this along with moving width: 100%; from skin specific css to the globally applied shared.css. While we're at it we might as well apply box-sizing: border-box; as well.

cdbapat92 wrote:

Removed cols preference

Rebased against trunk

Attached:

bsitu wrote:

Applied patch in r107187, thanks for the patch

But you wiped out any reasonable default too, causing Bug 33780!

bsitu wrote:

Thanks for the note, additional patch is applied in r109557

(In reply to comment #11)
Dear Sir,
In http://www.w3.org/wiki/HTML/Elements/textarea
does it not say

  • cols = valid non-negative integer specifies the expected maximum number of characters per line. by defult, it is 20.

So why do you insist on not setting it to something reasonable like you do for

  • rows = valid non-negative integer Specifies the number of lines to show. by defult, it is 2.

just because things work out on your browser doesn't mean it is that way for others!!

No, the magic of CSS should not be a requirement in this case.

Even in the HTML5 example at
http://www.w3.org/TR/html5/the-button-element.html#the-textarea-element

<p>If you have any comments, please let us know (you may use either English or Hebrew for your comments):
<textarea cols=80 name=comments dirname=comments.dir></textarea></p>

they don't manage to forget it!

Indeed, they never ever forget it (cols=80). It's on every example!

4 matches for "<textarea" in buffer: 4.10.8 The button element — HTML5 *w3m*

826:<p>If you have any comments, please let us know: <textarea cols=80 name=comments></textarea></p>
830:<p>If you have any short comments, please let us know: <textarea cols=80 name=comments maxlength=200></textarea></p>
834:<p>If you have any comments, please let us know: <textarea cols=80 name=comments>You rock!</textarea></p>
840:<textarea cols=80 name=comments dirname=comments.dir></textarea></p>

I agree. Looks like WebKit has a default of 20 cols:

var a = document.createElement('textarea');
a.cols

20

a.d.bergi wrote:

(In reply to comment #13)

No, the magic of CSS should not be a requirement in this case.

What do you mean with "magic of CSS"?

Wouldn't it be OK just to remove the setting, and set a fix size of col=80 in the skin.php?

(In reply to comment #17)

What do you mean with "magic of CSS"?

OK, the help of, use of, CSS.

Wouldn't it be OK just to remove the setting, and set a fix size of col=80 in
the skin.php?

Sounds good!

cols=80 not col. And maybe cols="80" even better...

Code reverted in r110007, r110008, r110009, r110010.

Thanks. Takes care of Bug 33780, I'm happy.

(In reply to comment #22)

(In reply to comment #1)

Good candidate for a preference to kill?

https://www.mediawiki.org/wiki/Requests_for_comment/Core_user_preferences

Tried before, need to make sure there's no regressions if we do.

We managed to get rid of the legacy skins but not this preference yet?

With I07895f76 merged no core skin actually uses this. Let's just set cols=80 and kill the pref.

Change 80061 had a related patch set uploaded by Demon:
Remove cols and rows preferences

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

Hmm "The body textarea on Page: pages editing was too big. The size defined in User preferences is now used". http://lists.wikimedia.org/pipermail/wikisource-l/2013-December/001700.html
Tpt, if it's about this preference you may want to use the default value directly I guess.

(In reply to comment #28)

Tpt, if it's about this preference you may want to use the default value
directly I guess.

ProofreadPage uses EditPage::showTextbox to build its textareas and so has no direct dependence on cols and rows system messages. Delete these messages won't break anything in the extension.

Change 101994 had a related patch set uploaded by Bsitu:
curl_setopt doesn't seem to url-encode the text

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

bsitu wrote:

oops, sorry wrong bug reference

Krinkle set Security to None.
Krinkle removed a subscriber: Unknown Object (MLST).

Removing good first task tag, seeing those many previous attempts and reverts in this task.

Change 331245 had a related patch set uploaded (by TTO):
Remove cols and rows preferences

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

TTO closed this task as Resolved.EditedJan 12 2017, 5:11 AM
TTO claimed this task.
TTO edited projects, added User-notice; removed Patch-For-Review.
TTO subscribed.

Example User-notice:

The "Columns" and "Rows" settings have been (OR: will be) removed from the Editing tab of Preferences. If you wish to mimic the effect of the "Rows" setting, you can add the following code to [[Special:MyPage/common.css|your personal CSS]], changing the number <code>50</code> to suit your needs: <code>#wpTextbox1 { height: 50em; }</code>