User talk:Ineuw/Archives/2015-06-30

From Wikisource
Jump to navigation Jump to search

— vs. {{—}}[edit]

Hi there, I noticed that a number of the edits done to pages I've proofread were changing instances of {{—}} to —. Is there some guideline as to when to use either? -Einstein95 (talk) 09:30, 14 March 2015 (UTC)[reply]

@Einstein95: Just noticed your post (for some reason, I got no notification). There is no difference. The braced emdash was the result of my forgetting to remove the braces after I do external spell checking. If I don't add them then the spell checker stops at every occurrence.Ineuw (talk) 17:13, 14 March 2015 (UTC)[reply]
@Ineuw: So I should replace {{—}} with — ? Say on Page:Popular Science Monthly Volume 43.djvu/341. --Siddhant (talk) 13:08, 8 May 2015 (UTC)[reply]
@Siddhant:Please do remove them. I do that whenever I notice them. — Ineuw talk 13:54, 8 May 2015 (UTC)[reply]

Of interest?[edit]

Hey again.

Just got done making Vector my b^tch and thought you might be interested. Go to Gadgets --> Interface and check out Collapsible Nav Menus. It makes the entire sidebar menu morph into something like the existing personal flat list in Vector's top-right corner. Let me know if you can finally move closer to the wiki-baselines or not (and of course if it has any trouble w/FF or Chrome etc.). Prost. -- George Orwell III (talk) 11:23, 14 March 2015 (UTC)[reply]

