Page MenuHomePhabricator

EditTool characters slightly outside their boxes in WikiEditor booklet on Wikimedia Commons
Closed, ResolvedPublic

Description

So when editing pages on Wikimedia Commons, when clicking into the EditTools, the text for most of the options is slightly outside their boxes.

Screenshot:

Edit-tool-character-bleed.png (157×1 px, 38 KB)

Event Timeline

DLindsley raised the priority of this task from to Medium.
DLindsley updated the task description. (Show Details)
DLindsley added a project: WikiEditor (2010).
DLindsley changed Security from none to None.
DLindsley subscribed.

Pretty sure that is not an issue with the WikiEditor extension itself but the site specific .css styling in effect dealing with EditTools on Commons..

If I add

.wikiEditor-ui-toolbar .sections .section {
    line-height: normal !important;
}

to my personal common.css on the Commons project, the characters in EditTools become centered nicely within the faux button borders.

What to do with this bug & how to route it next I'm not exactly sure unfortunately. Can you please verify adding the same to your personal css results in the same rendering in the meantime?

Pretty sure that is not an issue with the WikiEditor extension itself but the site specific .css styling in effect dealing with EditTools on Commons..

If I add

.wikiEditor-ui-toolbar .sections .section {
    line-height: normal !important;
}

to my personal common.css on the Commons project, the characters in EditTools become centered nicely within the faux button borders.

What to do with this bug & how to route it next I'm not exactly sure unfortunately. Can you please verify adding the same to your personal css results in the same rendering in the meantime?

@GOIII Hello. Where exactly do you add that? Is it somewhere in Inspect Element or somewhere on the edit page? Thanks.

DLindsley lowered the priority of this task from Medium to Low.Dec 12 2014, 2:43 AM
DLindsley raised the priority of this task from Low to Medium.

To see if it corrects the issue, add it to your...

...file. See mine here...

If that indeed adjusted the character positions for you, you then need to lobby for a site-wide change here....

If that is accepted by the Commons "community" they will add it to the site-wide css. At that point you can delete the test one created under your User: name.

Thanks. Requested the site-wide change, and the stuff to do with the coding seems to have fixed it. The task is now closed. :)

Edokter reopened this task as Open.EditedDec 14 2014, 8:54 AM
Edokter subscribed.

This is a problem on all projects, and a simpler and more robust fix is:

.wikiEditor-ui-toolbar .page-[...] div span
    line-height: 1;
}

