Last modified: 2014-11-17 10:36:42 UTC
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.
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!
Created attachment 9135 [details] Patch to remove columns preference from user prefrences Tested only with default skin. Applies on top of 1.17.
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.
Created attachment 9137 [details] Removed cols preference Rebased against trunk
Applied patch in r107187, thanks for the patch
But you wiped out any reasonable default too, causing Bug 33780!
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
(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
oops, sorry wrong bug reference