I like! Just a note, you realize that the menus stay open? (I switched back to Vector because this feature in Modern is too close to the Previous/Next buttons and interfered with pagination. — Ineuw 17:32, 14 March 2015 (UTC)[reply]
I know! I know! I couldn't figure out how to replicate that mouse-hover/change-focus thing -- though I know its possible -- under Vector without making a mountain out of a molehill (right now its mostly just .css with the original arrow-collapse script-let they removed from the vector extension a few weeks ago). And just "breaking the cookie" is not an option; we still need Display Options retain the last invoked Dynamic Layout settings & such. I'll figure it out eventually (with the caveat somebody doesn't speak up about missing logos or broken functionality elsewhere).

There is an upside or two already - the drop down's width only takes up max space when a single heading is opened; the others remain as wide as their labels happen to be (eventually I'll get all of them to "slide open" into the same general screen-space rather than just drop straight down. Plus its far more more akin to Minerva(?) (the mobile mode's layout) than any other skin still using sidebars of any sort. I'll touch back later. -- George Orwell III (talk) 18:14, 14 March 2015 (UTC)[reply]

Version b2 -- Now you can just hover to open menus (or click on them to pin open) and much less "bouncing" when going from one page to another. Please check it out against your testbed and report any issues you might come across. I'd like to announce it for wider "testing" after tomorrow's 1.25wmf22 update if possible. -- George Orwell III (talk) 19:54, 23 March 2015 (UTC)[reply]

Will do it right now.— Ineuw talk 19:56, 23 March 2015 (UTC)[reply]
@George Orwell III: Really like it!!!. I like the idea that the menus shift over so they are not covered when a menu is selected, also like the fact that inapplicable menu items are hidden (like when I select Tools "What links here"). My only comment is - would it be possible to move the whole group of these drop down menus to the right, as much as possible, because when I go to click "next page" it's difficult not to hover over the new menu as well. BTW, I am using the Vector, not the Modern skin in WS.— Ineuw talk 20:17, 23 March 2015 (UTC)[reply]
Here is where I can use some advice as a sysop with the community's interests in mind and not so much as a "greedy" User at heart.

First, it should only work in Vector - if you switch away from Vector and then back; you should be forced to re-enable the gadget manually again.

Second, some background info first. [mw-]head is the shaded top "bar" from left to right on any Vector page and is where the Vector tabs (view, talk, watchlist, edit, history, etc.) reside along with the personal tools flat list found along the top-right of the head. This header is intersected on the left from top to bottom by [mw-]panel -- where 1.) the site logo and 2.) the sidebar menu of tools, options, languages etc. originally reside. (Please recall "we" killed the logo on our own in User .css before all this; this is important later below).

My first "problem" is the Vector tabs and personal tools in head are further separated into #left and #right DIVs; the personal tools, search bar and some tabs like edit, history are in the right DIV (p-personal atop them) and view and talk by themselves to the left. The gadget takes panel, makes it a flat-list and moves it atop this left DIV container to mirror the right side (then "eliminates" the left margin altogether, closing the sidebar).

So in order to move the panel flat-list further to the right and up against the personal flat-list like you ask, it would screw up the original Vector skin design first and foremost (not easy to rectify so can't you be bit more careful and bit less limp wristed? :). In addition to that, our "lack" of a logo of any sort would probably not go over well with the higher-ups principle wise. User: wise - we'd need to do what we do now; kill it in our personal .css afterward. The problem either way is the ~11em left margin the logo normally takes up is not easy to recover because of this principled logo question. Should we care? Screw principle and recover ~11em at the price of those who do want a logo? Isn't that OK since its a voluntary Gadget?

Finally -- I can't figure out how to get the left panel flat-list to clear right(?) and float under the personal right flat-list when the browser window width is smaller than the total width of both lists. Currently, they both overflow over each other when I shrink browser window width past that trigger point. Any ideas on how to get the left list to "flow" right under the right personal list in those cases? -- George Orwell III (talk) 21:05, 23 March 2015 (UTC)[reply]

┌─────────────┘
 FWIW I've refined it to the point where I think its stable enough to work with if I do say so myself. I had to change the gadget's naming scheme to Sidebar Flat-list cause Collapsible Nav was already in use on a number of projects already in addition to not being very "accurate" anymore. Let me know what you think - suggestions still welcome. -- George Orwell III (talk) 21:03, 29 March 2015 (UTC)[reply]

@George Orwell III: Sorry for not getting back to you earlier. I like this layout as well it is very neat and no problems. I also like that the way it works, the {{nop}} is closer to the pagination controls.— Ineuw talk 03:16, 31 March 2015 (UTC)[reply]
@Ineuw: Great. I'm counting on you to let me know if you come across anything odd/broken/needs improvement if you keep using it (please let me know if you stop using it btw). In case you didn't notice, you can still "pin" menus open by clicking the arrowhead - though it won't cache that state past the screen you're already on. If all goes well, I'll "announce" it to the masses Wed. after tomorrow. Thanks again. -- George Orwell III (talk) 16:58, 31 March 2015 (UTC)[reply]

Comment on a PSM issue[edit]

Can you contribute your thoughts on Wikisource:Scriptorium#footer_string_-_what_to_do.3F Thanks. --Siddhant (talk) 03:11, 19 April 2015 (UTC)[reply]

Just delete it, we never use it!!!!.— Ineuw talk 03:25, 19 April 2015 (UTC)[reply]

Template:PSMTitle[edit]

Ineuw, are you aware this is broken? Moondyne (talk) 15:22, 22 April 2015 (UTC)[reply]

@Moondyne:Thanks for letting me know. I am correcting them. — Ineuw talk 15:32, 22 April 2015 (UTC)[reply]
I had to fix them anyways for another reason, and I am curious if you saw the problem, or was it revealed programmatically? — Ineuw talk 05:50, 23 April 2015 (UTC)[reply]
I just stumbled on it while reading. I had thought the template was faulty but I now see that its just useage. {{Pt|THE FISHES OF JAPAN.|}} vs {{Pt|THE FISHES OF JAPAN.}} I can fix those. Moondyne (talk) 09:15, 23 April 2015 (UTC)[reply]
First, I added the second segment later, so they were missing in the early titles, but I am fixing them quickly just don't remember how early. — Ineuw talk 14:32, 23 April 2015 (UTC)[reply]
Yikes! Moondyne (talk) 14:41, 23 April 2015 (UTC)[reply]
Vol 33 was already OK. I am correcting Vol 11 now, (probably until Vol 15). Besides, I check every page as I proofread because I have to anchor the titles, etc. for the indexes.— Ineuw talk 14:50, 23 April 2015 (UTC)[reply]

some formatting feedback required[edit]

Hello, I would appreciate any thoughts on my couple of recent formatting edits to Page:Popular Science Monthly Volume 31.djvu/817. Feel free to revert. Here is how it looked in my browser: screenshots --Siddhant (talk) 14:13, 26 April 2015 (UTC)[reply]

It's perfect. Thanks you so much for helping. My solutions are often made out of ignorance. My only wish is that the whole project remains consistent in looks. I am aware that there are elements that could have been done better, and I corrected many by returning to the beginning, but when I started, I didn't know anything.

You will also notice that all section titles are templates, which allow for modifying the font & looks. Recently changed the article title template {{PSMTitle}} from Arial to Liberation serif which is closer to the original and because it's supported by all browsers (Tested). — Ineuw talk 14:54, 26 April 2015 (UTC)[reply]

@Ineuw: Thanks. Yeah, I saw your recent changes to all titles. One question, couldn't you make the thirdsecond parameter to the PSMTitle template optional, instead of inserting a "|"(pipe) character in most titles which don't need a third parameter. --Siddhant (talk) 20:35, 26 April 2015 (UTC)[reply]
@Siddhant:: there is also a template for that, {{Float_right}}.— Mpaa (talk) 17:33, 26 April 2015 (UTC)[reply]
@Mpaa: Ah! Works perfectly. I had seen it earlier, but I was worried that making it _float_ might not allow me control in which line it appears. Looks like it does keep it in the same line. A little perplexing, but works. Thanks. --Siddhant (talk) 20:35, 26 April 2015 (UTC)[reply]
I may be on a different page, but that template began as a very simple template, without "|" separation between the two parameters. I noticed that the reference number displayed a large font, just like the title. So I added the optional second parameter with a 75% font size for the reference number. This second option was in a <span></span> and the combination of that within the <div></div> forced the author name much lower that it should have been. Then, the font and padding parameters were modified because of mwf software updates and the author name dropped even further. Last week when I changed the font and tried to reduce the space between the author and the title — I couldn't, so I used a table in the template, which made the 2nd parameter obligatory. The vertical bar didn't exist until volume 19, and then it was missing only 1 - 2 titles per volume until Vol 32. Anything later than that doesn't matter, because I must edit the pages to add anchors and some other minor modifications. The other advantage was that a good number of titles were corrected. — Ineuw talk 00:05, 27 April 2015 (UTC)[reply]
Ok. --Siddhant (talk) 02:04, 27 April 2015 (UTC)[reply]

year of death of Author:Mary Alling Aber[edit]

Hello, in this edit, you added birth and death years for the author. What is the reference for this? I understand that this is a very old edit, but I have been unable to find any source for those dates. Why I'm looking for sources is because I believe that the death year—1915—is wrong. Any pointers to any sources would be very helpful. --Siddhant (talk) 15:00, 11 May 2015 (UTC)[reply]

@Siddhant: Hi. Wherever and whenever you come across something questionable, please feel free to correct it. My "mania" is only about the consistency of style while its' being worked on. My striving for consistency is only to present a comprehensive and organized effort, hoping thereby others will accept it. But after completion, I cannot and will not have any say in the matter. After all we are a free and open web site. . . . Think I created a monster and will soon post my views on the subject of consistency of the PSM project.

As for this author, I've spent the past hour looking for that information and also came up with nothing. the LC names authority is down for maintenance, so I am limited to what's available. I also tried Ancestry.com and the NYT obits which is usually a very good source, but no luck. — Ineuw talk 18:04, 11 May 2015 (UTC)[reply]

Fraktur fonts[edit]

Hi, please don't think I was being critical. As you say, I use the font family myself from time to time. I just don't want us to unthinkingly replicate every nuance of a 19th Century publisher's armoury for a 21st Century audience. Which is why I've been asking a few "why" questions recently in response to various "how to" questions. Beeswaxcandle (talk) 07:51, 12 May 2015 (UTC)[reply]

Took no offense whatsoever and I agree with you. Mostly done it in the name of familiarization with web related matters of the free software world. Too much to learn in too little time.— Ineuw talk 16:00, 12 May 2015 (UTC)[reply]

Font size revisited[edit]

I see you're tinkling with "Sandbox 5" again after being idle for a bit & thought you should know I removed the local "post typography refresh" tweaks that at one point made "whole numbers" out of the current fractionalized Vector defaults. Fixing font templates is not going to help until selecting a sane site-wide font-size & related/relative line-height is made. I had thought a calculated 14.00000px would multiply and zoom nicely but it doesn't for all browsers in all the same scenarios. Seems to me everything should be based on the industry "default" (16.00000px) especially Vector content to get the best (small, smaller, smallest, medium large, larger etc.) multipliers as far as font size goes but NOBODY is "concerned with Paragraphs" like we are at Wikisource when it comes to this nuance so they focus on making H1 through H6 "font-size friendly" first (Wikipedia article sections) and that is why we wind up with 0.8750em and 1.6 (both cause calculated fractions under IE at the minimum) as Vector default for paragraphs it seems. It should be paragraphs determining all the other types of text-related elements like side-notes or headings & not the other way around like we have now. -- George Orwell III (talk) 03:24, 24 May 2015 (UTC)[reply]

Thanks for looking in on me, really appreciate it. Understand what you're saying about different browsers.

I don't know if you have Firefox installed, but I installed an interesting FF add-on named font finder 1.1.1. When I specified 1.0 rem fs and lh to see the "industry default" it reported 17.000px. not 16.000px as you mentioned. This is same on Wikipedia HERE

So, I thought I might be better off to use fractions of 'rem' rather than float between so many different measurements. However 'rem' is a dynamic measurement and 'pixel' is a fixed measurement. In Sandbox5 page I did some "rem" conversions. What do you think? (By the way I am well familiar with points, mm, cm, in, pica and TWIPS.) — Ineuw talk 04:00, 24 May 2015 (UTC)[reply]

Ineuw: not sure your add-on is "calibrated" because that Wikipedia sandbox reports 16px = 1rem for me (IE11). BTW, Rem should only be used at the top-level or major-level containing/parent element to [re]establish a baseline that "everything" under/within it "should" look to render themselves accordingly. All other height effective measurements should be in em (save simple borders or when line-height is in play).

Plus in your local sandbox 5 you can't screw with headings (H3) or (UL) lists because for example they do not always have the same line-height as paragraphs or will usurp/modify the calculation for elements from that point on (specifically Vector uses line-height 1.5 for lists and 1.6 for paragraphs normally). So right now in a nutshell; Sandbox5 does not "reflect" nearly the "same" when the under mediawiki's influenced rendering is compared to just my browser and a copy of your experiments outside of mediawiki influence rendered using my own local .htm w/ matching css to account for Vector, etc. Its not you; it's Vector et al. behind this craziness.

Here's a bit outdated article that does a fairly decent job of what we're actually trying to accomplish in the end by setting and adhering to a FS & LH baseline from the work's outset -- too bad he bases his examples around 12px rather than 14px or 16px which -- by today's monitor standards -- is thought of as "easy reading". Still the logic behind the premise given is sound and, in my view, should be something we need to [re]establish on Wikisource to finally put these redering "differences" to bed once and for all.

I tried to imitate his "lined paper" background approach at various [supposedly] fixed pixel heights with just as illuminating results/findings -- the current incarnation at User:George Orwell III/Lofas in case you're interested (see your Vector.css too). I just wish I had a "better" graphic for background(s) cause the lines still seem to get blurry at some setting or another and are not dynamic nor friendly to resizing like I envision a .svg based background would/could be. Any thoughts? Ideas? re: Lofas? -- George Orwell III (talk) 04:54, 24 May 2015 (UTC)[reply]

@George Orwell III:, Didn't forget about replying to this post, it's just that Windows 7 crashed yesterday morning and had to reinstall the OS and all the software, a 24 hours of unplanned activity. There is a lot on my mind about about font sizes and line heights, but must leave for now. — Ineuw talk 18:38, 27 May 2015 (UTC)[reply]
@Ineuw: thanks for touching-back. I eagerly await your thoughts on this since it is my belief its indeed time to address and resolve this issue so other issues are not "fixed in vain" in moving forward. -- George Orwell III (talk) 22:59, 27 May 2015 (UTC)[reply]

2015-05-28[edit]

@George Orwell III: Looked at the Lofas folder and in the lined guide, and only one font size aligns to the guide, and thanks for that link to the web site.

If using rem only for the top font hierarchy setting, then for simplicity's sake, would it not be easier to use pixels only afterwards, and drop em? What I am aiming at is to reduce and the simplify measurements. Since a pixel is a fixed measurement and em is dynamic — in the case of matching the line-height to the reduced font templates, it would be better to use pixels as well?

IMO, that much "fixed-ness" (using px for some vertical affecting elements but em for the "rest" in addition to the instances concerning line-height & font-size association) is partly the reason why find ourselves where we do re: this nuance today.

First: The factor that we must accept without question is there will always some differences among browsers & their default behavior followed by additional differences thrown into this mix thanks to changes made from one individual User's settings to the next User:'s settings -- that is just an unavoidable fact of life; user's won't always line up neatly as well as browser behavior won't always be the same. That said, I'm not here to champion one browser over another or one User's needs over somebody else's -- that short sightedness is also partially how we got into this hole too(intentional or otherwise). I'm not going to entertain any such favorable to some solutions either (there is no point since that kind of solution will eventually come back to "ruin things" someday in the future just as it is happening to us now). -- George Orwell III (talk) 01:37, 28 May 2015 (UTC)[reply]

This brings me to the fourth measurement of % which confuses me (and I am sure others as well), in the context of line heights. In the usage of the reduced font size templates I constructed, my presumed full line height was 140%. This was reduced to line heights of 120% = fs90, 110% = fs85, and 95% for fs75 and it works. How come the standard line height was 140%? Shouldn't it have been 100%? . . . . and at this point I better quit. — Ineuw talk 00:44, 28 May 2015 (UTC)[reply]

P.S: It the case of the lined page, it's the spacing between paragraphs which throw everything. — Ineuw talk 00:47, 28 May 2015 (UTC)[reply]

FORGET the TEMPLATES - these will always take the flawed so called standard .css input we have now and produce even more flawed results than without. Fixing the core settings is needed in order for any template to render as the same as possible across the board the way I see it.

Second, the lined paper base I used is not dynamic since it is a png. If I wasn't so illiterate when it comes to images, ideally, every baseline (line-height product) would have an svg that recognizes the browser/settings of the moment as well as when changed.

In other words if such an svg produces a computed result rendering in 16px font-size with a 24px line-height by default (imagine in IE this would be what the Medium font-size setting gives me on Wikisource), when I changed that to Larger -- whatever god damn multiplier IE applies that then renders a computed font-size of ~18.3333333px (hypothetical) with a line-height of ~26.6666666px (hypothetical) should also render the svg accordingly (i.e. dynamically = the same hypothetical ~26.6666px). Now for a FireFox user, the browser wording might be different, have more 'larger' and/or 'smaller' font choices than IE does, set to a different font family than I am and maybe many other similar differences compared to me BUT the same thing should take place for that User as it did for me regardless of the specifics. It doesn't matter if his/her multiplier produced/rendered a calculated font-size: of ~19.34px and a line-height: of ~27.67 as long as the svg faux lined paper proportionally changed too. Do you see where I'm coming from after all that? -- George Orwell III (talk) 01:37, 28 May 2015 (UTC)[reply]

Of course I understand where you coming from, but where are you heading to? Perhaps you should work backwards from the desired result, define what the end product should be, and then resolve each obstacle. — Ineuw talk 01:55, 28 May 2015 (UTC)[reply]
@Ineuw: because I know the .css for vector right now -- without change or interference from anything or anybody -- says
.mw-body-content {
    position: relative;
    line-height: 1.6;
    font-size: 0.8750em;
    z-index: 0;
}
but without changing any default settings in IE11 (i.e. the Medium text-size setting)...
* computed font-size is 13.93px (0.87em * 16 rounds up to 13.93); and my
* computed line-height is 22.28px (13.92 * 1.6 rounds down to 22.28)
Put aside fact separation is being introduced whenever any "rounding" of any sort takes place at all compared to using the hard number(s) and just absorb the fact IE calculated font-sizes (when in em) to 2 decimal places only. Since the default .css is in em to 4 decimal places but IE only does 2 decimal places, a theoretical multiplier of 140% -- be it template driven or thru a browser setting -- to my 13.93px will NEVER be the same as 140% to the intended Vector calculated 14.00px default it seems to be for others.

I can easily overcome this mathematical difference in IE by using font-size: calc(( 14 / 16) * 1.00em)) or similar 'calc before calculation' alternatives BUT damn if that don't "fly" for the dozens of stupid [skin based] css changes to follow -- never mind the templates built on all those changes after the fact.

"Thankfully" the IE problem is isolated to just that 2 decimal place when in em quirk whereas all the "other" browsers [apparently] begin fake things at some point or another also through variations on "rounding" -- also making multipliers (percentages or otherwise) problematic once we start changing things away from the "baseline" values (without reestablishing it between major sections as I've said before).

So regardless of the units used or the mathematics involved, arriving at the most flexible final Base Line possible is key for the resulting rendering to be optimal all around as long as the "behavior" is known, vetted, accounted for and consistent in reaching that baseline. Anything happening that after that Base Line will therefore be uniform in rendering as well (the way I see it).

The second stage once that baseline has been secured will require the use of .css media screen rules to take us across the current divide between mobile and phablets thru true tablets and laptops all the way up to desktops and monitors (e.g. the elimination/rebirth of dynamic layouts). -- George Orwell III (talk) 02:59, 28 May 2015 (UTC)[reply]

┌─────────────────────────────────┘
 Believe it or not, I understand the problem from the beginning to the end and let me think about it. — Ineuw talk 03:37, 28 May 2015 (UTC)[reply]

2015-05-29[edit]

  • You may have to accept that wherever calculations are done, the use the calc() function will be required for close cross browser support.
    • @Ineuw: - Like I mentioned earlier, once I set font-size to calc((14 / 16) * 1.00em) in my vector.css, the bulk of Vector becomes aligned with say Chrome or FireFox (default view/settings) for the most part. Its when subsequent modules and/or extensions that were initially created under monobook then later "tweaked" to accommodate Vector are applied is when the divergences start to appear then multiply in short order. -- George Orwell III (talk) 08:36, 30 May 2015 (UTC)[reply]
  • The lined .svg background would be a good exercise and a busman's holiday for me. I measured the current line spacing on /Lofas and it's seems 20px -21px, please correct me if I am wrong. Can you let me how large the .svg image you would need for your tests?
    • See File:Lineheight22.gif (currently applied) and File:Lineheight21.gif for the actual files being used. You see they don't have to be large at all - what we need is for the svg to be dynamic (if possible) that means when I change the text-size in IE's browser menu, the line height should change as well regardless of larger or smaller being selected. Only the default state of the image needs to be exact (in px where 96px = 1 inch). Right now, even the default site logos are not dynamic (note- zooming in and out is not what I mean here). -- George Orwell III (talk) 08:36, 30 May 2015 (UTC)[reply]
  • Here is a page that might be of interest for you. awesome css3 features you can finally use — Ineuw talk 01:23, 30 May 2015 (UTC)[reply]

2015-05-30[edit]

George Orwell III: I uploaded This file and will upload another with a light colored background, but the dynamics are done with code. At least that's what I think from reading this: svgdiscovery.com — Ineuw talk 02:42, 31 May 2015 (UTC)[reply]

Ping|Ineuw: Is it me or is the 21st pixel also transparent? I ask because I don't see how a "line" can be generated when "repeat" attribute(s) are set once the image is made the background without one. Fwiw.... I couldn't get pixels 1 thru 20 to remain transparent in the .gif format too but transparency isn't all that important since we are setting the image as the background -- overriding the default off-whitish current RGBa color Vector uses now. --- George Orwell III (talk) 02:53, 31 May 2015 (UTC)[reply]
Uploaded another,— Ineuw talk 03:42, 31 May 2015 (UTC)[reply]

2015-05-31[edit]

@George Orwell III: Stupid me. Tried to add the line on the top (for over an hour+) but couldn't. Will take a different approach and hoping to have it by tomorrow.— Ineuw talk 04:19, 1 June 2015 (UTC)[reply]


2015-06-01[edit]

@George Orwell III: I uploaded SVG image with a 2 pixel top border. can you please try it? - Ineuw talk 04:03, 2 June 2015 (UTC) This is how it looked like in inkscape. I posted this because File:6x21px yellow pad.svg looks white. — Ineuw talk 23:37, 2 June 2015 (UTC)[reply]

I don't know what is going on but with IE 11 I'm not seeing any background color or line color at all. I can highlight the dimensions selected from the file page just fine however.

The other point I might not have made clear is Vector applies a negative 1 px to the area right under the tabs so putting the line on top would defeat this built in work around for height (basically to account for the baby blue-ish border). The line should be always 1 px in height as well. -- George Orwell III (talk) 23:50, 3 June 2015 (UTC)[reply]

Have you looked at my accompanying screen capture of Inkscape? The black line on top is 2 pixels high. But no matter, I will try it as often as necessary, to get it right. — Ineuw talk 23:57, 3 June 2015 (UTC)[reply]
P.S. I will increase the black line by another pixel.
@Ineuw: I like what I saw in the inkscape grab but have you looked at File:Lineheight22.gif in it as a guide? Also note the thumbnail section of file history between my gif and your svg(s) - I don't see anything but the checkered background indicating transparency. How about you? -- George Orwell III (talk) 00:07, 4 June 2015 (UTC)[reply]

2015-06-03 GOIII[edit]

@George Orwell III: just uploaded another file File:6x21x3px yellow pad.svg can you please try this? — Ineuw talk 00:54, 4 June 2015 (UTC)[reply]

Uploaded a modified 6x21x2px as well.— Ineuw talk 01:02, 4 June 2015 (UTC)[reply]

Now that one I can see just fine but not sure why you are making the line 3px high? Vector makes a line-height of 22.4 px which is modified to a even 22px on User:George Orwell III/Lofas. So we'd "like" a svg with a white, yellow or transparent background for the 1st to 21st px from the top down and the 22nd be any color. The width can be 6 or 7 px wide, it doesn't seem to make any difference to me. -- George Orwell III (talk) 01:13, 4 June 2015 (UTC)[reply]
There is another one with 21 x 6 x 2px. The 3px was in case the black is not visible. — Ineuw talk 03:59, 4 June 2015 (UTC)[reply]

2015-06-06[edit]

@George Orwell III: Using this background image, I edited my vector.css and pointed it to this sandbox but it's still a no-go. Can you please take a look at it whenever.

I am also confused a bit about your specifications mentioned in previous post. To be clear, the overall dimensions of my image including the back strips is 21 pixels for both of my uploads. Correct me if I am wrong, but that's the measurement understood from your .gif which I downloaded and measured.

Please pardon my interference as I know this question was neither intended for me nor within my realm of knowledge.

Shouldn't the capitalisation of page-User_ineuw_Sandbox7 match that of the HTML within the sandbox? If so perhaps page-User_Ineuw_Sandbox7 might work better?

Of course this might be a known shortcut and I am being needlessly pedantic, in which case please pardon my wasting your time. AuFCL (talk) 23:00, 6 June 2015 (UTC)[reply]

"Pardon wasting my time?" he, he. Your input is valuable and I will check the GO3 original.:-)
{?{ping|AuFCL}} you are absolutely right. Did I hear GO3 cursing me out again? — Ineuw talk 23:23, 6 June 2015 (UTC)[reply]
Sheer dumb luck upon my part. See, I can still be civil to those who have earned respect. Transgressors hereby re-warned. AuFCL (talk) 00:36, 7 June 2015 (UTC)[reply]
Not cursing anybody here, but the last 2 hours with that Inkscape program is another story; it seems too advanced for me to master. Too bad cause it seems like the only program that will create heights or widths in sub pixels for image files. 22.40px in height would be great 'cause that is what Vector gives us by default and would mean far less user or page specific changes need to be made the "normal" .css settings. And I see now -- with the benefit of Sandbox 7 -- that the "lined paper" effect could be "perfect" as well if it we had an image with 0.20px line color on top + 22.0px of background color in the middle + 0.20px line color on the bottom for that 22.40px Vector total. I'm going to go dig up my old irfanview software and see if I have better luck with that in the meantime. Ideas? Comments? Suggestions? -- 02:23, 7 June 2015 (UTC)
I have the identical problem with Inkscape, the learning curve is very tough. I admit to cheating, by creating a .png file in Irfanview and opening it in Inkscape, modifying by the sweat of my eyebrows and saved it as an .svg. — Ineuw talk 02:30, 7 June 2015 (UTC)[reply]
I can do it for you, if you want. — Ineuw talk 02:32, 7 June 2015 (UTC)[reply]
A minor problem cropped up. Irfanview cannot make an image in fractional pixel. So, I made a .png of one 6x1blue + one 6x10yellow and stacked them on top of each other 10+1+10+1 ... import iy into Inkscape and save it as .svg.— Ineuw talk 02:47, 7 June 2015 (UTC)[reply]
@George Orwell III: Uploaded a new image for test - until I get the hang of Inkscape. File:6x22yell&blu.svg
Thanks I'll check it out. You might be onto something by creating a png first and then modifying it in inkscape. I'm thinking I'll try a 7px by 23px png and try to trim 0.30px from the top and bottom of it in inkscape (or something like that). -- George Orwell III (talk) 03:12, 7 June 2015 (UTC)[reply]
Good luck, I couldn't get my vector.css to insert the background in Sandbox 7. Can you look at my vector.css, and let me know what I did wrong again? — Ineuw talk 03:17, 7 June 2015 (UTC)[reply]

2015-06-07[edit]

Well that was a big honkin' waste of time - not only is there no way to consistently reproduce a line-height of 22.4px for a 14px font-size (vector default) but it will never dynamically "multiply" correctly as well (per browser agent). The "new" Css scheme using background-size --> background-origin rounds any percentage or real number with a fractional remainder into it's nearest whole number (22.40px will always become 22.0px; 22.50px will always become 23.00px). I've moved on to looking for image-less solutions but its the same story; nothing will line up perfectly unless the calculated values begin with sane defaults (font-size: 1.00em [= 16px] & line-height: 1.5 [= 24px]). We could then safely divide/multiply by 2, 4, or 8 for the needed margins, padding etc. found through out most of our works. I just have to find a way to propose something like this so folks can understand it! -- George Orwell III (talk) 11:10, 7 June 2015 (UTC)[reply]

The current setting is font-size:14px and line-height:21px. Try proposal your 16 fs, and 24 lh on a sample page and see how the community responds.— Ineuw talk 17:42, 7 June 2015 (UTC)[reply]
My "testbed" was based on a calculated font-size: 0.8750em (14px) and switched between a line-height: 1.5715 (22px) & a line-height: 1.5 (21px) at various stages. Neither line-height is whole number "friendly"; 21 can only be divided/factored by 3 or 7; 22 by 2 or 11. :(

Vector's defaults are also based on a calculated font-size: 0.8750em (14px) but uses a line-height: 1.6 (22.40px); even worse than my testbed when it comes to being "whole-number friendly".

The problem with just a mock-up of 16 fs & 24lh for proposal is the viewport(s) involved. I have more than one laptop but hardly put them to use. Same with the mobile phone. What I typically work/play on are all ~26in/~1080p or higher viewport wise. I'm probably not the norm and there lies the last factor. Its all explained nicely HERE; Fig. 2. depicts exactly why I have concerns with just proposing new settings (& waiting for integration with Mobile Mode [16.0px fs & 26.40 lh] seems farther and farther everyday too). -- George Orwell III (talk) 18:29, 7 June 2015 (UTC)[reply]

I went a step further and converted one paragraph to 16 x 24 here. Also checked the Macbook 13" laptop and it looks very good in both Firefox and Safari [the 5th browser of my collection, and which I forgot about. :-)]. A cellphone, or a tablet I don't have so I can't comment. For me, it's nice, and clear, easy to read, but who knows about community acceptance. Perhaps we could "convince" them if they are aware of the advantages for them. — Ineuw talk 19:30, 7 June 2015 (UTC)[reply]
@George Orwell III:Hey teach, Modified my common.css temporarily and uploaded the results with some info.— Ineuw talk 01:03, 8 June 2015 (UTC)[reply]

2015-06-12[edit]

GO3, Have you considered using millimetric measurement? It does accept fractional values.— Ineuw talk 23:54, 11 June 2015 (UTC)[reply]

I don't believe mm is a relative unit of measurement; its absolute isn't it? I'll have to look into it I suppose.

At any rate, the problem is not having fractions per say but fractions that. . .

  • have decimal equivalents that result in more than an equivalent calculated value of more than one or two decimal places when it comes to font-size in IE specifically IE9 and higher bug, and/or;
  • have decimal equivalents that result in more than an equivalent calculated value of more than three to four decimal places when it comes the font-size to line-height relationship (14px * 1.6 = 22.2px line-height while 14px * 1.5715 = 22.0px line-height).
The take-away here should be sometimes "fractional" values are desirable and sometimes they are not - it all depends on how much planning and testing goes into determining the baselines and/or defaults. -- George Orwell III (talk) 23:14, 12 June 2015 (UTC)[reply]
By fractional was really meant to say decimal, after all it is a decimal system. I don't think it's a relative unit of measurement, but some use it for some screen measurement. Read a bit about it's use in relation to pixels but would have to read more since I was only fishing. — Ineuw talk 01:52, 13 June 2015 (UTC)[reply]

2015-06-22[edit]

<Poem> extension tag[edit]

@AuFCL: After repeated tries, by now I know that the <poem> extension takes some CSS parameters, like line-height and font-size, but I can't figure out what else. (looked at the documentation) What I am trying to do is to include the "block center" into the tag to eliminate the use of the {{block center/s}} template. 

{{block center/s}}<poem style="line-height:105%; font-size:90%;">
poem poem poem poem poem 
</poem>{{block center/e}}

Above is the tag setup I am using now instead of the combination of two templates + the tag, because the templates pad the top and bottom of the poem (between two paragraphs) unevenly, and I like symmetry. If you have the mind and the time, can you please look at it and see if this can be done? . . Thanks.— Ineuw talk 05:11, 2 June 2015 (UTC)[reply]

The "guts" of the PHP code which implements the poem tag is this:
	public static function renderPoem( $in, $param = array(), $parser = null, $frame = false ) {
		// using newlines in the text will cause the parser to add <p> tags,
		// which may not be desired in some cases
		$newline = isset( $param['compact'] ) ? '' : "\n";

		$tag = $parser->insertStripItem( "<br />", $parser->mStripState );

		// replace colons with indented spans
		$text = preg_replace_callback( '/^(:+)(.+)$/m', array( 'Poem', 'indentVerse' ), $in );

		// replace newlines with <br /> tags unless they are at the beginning or end
		// of the poem
		$text = preg_replace(
			array( "/^\n/", "/\n$/D", "/\n/" ),
			array( "", "", "$tag\n" ),
			$text );

		// replace spaces at the beginning of a line with non-breaking spaces
		$text = preg_replace_callback( '/^( +)/m', array( 'Poem', 'replaceSpaces' ), $text );

		$text = $parser->recursiveTagParse( $text, $frame );

		$attribs = Sanitizer::validateTagAttributes( $param, 'div' );

		// Wrap output in a <div> with "poem" class.
		if ( isset( $attribs['class'] ) ) {
			$attribs['class'] = 'poem ' . $attribs['class'];
		} else {
			$attribs['class'] = 'poem';
		}

		return Html::rawElement( 'div', $attribs, $newline . trim( $text ) . $newline );
	}
In summary this translates as
  • Handle leading ":"s as indent markers on each line;
  • Convert all internal newlines into <br/>s;
  • Convert all initial spaces on each line into &nbsp;s and
  • Wrap the result of the above inside <div class="poem">…</div>
All-in-all I suspect the simplest way of achieving the result you are after might to do something like: <div class="poem" style="line-height:105%; font-size:90%; margin: 0 auto 0 auto; width:200px;">{{lorem ipsum}}</div> which results in:
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Though I stand to be corrected upon this point I truly suspect the poem tag actually throws away any style parameter presented to it altogether. At least none of my experiments to date have ever convinced me anything survives the parser filtering process to pass to the browser. Which documentation did you read which led you to believe otherwise? AuFCL (talk) 08:00, 2 June 2015 (UTC)[reply]
Apologies. Answered my own question above: Here implies style is processed. However as I carried out my experiments inside a ":"-indentation block clearly there are issues with regards what tag wraps/precedes poem. I really dislike this tag (or it dislikes me?) AuFCL (talk) 08:27, 2 June 2015 (UTC)[reply]
You are correct about the use of ":" to indent. That doesn't work. Most of us here use the {{gap}} or {{gap|1em}}. As for a multi-page poem having to be terminated on each page, I figured it out by trial and error and posted somewhere about it.

Thanks for the above poem tag, classes and inheritances are not yet 100% clear to me but hope to catch up to them in this life. I must assume that the 200px is an arbitrary width.— Ineuw talk 17:44, 2 June 2015 (UTC)[reply]

Oops. Yes. The 200px was entirely arbitrary and intended to be modified at your personal discretion (in fact I had originally meant to make that point but demurred on basis I thought it might have been more obvious.) The documentation is clearly old (and if truth be known the PHP I reproduced was from mediawiki 1.25 whereas WikiSource is currently on version 1.26wmf8... so much for Poem being a "stable" extension if this has changed again...)

And I was trying to make a different point about adjacent/wrapping tags being interfered with by <poem>: I have noticed that its style is applied to an inserted empty paragraph before the poem content (resulting in the content appearing to be style-less) if the tag immediately follows a <dl> tag. Guess what the parser turn the construct :text <poem style="guff:enabled;"> content </poem> into? Well to save you the trial here is the result:

<div style="guff:enabled;" class="poem">
<p>content</p>
</div>
which you might further note has created both <div> and <p> tags internally. Which in turn rules out tricks like GOIII's wrapping the whole mess in a styled paragraph tag. Yes poem really is a bit of a hack pushed far beyond its original design. About the only commonly-used template whose effect escapes getting mashed by this process happens to be the {{block center}} family as it is based upon tables… and do not forget there is a push going on to subvert that in the interests of mobile view…

Cans of cans (repeat refrain) of nothing more than worms? AuFCL (talk) 21:48, 2 June 2015 (UTC)[reply]

Additional note: And even then things are not entirely clean. For example compare the behaviour of:
::::{{block centre|width=200px|<poem>{{lorem ipsum}}</poem>}}
with
::::

{{block centre|width=200px|<poem>{{lorem ipsum}}</poem>}}
I shall not waste space showing you the output or analysis (and No, this is not one of those I-need-a-paragraph-space-to-insert-the-right-code cases we are all so familiar with you {{fs85}} et al control freak you. Now laugh—please?); suffice it to state the first case does not work but the latter one does; and the only difference in the input is two added new-lines. The HTML output by the parser is just so embarrassingly wrong (semantically; I cannot fault the syntax!) that I seriously question whether mediawiki was necessarily a sound or even sane choice for WikiSource requirements. I am sure I am only lagging GOIII in expressing this thought. AuFCL (talk) 03:50, 3 June 2015 (UTC)[reply]
I have to check the block center template code, because all the poems in PSM use 90% text. So far for me, <div class="poem" style="line-height:105%; font-size:90%; margin: 0 auto 0 auto; width:200px;">{{lorem ipsum}}</div> is by far the best candidate for the moment. I already used it with a minor variations starting on this page and spanning 3 pages. Also checked the transcluded section here and it looks very good.

My only concern is that with the {{block center}} it always centers without having to specify the width. I write this because I already played with this issue in my sandbox earlier this month, by measuring the longest line and then specifying the width, but that is not a solution. The bloc center template figures out the longest line and sets the margins accordingly, but I don't know hot it does it. — Ineuw talk 04:14, 3 June 2015 (UTC)[reply]

But not if width=some value is specified on the {{block centre}} invocation. What did you think the margin: 0 auto 0 auto; was for if not precisely this (i.e. centering on the result of finding the longest line?) Specifying width subverts/short-cuts this step.

All block center does is to wrap that (again) in a table-cell wrapped in a table. And then it centres that table. None of the actions described in the prior two sentences are really doing anything useful for you (in this particular case) that cannot be expressed just as usefully within the style parameter of the <div>.

Which only leaves the vexed question of those damned newlines that <poem> so conveniently preserves… AuFCL (talk) 04:32, 3 June 2015 (UTC)[reply]

┌─────────────────────────────────┘
 The margin: 0 auto 0 auto; Let's try some samples of different widths with no width specified and see the results.

Lorem ipsum dolor sit amet,

consectetur adipisicing elit,

sed do eiusmod tempor

incididunt ut labore et dolore

magna aliqua. Ut enim ad minim

veniam, quis nostrud

exercitation ullamco laboris

nisi ut aliquip ex ea commodo

consequat. Duis aute irure

dolor in reprehenderit in

voluptate velit esse cillum

dolore eu fugiat nulla

pariatur. Excepteur sint

occaecat cupidatat non


proident, sunt in culpa qui officia deserunt

mollit anim id est laborum. Curabitur pretium

tincidunt lacus. Nulla gravida orci a odio.

Nullam varius, turpis et commodo pharetra, est

eros bibendum elit, nec luctus magna felis

sollicitudin mauris. Integer in mauris eu nibh

euismod gravida. Duis ac tellus et risus

vulputate vehicula. Donec lobortis risus a elit.

Etiam tempor. Ut ullamcorper, ligula eu tempor

congue, eros est euismod turpis, id tincidunt

sapien risus a quam. Maecenas fermentum consequat

mi. Donec fermentum. Pellentesque malesuada nulla

a mi. Duis sapien sem, aliquet nec, commodo eget,

consequat quis, neque. Aliquam faucibus, elit ut

dictum aliquet, felis nisl adipiscing sapien,

sed malesuada diam lacus eget erat. Cras mollis

scelerisque nunc. Nullam arcu. Aliquam consequat.

Curabitur augue lorem, dapibus quis, laoreet et,

pretium ac, nisi. Aenean magna nisl, mollis

quis, molestie eu, feugiat in, orci. In hac

habitasse platea dictumst.

Sub-issue: margin:0 auto 0 auto[edit]

I am not sure what the issue is, unless you deliberately made the width: specification dimensionless, i.e. 200. If I specify 200px this happens:

Lorem ipsum dolor sit amet,

consectetur adipisicing elit,

sed do eiusmod tempor

incididunt ut labore et dolore

magna aliqua. Ut enim ad minim

veniam, quis nostrud

exercitation ullamco laboris

nisi ut aliquip ex ea commodo

consequat. Duis aute irure

dolor in reprehenderit in

voluptate velit esse cillum

dolore eu fugiat nulla

pariatur. Excepteur sint

occaecat cupidatat non


proident, sunt in culpa qui officia deserunt

mollit anim id est laborum. Curabitur pretium

tincidunt lacus. Nulla gravida orci a odio.

Nullam varius, turpis et commodo pharetra, est

eros bibendum elit, nec luctus magna felis

sollicitudin mauris. Integer in mauris eu nibh

euismod gravida. Duis ac tellus et risus

vulputate vehicula. Donec lobortis risus a elit.

Etiam tempor. Ut ullamcorper, ligula eu tempor

congue, eros est euismod turpis, id tincidunt

sapien risus a quam. Maecenas fermentum consequat

mi. Donec fermentum. Pellentesque malesuada nulla

a mi. Duis sapien sem, aliquet nec, commodo eget,

consequat quis, neque. Aliquam faucibus, elit ut

dictum aliquet, felis nisl adipiscing sapien,

sed malesuada diam lacus eget erat. Cras mollis

scelerisque nunc. Nullam arcu. Aliquam consequat.

Curabitur augue lorem, dapibus quis, laoreet et,

pretium ac, nisi. Aenean magna nisl, mollis

quis, molestie eu, feugiat in, orci. In hac

habitasse platea dictumst.

And of I change the 200px into 3.25in this happens:

Lorem ipsum dolor sit amet,

consectetur adipisicing elit,

sed do eiusmod tempor

incididunt ut labore et dolore

magna aliqua. Ut enim ad minim

veniam, quis nostrud

exercitation ullamco laboris

nisi ut aliquip ex ea commodo

consequat. Duis aute irure

dolor in reprehenderit in

voluptate velit esse cillum

dolore eu fugiat nulla

pariatur. Excepteur sint

occaecat cupidatat non


proident, sunt in culpa qui officia deserunt

mollit anim id est laborum. Curabitur pretium

tincidunt lacus. Nulla gravida orci a odio.

Nullam varius, turpis et commodo pharetra, est

eros bibendum elit, nec luctus magna felis

sollicitudin mauris. Integer in mauris eu nibh

euismod gravida. Duis ac tellus et risus

vulputate vehicula. Donec lobortis risus a elit.

Etiam tempor. Ut ullamcorper, ligula eu tempor

congue, eros est euismod turpis, id tincidunt

sapien risus a quam. Maecenas fermentum consequat

mi. Donec fermentum. Pellentesque malesuada nulla

a mi. Duis sapien sem, aliquet nec, commodo eget,

consequat quis, neque. Aliquam faucibus, elit ut

dictum aliquet, felis nisl adipiscing sapien,

sed malesuada diam lacus eget erat. Cras mollis

scelerisque nunc. Nullam arcu. Aliquam consequat.

Curabitur augue lorem, dapibus quis, laoreet et,

pretium ac, nisi. Aenean magna nisl, mollis

quis, molestie eu, feugiat in, orci. In hac

habitasse platea dictumst.

These both behave as I had expected you wanted them to. What was your intent omitting the unit specifier if not implied px? What am I missing, please? AuFCL (talk) 05:23, 3 June 2015 (UTC)[reply]

I was falling asleep and couldn't function properly, I hope you can forgive. At this point I have no clue what I was doing. Talk to you tomorrow. — Ineuw talk 06:00, 3 June 2015 (UTC)[reply]
'Tis O.K. I shall put the confusion in Neutral; engage the Parking Brake; turn off the ignition and hope this monstrosity isn't a diesel? AuFCL (talk)

2015-06-03 AuFCL[edit]

Thanks for being understanding. The missing "px" was a simple oversight due to the above mentioned reasons. Try as I might to adjust my life habits to correspond with down under, still cannot last through the whole (my) night.— Ineuw talk 19:32, 3 June 2015 (UTC)[reply] 

<div class="poem" style="display:table; line-height:105%; font-size:90%; left-margin:auto; right-margin:auto; width:auto; max-width: "></div>

proident, sunt in culpa qui officia deserunt

mollit anim id est laborum. Curabitur pretium

tincidunt lacus. Nulla gravida orci a odio.

Nullam varius, turpis et commodo pharetra, est

eros bibendum elit, nec luctus magna felis

sollicitudin mauris. Integer in mauris eu nibh

euismod gravida. Duis ac tellus et risus

vulputate vehicula. Donec lobortis risus a elit.

Etiam tempor. Ut ullamcorper, ligula eu tempor

congue, eros est euismod turpis, id tincidunt

sapien risus a quam. Maecenas fermentum consequat

mi. Donec fermentum. Pellentesque malesuada nulla

a mi. Duis sapien sem, aliquet nec, commodo eget,

consequat quis, neque. Aliquam faucibus, elit ut

dictum aliquet, felis nisl adipiscing sapien,

sed malesuada diam lacus eget erat. Cras mollis

scelerisque nunc. Nullam arcu. Aliquam consequat.

Curabitur augue lorem, dapibus quis, laoreet et,

pretium ac, nisi. Aenean magna nisl, mollis

quis, molestie eu, feugiat in, orci. In hac

habitasse platea dictumst. 

<poem style="display:table; line-height:105%; font-size:90%; left-margin:auto; right-margin:auto; width:auto; max-width: "></poem>


proident, sunt in culpa qui officia deserunt
mollit anim id est laborum. Curabitur pretium
tincidunt lacus. Nulla gravida orci a odio.
Nullam varius, turpis et commodo pharetra, est
eros bibendum elit, nec luctus magna felis
sollicitudin mauris. Integer in mauris eu nibh
euismod gravida. Duis ac tellus et risus
vulputate vehicula. Donec lobortis risus a elit.
Etiam tempor. Ut ullamcorper, ligula eu tempor
congue, eros est euismod turpis, id tincidunt
sapien risus a quam. Maecenas fermentum consequat
mi. Donec fermentum. Pellentesque malesuada nulla
a mi. Duis sapien sem, aliquet nec, commodo eget,
consequat quis, neque. Aliquam faucibus, elit ut
dictum aliquet, felis nisl adipiscing sapien,
sed malesuada diam lacus eget erat. Cras mollis
scelerisque nunc. Nullam arcu. Aliquam consequat.
Curabitur augue lorem, dapibus quis, laoreet et,
pretium ac, nisi. Aenean magna nisl, mollis
quis, molestie eu, feugiat in, orci. In hac
habitasse platea dictumst.

The above attempts are also known as the style="kitchen sink;" approach. I copied from the {{Block center}} whatever settings I thought that would improve it . . . and it resolved the width issue but not the centering. — Ineuw talk 20:44, 3 June 2015 (UTC)[reply] 

<div class="poem" style="display:table; line-height:105%; font-size:90%; margin-left:auto; margin-right:auto; width:auto; max-width: "></div>

proident, sunt in culpa qui officia deserunt

mollit anim id est laborum. Curabitur pretium

tincidunt lacus. Nulla gravida orci a odio.

Nullam varius, turpis et commodo pharetra, est

eros bibendum elit, nec luctus magna felis

sollicitudin mauris. Integer in mauris eu nibh

euismod gravida. Duis ac tellus et risus

vulputate vehicula. Donec lobortis risus a elit.

Etiam tempor. Ut ullamcorper, ligula eu tempor

congue, eros est euismod turpis, id tincidunt

sapien risus a quam. Maecenas fermentum consequat

mi. Donec fermentum. Pellentesque malesuada nulla

a mi. Duis sapien sem, aliquet nec, commodo eget,

consequat quis, neque. Aliquam faucibus, elit ut

dictum aliquet, felis nisl adipiscing sapien,

sed malesuada diam lacus eget erat. Cras mollis

scelerisque nunc. Nullam arcu. Aliquam consequat.

Curabitur augue lorem, dapibus quis, laoreet et,

pretium ac, nisi. Aenean magna nisl, mollis

quis, molestie eu, feugiat in, orci. In hac

habitasse platea dictumst. 

<poem style="display:table; line-height:105%; font-size:90%; margin-left:auto; margin-right:auto; width:auto; max-width: "></poem>


proident, sunt in culpa qui officia deserunt
mollit anim id est laborum. Curabitur pretium
tincidunt lacus. Nulla gravida orci a odio.
Nullam varius, turpis et commodo pharetra, est
eros bibendum elit, nec luctus magna felis
sollicitudin mauris. Integer in mauris eu nibh
euismod gravida. Duis ac tellus et risus
vulputate vehicula. Donec lobortis risus a elit.
Etiam tempor. Ut ullamcorper, ligula eu tempor
congue, eros est euismod turpis, id tincidunt
sapien risus a quam. Maecenas fermentum consequat
mi. Donec fermentum. Pellentesque malesuada nulla
a mi. Duis sapien sem, aliquet nec, commodo eget,
consequat quis, neque. Aliquam faucibus, elit ut
dictum aliquet, felis nisl adipiscing sapien,
sed malesuada diam lacus eget erat. Cras mollis
scelerisque nunc. Nullam arcu. Aliquam consequat.
Curabitur augue lorem, dapibus quis, laoreet et,
pretium ac, nisi. Aenean magna nisl, mollis
quis, molestie eu, feugiat in, orci. In hac
habitasse platea dictumst.

Baby steps.

Ouch! Took me ages to spot it: Wrong keywords! Substitute left-margin with margin-left and <right-margin with margin-right everywhere. Now it centres as well for me at least.

Next step.

I think you may have misread the template code. The construct (there) which reads {{#if:{{{max-width|}}}| max-width:{{{max-width}}};|}} does not default to max-width:&#32; as you interpreted it to but to the—nothing—between the vertical-bar and final }}. So this still (ought to) work/s: 

<div class="poem" style="display:table; line-height:105%; font-size:90%; margin-left:auto; margin-right:auto; width:auto;"></div>

proident, sunt in culpa qui officia deserunt

mollit anim id est laborum. Curabitur pretium

tincidunt lacus. Nulla gravida orci a odio.

Nullam varius, turpis et commodo pharetra, est

eros bibendum elit, nec luctus magna felis

sollicitudin mauris. Integer in mauris eu nibh

euismod gravida. Duis ac tellus et risus

vulputate vehicula. Donec lobortis risus a elit.

Etiam tempor. Ut ullamcorper, ligula eu tempor

congue, eros est euismod turpis, id tincidunt

sapien risus a quam. Maecenas fermentum consequat

mi. Donec fermentum. Pellentesque malesuada nulla

a mi. Duis sapien sem, aliquet nec, commodo eget,

consequat quis, neque. Aliquam faucibus, elit ut

dictum aliquet, felis nisl adipiscing sapien,

sed malesuada diam lacus eget erat. Cras mollis

scelerisque nunc. Nullam arcu. Aliquam consequat.

Curabitur augue lorem, dapibus quis, laoreet et,

pretium ac, nisi. Aenean magna nisl, mollis

quis, molestie eu, feugiat in, orci. In hac

habitasse platea dictumst. 

<poem style="display:table; line-height:105%; font-size:90%; margin-left:auto; margin-right:auto; width:auto;"></poem>


proident, sunt in culpa qui officia deserunt
mollit anim id est laborum. Curabitur pretium
tincidunt lacus. Nulla gravida orci a odio.
Nullam varius, turpis et commodo pharetra, est
eros bibendum elit, nec luctus magna felis
sollicitudin mauris. Integer in mauris eu nibh
euismod gravida. Duis ac tellus et risus
vulputate vehicula. Donec lobortis risus a elit.
Etiam tempor. Ut ullamcorper, ligula eu tempor
congue, eros est euismod turpis, id tincidunt
sapien risus a quam. Maecenas fermentum consequat
mi. Donec fermentum. Pellentesque malesuada nulla
a mi. Duis sapien sem, aliquet nec, commodo eget,
consequat quis, neque. Aliquam faucibus, elit ut
dictum aliquet, felis nisl adipiscing sapien,
sed malesuada diam lacus eget erat. Cras mollis
scelerisque nunc. Nullam arcu. Aliquam consequat.
Curabitur augue lorem, dapibus quis, laoreet et,
pretium ac, nisi. Aenean magna nisl, mollis
quis, molestie eu, feugiat in, orci. In hac
habitasse platea dictumst.

Yet another step.

I had an argument prepared along the lines of display:table being a dire plot of a certain GOIII for mobile compatibility and/or possibly mere contextual support for the |title= logic of {{block center}}. However removing or altering display: breaks centring (and I admit I don't entirely know why—got lost and gave up trying to trace the CSS tree!) so that turns out to be essential.

Which leaves width:auto;. As this is already the default, losing that ought to change nothing: 

<div class="poem" style="display:table; line-height:105%; font-size:90%; margin-left:auto; margin-right:auto;"></div>

proident, sunt in culpa qui officia deserunt

mollit anim id est laborum. Curabitur pretium

tincidunt lacus. Nulla gravida orci a odio.

Nullam varius, turpis et commodo pharetra, est

eros bibendum elit, nec luctus magna felis

sollicitudin mauris. Integer in mauris eu nibh

euismod gravida. Duis ac tellus et risus

vulputate vehicula. Donec lobortis risus a elit.

Etiam tempor. Ut ullamcorper, ligula eu tempor

congue, eros est euismod turpis, id tincidunt

sapien risus a quam. Maecenas fermentum consequat

mi. Donec fermentum. Pellentesque malesuada nulla

a mi. Duis sapien sem, aliquet nec, commodo eget,

consequat quis, neque. Aliquam faucibus, elit ut

dictum aliquet, felis nisl adipiscing sapien,

sed malesuada diam lacus eget erat. Cras mollis

scelerisque nunc. Nullam arcu. Aliquam consequat.

Curabitur augue lorem, dapibus quis, laoreet et,

pretium ac, nisi. Aenean magna nisl, mollis

quis, molestie eu, feugiat in, orci. In hac

habitasse platea dictumst. 

<poem style="display:table; line-height:105%; font-size:90%; margin-left:auto; margin-right:auto;"></poem>


proident, sunt in culpa qui officia deserunt
mollit anim id est laborum. Curabitur pretium
tincidunt lacus. Nulla gravida orci a odio.
Nullam varius, turpis et commodo pharetra, est
eros bibendum elit, nec luctus magna felis
sollicitudin mauris. Integer in mauris eu nibh
euismod gravida. Duis ac tellus et risus
vulputate vehicula. Donec lobortis risus a elit.
Etiam tempor. Ut ullamcorper, ligula eu tempor
congue, eros est euismod turpis, id tincidunt
sapien risus a quam. Maecenas fermentum consequat
mi. Donec fermentum. Pellentesque malesuada nulla
a mi. Duis sapien sem, aliquet nec, commodo eget,
consequat quis, neque. Aliquam faucibus, elit ut
dictum aliquet, felis nisl adipiscing sapien,
sed malesuada diam lacus eget erat. Cras mollis
scelerisque nunc. Nullam arcu. Aliquam consequat.
Curabitur augue lorem, dapibus quis, laoreet et,
pretium ac, nisi. Aenean magna nisl, mollis
quis, molestie eu, feugiat in, orci. In hac
habitasse platea dictumst.

Now I think this is a minimal working set. I hope you and your army of browsers concur? AuFCL (talk) 22:45, 3 June 2015 (UTC)[reply]

It goes to show you never trust a Hungarian doing the coding. Even though I looked at the template, I didn't copy it, as I was so sure I didn't make a mistake, (my weakness). My only excuse is that even Einstein made numerous calculation errors AND he was sloppy as well. At least I image things as they are not, but put them down on paper very neatly.

All browsers are very happy. IE 11, Comodo Dragon (Chrome/Chromium), and Opera, and naturally Firefox. My next step would be check the two which spans across pages, (probably the </div>) and use the one that works for a template with optional parameters for line-height, font-style, font-size, and perhaps text alignment. My gratitude for all your help.— Ineuw talk 23:09, 3 June 2015 (UTC)[reply]

I trust old Hungarians to be cunning, subtle, devious and entertaining. And as for mistakes I can only plead I made quite a few of them during this episode as well. With any luck we are both still learning. (Oh, diesel: Engine Stop of course.) AuFCL (talk) 00:54, 4 June 2015 (UTC)[reply]

Dyslexia[edit]

Aha! Regrettably above turns out to be yours (you were looking for "fslnInherit" not "fsInherit".) I did try but gave up when I could not find the precise match (no, not entirely being smug: I simply did not entertain the thought of alternatives.) Lucky we've got the Washington cavalry. AuFCL (talk) 04:04, 30 June 2015 (UTC)[reply]

Bravo. But now must think in which one of my templates I saw it used. Must be one of the more recently edited ones.— Ineuw talk 05:01, 30 June 2015 (UTC)[reply]
Bingo, I copied it (wrong) from Template:Font-size90%/s. Actually, it's easy to find a particular word with this search engine. — Ineuw talk 05:09, 30 June 2015 (UTC)[reply]
Retrieved from "https://en.wikisource.org/w/index.php?title=User_talk:Ineuw/Archives/2015-06-30&oldid=6005059"