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?

It's still in trunk.

Exterminate! EXTERMINATE!

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: remove_col.diff

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 #1)

Good candidate for a preference to kill?

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

(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

Change 80061 abandoned by Chad:
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