The CSS rules for [...] is probably dynamically generated (I just don't know where). In any case, here lies the culprit.

For a local fix, just use .page instead of page-[...].

This is a problem on all projects,

Not really. It happens only on projects that choose to re-task EditTools (ancient graceful fail/fallback for non javascript enabled browsers ~ mw-editTools) along with using the CharInsert extension/gadget at the same time (I beg you -- open any WP article, submit it for preview at least once then look at the source html without saving the edit. Anything in the old EditTools menu/js scheme is still being loaded although not displayed; but the associated font-size and line-height settings are still being passed down). Commons compounds the issue with a 3rd step by mapping "it" to its own group on WikiEditor.

So the crux of the problem here is "too many" inherited line-height &/or font-size settings being applied before final rendering --and-- using length or percentages for line-height values the way we do only invites more & more inheritance behavior breakdown.

Without trying to figure out what the correct number value should be, using normal was the safest alternative. If you say the ''final'' line-height setting that should be rendered along with it's desired font-size setting should be 1em, then the value [number] we should be using is simply 1 or 1.0 (e.g. no units of measurement; no percentages)

So the crux of the problem here is "too many" inherited line-height &/or font-size settings being applied before final rendering --and-- using length or percentages for line-height values the way we do only invites more & more inheritance behavior breakdown.

MDN documents this nuance in a nutshell.

w3.org says as much but you'll need to piece it together from various drafts/specs on your own.

I was talking about wikieditor toolbar in general... the *cause* lies there because it falis to assign a line-height to the button content to begin with. Any element added to the toolbar -- no matter what the source -- is then misrendered. Just try this fix on Commons, and you'll see all caharcter -- imported or not -- perfectly aligned.

line-height: 1; may be indeed the better choice. Though the difference is negligable. They both reset the content line-height in the context of their current container (as opposed to their parent container).

Just try this fix on Commons, and you'll see all character -- imported or not -- perfectly aligned.

But the same faux-buttons in WikiEditor's Special Characters drop down menu had no character leakage - what gives?

Its not the lack of an assigned line-height value for buttons so much as the poor way EditTools inherits a value here -- its a relic that's just not up to the task at hand anymore. Adding more .css settings to circumvent that reality is just adding on to the garbage pile if you ask me.

I went through same thing on Wikisource -- & imho the issue here is USING editTools in any way, shape or form the first place instead of deprecating it once and for all for CharInsert in addition to ''mapping it'' as its own drop down to WikiEditor after the fact as far as Commons is concerned.

But the same faux-buttons in WikiEditor's Special Characters drop down menu had no character leakage - what gives?

Actually, the character decsenders are breaking out of the bottom button border.

Its not the lack of an assigned line-height value for buttons so much as the poor way EditTools inherits a value here -- its a relic that's just not up to the task at hand anymore. Adding more .css settings to circumvent that reality is just adding on to the garbage pile if you ask me.

There is no line-height set; neither in WikiEditor or edittools. The only line-height it inherits is that of .mw-body-content; the page-wide line-height. Here's a rule of thumb in CSS: if you change the font-size in a restricted container; you must reset the line-height to 1. Otherwise the line-height that ends up being used is that of the container's parent element instead of the container element itself; basically leaving the line-height undefined. This results in too much line-height in reduced fontsizes, and vice-versa.

So yes, it is in fact a matter of a missing line-height; it forms an inseparable pair with font-size. Just set the line-height to 1 in whatever element the font-size is set (as I did above), and all will be fine.

So yes, it is in fact a matter of a missing line-height; it forms an inseparable pair with font-size. Just set the line-height to 1 in whatever element the font-size is set (as I did above), and all will be fine.

EditTools is somehow forced into a WikiEditor group after the fact and that's where the inheritance "broke" on Commons. I can't blame WikiEditor for not being able to anticipate the ancient monobook-ish, classic-toolbar junk folks would try to force into it; this was but one example of that.

So patching .page without the -groupname [happens to be .page-Edittools1 in case it matters] isn't really a fix when it comes to instances of character mis-alignment other than the one specifically reported in Commons with EditTools. Sure it would help workaround the final rendering there too but in reality we probably be better off ''fixing'' the .css in the WikiEditor extension itself, no?

Commons could then also do away with their fix in MediaWiki:EditTools.css -- they also use .page-characters just like the built-in Special character wikiEditor-group already does.

Who's got five minutes to add line-height: 1.0; to the above linked .css entry for .wikiEditor-ui-toolbar .page-characters div span

Did I mention that all pages in the WikiEditor are suffering from the missing line-height, not just EditTools? My above patch is targeting WikiEditor, not EditTools! And yes, this patch should be made in the WikiEditor extension, not EditTools!

I don't understand why I'm not getting my message across...

I don't understand why I'm not getting my message across...

Too funny. I just went 12-rounds on this back on the Commons talk page saying the same thing.

I don't know what WikiEditor you have but mine is mostly made up icon-buttons, setup in a toolbar like fashion so I'm unaware of any weirdness taking place re: line-height and similar. That's why it took me so long to make the connection I guess -- the Help booklet and the Special characters booklet are the only ones where font-size or line-height comes into play for me -- and I rarely use either -- so I'll take the blame up to that point.

But if you say ''every'' text/semantic based toolbar or booklet out there is hosed because the line-height has been missing all this time, I'll have to take your word for it. If that's the case, then there is more that needs to be done than just adding that one line to the extension's .css

Again, anyone care to add line-height: 1.0; to this linked .css entry for .wikiEditor-ui-toolbar .page-characters div span ?

GOIII renamed this task from Edittools options text slightly outside boxes when editing on Wikimedia Commons to EditTool characters slightly outside their boxes in WikiEditor booklet on Wikimedia Commons.Dec 14 2014, 9:14 PM
GOIII removed GOIII as the assignee of this task.
GOIII updated the task description. (Show Details)

Ah... OK. Partly my fault. What I meant is the problem is also visible under "Special Characters" toolbar, and every page thereof. You will see everything there almost breaking out of their boxes.

I'll be damned if I can't figure out how to get it to take - can anyone take it from here?

diff --git a/modules/jquery.wikiEditor.toolbar.css b/modules/jquery.wikiEditor.toolbar.css
index 84470c3..b7a4b35 100644

--- a/modules/jquery.wikiEditor.toolbar.css
+++ b/modules/jquery.wikiEditor.toolbar.css
@@ -252,20 +252,19 @@
 .wikiEditor-ui-toolbar .section-help .page-table .cell {
 	vertical-align: top;
 }
+.wikiEditor-ui-toolbar .section-help .page-table td.cell-description,
+.wikiEditor-ui-toolbar .section-help .page-table td.description {
+	width: 20%;
+}
 .wikiEditor-ui-toolbar .section-help .page-table td.cell-syntax,
 .wikiEditor-ui-toolbar .section-help .page-table td.syntax {
 	font-family: monospace, "Courier New";
+	width: 40%;
 }
-.wikiEditor-ui-toolbar .section-help .page-table td.syntax,
-.wikiEditor-ui-toolbar .section-help .page-table td.cell-syntax,
 .wikiEditor-ui-toolbar .section-help .page-table td.cell-result,
 .wikiEditor-ui-toolbar .section-help .page-table td.result {
 	width: 40%;
 }
-.wikiEditor-ui-toolbar .section-help .page-table td.description,
-.wikiEditor-ui-toolbar .section-help .page-table td.description {
-	width: 20%;
-}
 /* Characters Pages */
 .wikiEditor-ui-toolbar .page-characters div span {
 	border: 1px solid #DDDDDD;
@@ -282,6 +281,7 @@
 	cursor: pointer;
 	font-family: monospace, "Courier New";
 	font-size: 1.25em;
+	line-height: 1;
 }
 .wikiEditor-ui-toolbar .page-characters div[dir=rtl] span {
 	/* @noflip */ direction: rtl;

The line-height:1; change does seem to work for me (on Safari at least). Perhaps your cache wasn't clearing ?

I know adding line-height:1 works. I've "known" how to go about rectifying this locally for months now. And everybody that I asked to apply it via their local .css settings wound up keeping it because it worked too. en.wikipedia has it in their common.css, en.wikisource has it their common.css . . . I don't know what more convincing I can do at this point.

This issue at this point is I don't know what I'm doing when it comes to Git and everybody who seems to know what they doing is too preoccupied to stop & make little fixes like this one. The backlogs for certain extensions/projects are filled with such minutia -- its just a pain in the azz to go back in bugzilla time and play detective for every issue I suppose.

Change 183051 had a related patch set uploaded (by TheDJ):
Toolbar: Reset lineheight for character cells

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

Patch-For-Review

This issue at this point is I don't know what I'm doing when it comes to Git

[offtopic] Does https://www.mediawiki.org/wiki/Gerrit/Tutorial help?

[offtopic] ... only gave me enough rope to hang myself with... then the holidays started and it was one lynching after another.

[offtopic] I managed to get in and do up to the recursive download part but events both in meat-space and online kept overtaking any focus or progress I was making at that point. I'll get around to figuring it eventually. Thanks for asking.

As I haven't seen any more discussion on this report for 3 days, and that the Gerrit patch has been uploaded, I have closed this task. Feel free to reopen it if there is more to discuss.

Change 183051 merged by jenkins-bot:
Toolbar: Reset lineheight for character cells

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

Verified in wiki commons - labels look properly centered.