Hello, Viewer2, and welcome to Wikisource! Thank you for joining the project. I hope you like the place and decide to stay. Here are a few good links for newcomers:
Add the code {{active projects}}, {{PotM}} or {{CotW}} to your page for current wikisource projects.
You can put a brief description of your interests on your user page and contributions to another Wikimedia project, such as Wikipedia and Commons.
I hope you enjoy contributing to Wikisource, the library that is free for everyone to use! In discussions, please "sign" your comments using four tildes (~~~~); this will automatically produce your IP address (or username if you're logged in) and the date. If you need help, ask me on my talk page, or ask your question here (click edit) and place {{helpme}} before your question.
Again, welcome!
And just a doubt—are you/were you the (extremely kind) (string of) IP(s) who has (had?) been helping me and DanielTom with A History of Mathematics? If you're not, very sorry. :) If you are, why, thank you very much. (Is it just me, or are there more parentheses here than are good for me?) Best regards,—Clockery Fairfeld (talk) 05:16, 9 November 2013 (UTC)[reply]
((parentheses) are) but the )dietary fibre( of prose. Nobody likes dietary fibre no matter how many experts tell you it is really good for you.
Me, kind? Never! So it must have been somebody else.
The dates I found are all so vague! At least Heron of Byzantium a.k.a. Heron the Younger is easy, he wrote practically in the early Middle Ages, so is obviously a different person.
However, Heron the Elder lived over a hundred years (maybe even 150) before "normal" Heron of Alexandria. How can this be the same person? I am quite confused, so if you can do any better please go ahead and the very best of luck to you!
Well, I query both "believe" and "mathematician" in the sense you have just used them, but I am certainly entertaining the idea!
Or, looking at the matter in a completely different way, Florian Cajori seems to think there was only one "Heron of Alexandria", even though he uses the names:
"Heron" - given credit for having a method for extracting square roots.
"Heron" - credit for wring about Perseus (200-100BC) writing a book on spirics.
"Heron the Elder of Alexandria" and "Heron the Younger" - "the Elder" is here described as "pupil of Ctesibius", possibly Ct.'s son and inventor of the hydraulic organ, water-clock, catapult, eolipile and "Herons fountain"; "the Younger" is noted as living in the "seventh or eighth century" AD; a possible alternate author of Treatise on the Dioptra and that Geodesy might be a derivative work. Florian finally notes on this page: "no reliable evidence has been found that there actually existed a second mathematician by the name of Heron."
"Heron" - as surveyor, formula writer, having similarities with Egyptians.
"Heron". Florian ends the chapter on The First Alexandrian School, with the statement "We have now sketched the progress of geometry down to the time of Christ."
Stepping right outside of Florian for a moment, The New International Encyclopædia/Hero of Alexandria sums up all my doubts about the dating of "Hero of Alexandria." For some reason the Wikipedia article has settled only on the later dates, but credits their "Hero" with all the inventions. Also by making him post-Christ, they have moved him out of the scope considered by Florian in his chapter on The First Alexandrian School!
Putting this all together, I have a feeling that there was one "Hero of Alexandria" a.k.a. "Heron" a.k.a "the Elder"; and one "Heron of Byzantium" a.k.a. "the Younger" living about 800-900 years apart. The first was a (perhaps lesser) mathematician, surveyor and inventor; and the second an artist/engineer designer of weoponry. I think the dates on the Wikipedia article cannot be supported, unless that article describes a "Heron" not known to Florian, who is perhaps not entitled to some of the inventions and writings gathered there. In short, I think every fact available has been mushed into that article, to the point where I was no longer sure it is describing only one person.
While you are thinking on all of that, may I make a few further suggestions? The basic problem seems to me that taken together, Florian's and wikipedia's Hero/n of Alexandria information lead to contradictions. That there was another Heron of Byzantium does not create an issue, but I feel the two weakest points about H of A are:
the Author:Ctesibius connection (son, pupil). If true it describes a Heron at the extreme earliest end of the c.155BC – 10AD possible birth date range.
that confident 10AD!
At least one of these two must be thrown away if there is any chance of there really being a single "Heron of Alexandria."
But if you entertain the possibility of two (or more… but lets not open that can of worms, at least yet.) the possibilities include:
(considering Ctesibius is considered "Greek" but is living in Ptolemaic Alexandria, and might have been a head of the Museum) could there have been a "Greek culture" and an "Egyptian (culture)" Hero living at slightly different periods in the same city?
Or (bearing in mind there were lots of Alexandrias, a Heron in each of different cities of the same name?
I still think "Heron the Elder" is the same as Hero of Alexandria, but I am looking up dates at other sources. The WP article is definitely wrong – notice all the inventions they attribute to this "Hero of Alexandria"; it's not just its dates that are confusing. It may take me some time to reply because I have other things in my head. (In fact, you were typing the book faster than I was reading it, so I had to stop for a while. Amazing work you do.) DanielTom (talk) 00:03, 2 December 2013 (UTC)[reply]
I am happy with that. I look forward to your conclusions.
please have a look at Page:Mexico of the Mexicans.djvu/30 and let me know if this is the effect you wish to achieve. If so, it would be fairly easy to incorporate in a template (if it doesn't already exist.)
I would consider this a form of paragraph heading, perhaps? Viewer2 (talk) 22:01, 8 December 2013 (UTC)
Viewer 2, Yes, the example you present is exactly what should be used. So, the question now is how to make a template for this book. Thank you for your help. This is a book that has no template for the solution. —Maury (talk) 14:20, 9 December 2013 (UTC)[reply]
In short it "clears" both the left and right margins beneath images or "floating" blocks of text (the new {{inset heading}} is an example of this.) If that does not make sense, think of it as being a hint to the browser to automatically add blank lines to the main text up to a point where the next line could be drawn across the full width of the page. (Note I said "could be", because the following text is allowed to start stacking up images and floats from afresh.)
I think from memory I have used {{-}} in two situations with regards to "Mexico of the Mexicans":
On Page:Mexico of the Mexicans.djvu/20, I put a {{-}} into the footer, because "Motecuhzoma II, The Great." pushes down below the bottom of the screen on narrow displays, and this tells the browser to make the display a little bit deeper to allow for this. Why in the footer? Because after the page is transcluded and combined with the next page this effect will not be necessary due to more text (from the page ahead) being available to flow around the heading.
On Page:Mexico of the Mexicans.djvu/23, I put a {{-}} into the "paragraph-marking" double-carriage-return following "the Spaniards were almost decimated." This addresses an issue relating to the opposite case: on a very wide display, the two headings "El Noche Triste." and "The Siege of Mexico." risk overlapping (actually the way I did the indentation they will stack up, cascading-indent style.) If there is already enough vertical space available, the {{-}} does nothing, but if not, it will add more blank lines between the paragraph ending "the Spaniards were almost decimated", and the one starting "Cortés now found it necessary" so as to make space for "The Siege of Mexico." to fit normally.
There was a time, a time of so very long-ago, when I actually liked math in the form of the slide rule and later - punch cards and binary 1 and 0 code. Way back then I also loved playing in the oh! ever so cold snow. But that was a time, a time of so very long-ago. Now I enjoy good health but neither math nor cold nor code. I now prefer a good illustrated paper book, sitting by the fireside with my collie, and my wife away shopping. :0) —Maury (talk) 04:37, 10 December 2013 (UTC)[reply]
Thanks, BTW You might want to review the existing pages as well, because some images were previously added, meaning that currently there is a style inconsistency across the images.
You are right and, truth be known, I have not been entirely consistent in my own stylings, having eventually settled on using GIF versions of completely re-drawn line diagrams for my later attempts. I quite agree SVG is the "technical best solution," however it is a format I know little about (I have SVG-capable viewing programs, but no graphical editor available to me at present, and as stated above, have so far been unsuccessful in satisfactorily hand-attacking the internal XML.)
Every single existing SVG in that project currently has issues regarding large areas of unnecessary white space (in short the image cropping is inconsistent) so from my perspective eventually every single page will have to be revisited in any case. I did try a few modifications as you've probably already seen, but not with any consistent degree of success.
Hope this does not come across as too heavy-handed. I am currently a fair bit more sleep-deprived than I really want to be.
I came up with Template:FreedImg/basic mode the other day to prove to myself (again) the nuances involved with the part of wiki mark-up dealing with images floated to the right or to the left. If you have the time and would be as so kind to verify/replicate my findings (so that the last example is the way "forward" for this left/right aspect under {{FI}}) that would be one less thing on my to-do list.
If this proves viable, the chances of "doing away" with some of the inherits in the CSS can only increase if most browsers act the same as my lowly IE8 does. Thanks in advance. -- George Orwell III (talk) 22:07, 17 December 2013 (UTC)[reply]
Happy to help in any way I can.
Not sure about your structural style on that page—did you intend the code blocks enclosed in <nowiki> blocks to be representations of the wikicode presented for rendering, or of the HTML produced by the wiki, as it looks to me to be more the latter—which might confuse the intended audience.
Or maybe it is I who am being confused. Which does not auger entirely well for my usefulness to you in this exercise.
Sorry - I'm having a brain fart and can't remember how to output the source HTML underneath each example after executed/saved. My main concern is to show using |right in a wiki mark-up File: string produces a DIV that uses a class definition to accomplish the float (with the unwanted break when taking place within a paragraph block thus no opening P tag) rather than using an inline float:right approach. And second (if the first is true) why not just assign the same definition in the css for IMG instead also accomplishing the same float, producing proper opening & closing P tags all with no unwanted reurns or breaks. Thanks again. -- George Orwell III (talk) 23:32, 17 December 2013 (UTC)[reply]
And funny thing is that my initial impression had been that you had cleverly constructed the examples to avoid highlighting that very point (i.e. the div-insertion-adding-an-unwanted-line-break)! Maybe I am just too suspicious/paranoid. How about I add a naïve case which demonstrates this result. And would you be happy if I added some (as compact as I can make them) <syntaxhighlight> blocks containing captures of the HTML which hits my browser for each case?
Trying to ask all the "dumb questions" up front so that you really can offload this matter without tying you up too much further. Thanks for your patience. Viewer2 (talk) 23:48, 17 December 2013 (UTC)[reply]
Well I didn't think folks would understand the implications for the instance where no opening P tag is being generated so I just figured it best to just show the [unwanted] result - the break/LR.
Aha!So this: →← has the side-effect of inserting an unwanted LF for you in IE (as it does for me in FF);
—whereas this: →← has no such impact?
If so, then why does the active code in what I believe to be the relevant section of {{FreedImg/basic mode}} contains: →
←? For me at least the added <span>s "re-corrects" and hides the bad behaviour. N'cest pas?
—which it interestingly does not do so here? Hmm.
Got it! It is the further wrapping in a <div> which apparently does the magic, viz:
'Ere we go →← again guv'nor!
<p>
So this: →
</p><divclass="floatright"><aclass="image"href="/wiki/File:Example.png"title=""><imgwidth="172"height="178"src="//upload.wikimedia.org/wikipedia/commons/7/70/Example.png"alt="Example alt text"></img></a></div><p>
← has the side-effect of inserting an unwanted LF …
<brstyle="clear:both;"></br></p>
┌─────────────┘ I am guessing none of this activity was quite what you really wanted me to do, but it has turned out to be a day of interruptions and general confusion (mainly mine!) I ended up recapturing the output-HTML blocks as the minor differences were distracting me. Turns out all of them were just reordering of internal tags and not at all otherwise significant.
One thing might be useful to you: turns out <syntaxhighlight> accepts an optional enclose, with default value "pre" (one long line), other options "div" or "none" (see MW:Extension:SyntaxHighlight_GeSHi#Default_DIV_Based_Rendering). I could not discern any effective differences between the effects of "div" or "none", but either of them enable line wrapping within the parsed block. I left it there (honestly I forgot to remove it) but there is probably no advantage in specifying style="overflow:auto;" any more with this option enabled.
I am at a bit of a loss as to how to reproduce the extra-unwanted-paragraph-break-effect where the floated image was relocated within the constraints of your documentation. Is this something which happens to "work" for me, yet which "breaks" under Internet Explorer? Viewer2 (talk) 06:28, 18 December 2013 (UTC)[reply]
That's what I'm spinning my wheels over. Its not that [[File:Example.png|right|alt=Example alt text]] gives me a line break similar to the one Ineuw brought up when he applied {{FI}} a couple of days ago right now... but I could of swore it did. The only "differnce" between the three ways to "float" right here under IE8 is the top & bottom margins/padding are somewhat bloated when it comes to using the
[[File:Example.png|right|alt=Example alt text]] approach. Other than that, I don't "see" any break BUT I don't get the automatic opening & closing P tags for that instance when I look at the HTML source either. I'll bet that lack of P tag generation is somehow causing that break --> but only under certain conditions (Like when I try to mimic it in a template?) -- George Orwell III (talk) 07:36, 18 December 2013 (UTC)[reply]
So all the "second set of eyes" here can suggest is that I see the same thing—and quietly—share much the same suspicions—as you apparently do. I shall repeat it here, but my example from above, lit.:
text text texty text →[[File:Example.png|right|alt=Example alt text]]← more text, yet more text. Do the arrow heads look like →← this?{{-}}
fails thus:
text text texty text →
← more text, yet more text. Do the arrow heads look like →← this?
Yet enclosing this same construct in another div, viz:
<div>text text texty text →[[File:Example.png|right|alt=Example alt text]]← more text, yet more text. Do the arrow heads look like →← this?</div>{{-}}
works again, thus:
text text texty text →← more text, yet more text. Do the arrow heads look like →← this?
Regrettably Murphy's (see w:Ginsberg's theorem—which I learned under the name of Gumperson's trio of despair, and feel is even more apt!) Law determined that you should have happened to chose the latter construct to document the cases in {{FreedImg/basic mode}} using the latter construct.
The first one appear to break at the arrow heads while the second example wrapped in a div does not. Obviously once captions (P) are introduced to go with image, the second one will break too. -- George Orwell III (talk) 09:48, 18 December 2013 (UTC)[reply]
Well, that proves both of our browsers react the same way, at least. In summary:
P(File:x/float) breaks.
DIV(P(File:x/float)) is O.K.
P(SPAN/float(File:x)) is O.K.
P(SPAN(File:x/class=float)) is O.K. (what extra does the SPAN really do for us here except give us a the style hook File: denies us?)
Unless I am mistaken, case 2 is pretty much the "core" of the "traditional" {{FI}} implementation? And case 3 is the approach I was suggesting recently. I don't really like case 4 on the basis of having to manipulate common-purpose controls on two apparently unrelated containers (the span and the synthesised img-via-File:.)
So I make the usable choices cases 2, 3 or 4 at present. Do you agree? And how reliable (i.e stable) do you think the current parser implementation might be? The safe bet is not to commit too strongly to any approach at least until wmf1.23 matures (don't forget 1.23wmf7 has now snuck in.) I shall stop pretending I am wise, because I'm certainly out of my depth here. Viewer2 (talk) 10:21, 18 December 2013 (UTC)[reply]
I noticed in passing you changed all the <syntaxhighlight|enclose="none">s into |enclose="div"s in Template:FreedImg/basic mode. I don't mind at all—in fact I am curious as to whether you've managed to uncover what the difference is? (The name is obviously suggestive, but I never really investigated properly after discovering either solved my immediate problem at that point in time.)
Reduced line-height (compressing the section's overall height) and "gray" background (like when PRE or CODE is used) but long lines do wrap to parent block's width (just like if it was in a DIV container). None = none of that except the wrapping part. At least that's the way I see it -- George Orwell III (talk) 09:32, 19 December 2013 (UTC)[reply]
Hi, just to let you know, I've made the template we discussed the other day (well, really stole the code from {{Overfloat left}} as you used it): {{fqm}}. If you can see any improvements to make, please go ahead! Thanks again, and Merry (pre-)Christmas! --xensyriaT21:00, 18 December 2013 (UTC)[reply]
Brilliant! Thank you for letting me know. I cannot remember who showed me the technique first but I must have typed it a fair bit, because it just comes automatically out of muscle memory with no real thought process at all. I did very minorly simplify the quote-default-for-p1 check as you can see, but that should not be taken to mean I considered anything to be "wrong" with your initial coding.
And an excellent job on the documentation. I often have more problems there than in the main template logic. No stylist/design artist me, I'm afraid. Viewer2 (talk) 02:08, 19 December 2013 (UTC)[reply]
Well, I only saw it with trial and error (I was actually going to leave it and say parameter 1 shouldn't be left empty if you used parameter 2, but with another set of coder's eyes looking over it I thought I'd better put that kludge in; the piped solution would have been much more elegant). And thanks for the complement: still hate writing the docs though! --xensyriaT20:17, 19 December 2013 (UTC)[reply]
So you are—what, thirteen or so?—and need glasses? I must be near to, or past my one-full-dozenth prescription, and think these ones don't always work…or perhaps its just the brain fading!
Yes and yes to above two questions. What power glasses do you use? And the reason I changed to Roman numerals is because the first three chapters were already transcluded to them, and there was no point in moving them to Arabic (or should I say Hindu-Arabic?). If anyone has a problem, they can do it themselves. (I know, because I’ve done it once myself for The Canterville Ghost.) Bwahaha—Clockery Fairfeld (talk) 10:02, 22 December 2013 (UTC)[reply]
Close enough to the reaction I expected regarding H.-A. Hope you realise I was only teasing!
I had to look up the power, so here it is: left: -1.00; right: -0.50 (units unspecified, I assume they still use dioptres?) As you see I am very mildly short-sighted (but very, very astigmatic!), which is weird because my mother was and is fairly strongly long-sighted. The astigmatism I very definitely got from my father. Too much information?
I simply copied the majority scheme the chapters already used (presumably your work) in Mexico of the Mexicans. You may have noticed I (later) adopted a similar scheme for the Plates index page. I just wanted a shortish tie-breaker, because Chapter X turned out to have the majority of the plates, and I could not get away with my original "plan" (such as it was) to refer to each image as "#Plate" within the chapter (Yes, I had naïvely presumed one-chapter, one picture without properly checking.) Viewer2 (talk) 10:24, 22 December 2013 (UTC)[reply]
Of course I don’t mind. As you so wisely said, what’s between friends? But I still feel they would’ve been better off naming them Indo-Arabic numerals -- after all, not all people in India are Hindus. And you're lucky -- my power is right: -6.50; left: slightly higher, possibly -7.00. :D (I agree, most probably dioptres.) Hehe. And nope, not too much information. My mother used to wear glasses, but that was long back (when she was in school, in fact). My father still is mildly shortsighted. But I don’t know where I got the excess of dioptres from -- probably from reading too much (that’s how I landed here). (I trust you aren’t now suffering from an informational overdose? :)
I knew this was bothering me. That quote is not Star Trek at all (I married a mad-keen fan, so second-hand contamination)⸻is it? Oh. I see. Viewer2 (talk) 13:06, 22 December 2013 (UTC)[reply]
I know, it ain’t Star Trek, but let it stay for now. Actually, until I looked it up, I was under that misapprehension, but am not any more. :D (And btw, what on earth does that Unicode character stand for?) —Clockery Fairfeld (talk) 13:10, 22 December 2013 (UTC)[reply]
Thank you for confirming a suspicion I have held for a little while now. "⸻" is the "three-em dash" (a.k.a. ⸻), but I suspect that nearly every browser refuses to honour it. "Lucky" me just happened to be using one of the exceptions to this rule, and so merrily thought it would work everywhere. There is also an extensive list of handy-looking fractions, to which similar considerations apply (if it doesn't look too hard, would you mind please filling in some of the I.E. blanks?):
Description
Entity
Appearance
Works in
Firefox 26.0?
Internet Explorer ?
One-tenth (1/10)
⅒
⅒
Yes/no
?
One-ninth (1/9)
⅑
⅑
Yes/no
?
One-eighth (1/8)
⅛
⅛
Yes
Yes
One-seventh (1/7)
⅐
⅐
Yes/no
?
One-sixth (1/6)
⅙
⅙
Yes
?
One-fifth (1/5)
⅕
⅕
Yes
?
One-quarter (1/4)
¼
¼
Yes
Yes
One-third (1/3)
⅓
⅓
Yes
Yes
Three-eighths (3/8)
⅜
⅜
Yes
Yes
Two-fifths (2/5)
⅖
⅖
Yes
?
One-half (1/2)
½
½
Yes
Yes
Five-eighths (5/8)
⅝
⅝
Yes
Yes
Three-fifths (3/5)
⅗
⅗
Yes
?
Two-thirds (2/3)
⅔
⅔
Yes
Yes
Three-quarters (3/4)
¾
¾
Yes
Yes
Four-fifths (4/5)
⅘
⅘
Yes
?
Five-sixths (5/6)
⅚
⅚
Yes
?
Seven-eighths (7/8)
⅞
⅞
Yes
Yes
Most of these I've stopped using, because when I have, later on various people have "corrected the strange question-mark", so obviously they do not universally work. Viewer2 (talk) 20:04, 22 December 2013 (UTC)[reply]
Thank you. Although I didn't explicitly state this, the entire sub-heading was actually aimed at User:Clockery, as she'd expressed some interest earlier. Needless to say there are tens of thousands of these. UNICODE: yet another grand plan ship-wrecked, eh? Viewer2 (talk) 21:30, 22 December 2013 (UTC)[reply]
For either of you: this site may be of interest in case you haven't already seen it. It is the most comprehensive list I have seen so far of the "official" (in the sense of having an &keyword; form, as opposed to numeric only) HTML entities. Viewer2 (talk) 21:43, 22 December 2013 (UTC)[reply]
Very, very interesting… Hey! Are you sure this isn't your standard technique for bogging down troublemakers—directing them to some kind of endless geek/nerd honey-trap? Viewer2 (talk) 00:00, 23 December 2013 (UTC)[reply]
Strange, though. I also use Firefox 26.0, but some of these don’t work for me (I’ve marked those as /no under FF 26.0). Looks like it’s not only browser-related, but I can’t think what else it could be related to (OS? Or the fact that I recently uninstalled a whole lot of driver software without checking what it was used for? :D). —Clockery Fairfeld (talk) 07:44, 23 December 2013 (UTC)[reply]
That is very, very interesting! I omitted to make the point I use Linux (worse, a very old distribution: Slackware) and have from time-to-time manually added in fonts (remember my trying to find the Egyptian number symbols? If I remember rightly I had to install Akkadian to get anything to work for me back then) as I've noticed gaps. I might—probably do—have a very atypical set-up as a result. Viewer2 (talk)
I use Windows Vista (oldest v. I think), FF 26.0 (about the only up-to-date program [apart from GIMP] I have on my computer), outdated/uninstalled driver software, really old laptop,… well, you get the point. So "what doesn’t work for me" is likely to be a really long list, and I recommend not using it. :D —Clockery Fairfeld (talk) 08:30, 23 December 2013 (UTC)[reply]
Oh well, so much for attempted mugging^H^H^H^H^Htrendsetting. If it is too hard to digest then I'll redo it the traditional way (probably a good thing anyway as I forgot to mark it proofread.)
The explanation is I was trying to use (he really is going to shoot me for calling it his) George Orwell III's paragraph-generating templates. Essentially {{table style}} logic applied to a paragraph instead of a table cell. See {{Paragraph_tag/parse}} for all the bells & whistles. Viewer2 (talk) 09:04, 23 December 2013 (UTC)[reply]
Oho! So that’s what all those three-letter abbreviations meant. I couldn’t for the life of me make out what those meant, and I figured, well, best to go and talk to the author of aforementioned page rather than try to make them out using pea-sized brain. Thanks, and on second thoughts, carry on, Jeeves. They look like they have more scope than the ones us poor mortals use -- I refer specifically to Page:Christmascarol1843.djvu/15. I think I’ll start using them myself… —Clockery Fairfeld (talk) 09:40, 23 December 2013 (UTC)[reply]
Not fair! I think I've just finished removing them all.
Hello. I noticed you created an entry about Hypatia. Hypatia is an author whose works have not survived (even fragments and testimonies are non-existent). I am just wondering whether such an entry is necessary. --Omnipaedista (talk) 21:48, 29 December 2013 (UTC)[reply]
Ah well, even if her works haven’t survived, there might still be articles about her (in EB, &c.) which could be listed here. Apart from that, as the first well-known female mathematician, she deserves an authorpage here -- yes, even if her works were destroyed. :) Hope I haven’t put in my nose where it’s not wanted…? —Clockery Fairfeld (talk) 04:55, 30 December 2013 (UTC)[reply]
You are right. Texts about Hypatia could be included in that entry. This is what has been done in the case of Socrates (a non-author). Thanks for the reply and happy editing! --Omnipaedista (talk) 05:57, 30 December 2013 (UTC)[reply]
As you probably already know, the current solution for inserting dot leaders (Template:Dotted TOC page listing) in such items as the 'table of contents' is bloated to say the least. And I saw you took a stab at coming up with an alternative once already.
Well I've come up with a possible alternative based on the "old" approach I recalled using years ago (basically re-hashed here). As it stands now, implementation requires some css to be in place - User:George_Orwell_III/common.css/dotleader.css - which I've taken the liberty of calling from your common.css file already.
In a nutshell, rather having the dot leader created based on some limited order of spans or whatever appearing under a defined container as depicted in the W3.org example, I've modified the css to trigger when a specific span (<span class="dotStart"> </span>, placed at the very end of the "entry" text) is encountered instead.
So an input of......
<divclass="dotLeader1"style="margin-right:auto; margin-left:auto; width:80%;"><pstyle="margin-right:3.00em;"><span>Salmon Ravioli</span><spanclass="dotStart"> </span><spanstyle="margin-right:-3.00em;">7.95</span></p><pstyle="margin-right:3.00em;"><span>Fried Calamari</span><spanclass="dotStart"> </span><spanstyle="margin-right:-3.00em;">8.95</span></p><pstyle="margin-right:3.00em;"><span>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. <spanstyle="font-variant:small-caps;">Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.</span> Duis aute irure dolor in reprehen derit 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. Almond Prawn Cocktail.</span><spanclass="dotStart"> </span><spanstyle="margin-right:-3.00em;">7.95</span></p><pstyle="margin-right:3.00em;"><span>Bruschetta</span><spanclass="dotStart"> </span><spanstyle="margin-right:-3.00em;">5.25</span></p><pstyle="margin-right:3.00em;"><span>Margherita Pizza</span><spanclass="dotStart"> </span><spanstyle="margin-right:-3.00em;">10.95</span></p></div>
.......produces an output of.....
Salmon Ravioli7.95
Fried Calamari8.95
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 reprehen derit 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. Almond Prawn Cocktail.7.95
Bruschetta5.25
Margherita Pizza10.95
... which seems (well at least here) to render dot leaders nicely enough AND do so dynamically (just re-size your browser window). Of course my brain hurts at this point and this is were I'd like you to chime in.
If you've followed and absorbed as much this far, the remaining "enhancement(s)" needed are:
to make this premise universal regardless of the type of parent being used to hold the "entry" text (table cell/row, ordered list, divs, paragraphs or some combination thereof).
to find a better way to "cloak" the background of the "entry" text, its padding, indents or margins being applied to the above mentioned parent scheme so that the forced background color (white) always trumps any dot leader "overflows" (this the reason for the positive and negative margin-right settings).
to incorporate a way to manipulate word or letter spacing to provide different sorts of dot leader outputs. Leaders using other symbols in place of dots will need their own css definitions added to the main group of course.
It isn't you that is being the pain. I see you've uncovered the old "Tantek Çelik's Bella Mia menu" example, although I note your W3 reference carefully does not call it that. The strange menu items sort of give the plot away.
The mere fact you are taking on this task reveals you have a hitherto unsuspected (by me at least) predilection for kinky masochism. I really suggest from the start: "Run away. Run away and never look back!"
Still here? O.K., being idiots together, several points:
<grin>
Your example works surprisingly well—much better than any of my own experiments which you have obviously already seen. And yes, this stuff does make my brain itch! I am also surprised that anything relating to this from my common.css was of the slightest assistance to you. (Hah! never even noticed before you'd changed it. That was painless: you should have become a surgeon.)
Most certainly, studying your previous exploits triggered my memory and I was off to the races from that point on. I give credit where credit is due - I would not have reached this point without your [passive] input.
Oh, and before this discussion descends into the petty abusiveness of technical limitations, may I make a bit of a comment upon the true monument to W/S that our maligned friend {{dotted TOC page listing}} truly is? Yes it is a parasitical resource hog. Yes it frightens little children. But doesn't it do exactly what it says on the outside of the box when it doesn't actually bring this house of cards to its metaphorical knees? Yes like most monuments in the outside world it gets in the road of aircraft, costs a fortune to build and maintain. Yet the place would be poorer without it. We must love the damned thing whilst pretending to all around we really detest it and it really ought to go, don'cher'know? Ode out.
True, it was an approach that I probably never would have come up with - but its been problematic from day one in certain instances. And its not so much the 5k or so in Post-expand include size a single TOC row seems to gobble up in of itself that is a problem. The issue is the memory bloat on top of the 8, 9, 10, 11, 12 or more out of 40 possible template "expansion depths" needed to render that typical single TOC row. There too many other template / sub-template calls going on there. And if you ever looked at the raw html of one of these rendered TOCs, you'd see every single "dot", visable or not, is ever present for every instance invoked (thats shameful imho).
A fair whack of the complexity of that template revolves around its promise to make the leader itself manipulable (i.e. parameters |spaces, |symbol and (sigh) even bloody |dottext and |dotend. Going CSS immediately sacrifices all of that, so any resource improvements should not make us too smug right from the get-go.
Meh, point taken. Each optional symbol to be repeated would seem to need its own css entry (barring some LUA solution or something) but the various "spacing" requirements for each said symbol should not be all that hard to pull off with additional templatized/inline styling. I could be wrong about all that, however.
A subtlety easy to overlook in simple cases is that the template left-aligns the (Oh Hell, how do you term the sub-fields and still make sense in discussion? LEFT-LEADER-RIGHT do for now?) LEADER field, anchoring at the common origin LEFT text, even though LEFT obscures the overlapping region of the two. That was where my experiments foundered, the only way I could get correct alignment within the LEADER left a tiny trace rendering of LEADER visible beneath LEFT (or sometimes RIGHT). I could only attain the obscurity requirement at the price of sacrificing the alignment one…
Left alignment was the only way to pull of instances where the entry text was long enough to start wrapping. If we were isolated to just single table cell within a complete chap + entry-text + page number table-row, then left/right alignment wouldn't make a difference I suppose. My thinking was its better to cover P, LI, DIV, etc. instances along with the current mania of applying tables than vise-versa.
All in all (and I am afraid this is not all that helpful!) it strikes me my list of show-stoppers is largely similar to your own. In fact I can confidently state you appear to have solved some of the issues which concerned/defeated me earlier. I realise encouraging you in such a thankless task is merely cruel, but with this proviso: Well Done! Viewer2 (talk) 04:38, 12 January 2014 (UTC)[reply]
Ooo, you are an evil person, tempting others to become involved with your pseudo-childlike-innocence-and-fake-flattery routines (you realise we will both go to Hell for this—success v [I'd use the proper UNICODE "∨" but expect it isn't portable?] failure?)
I saw your alterations here and here, and I must admit it gave me a certain unholy satisfaction your clearly better brain tried much the same convolutions and combinations as I had done before. (And you haven't seen the off-line versions. I am quite certifiable I assure you.)
You might as well drop the inuendo/comedy routines altogether - I rarely follow what you're trying to get across anyway. This is through no fault of your own; text based "chatting" is hardly the best way to get something like sarcasm across for example (& you can't say I'm swift to pick up on such nuances in real life either).
O.K. Straight mode engaged. Oz/Yank humour never works anyway: we think you guys are inflexible; you think we are irrepressible mavericks. Status Quo, live with it. Viewer2 (talk) 08:50, 12 January 2014 (UTC)[reply]
With regards using LUA as you suggest above, I feel this is pinning your hope on the wrong cloud. LUA simply doesn't give a useful "hook" into providing user-control over CSS in the proper way, nor early enough in the page generation, nor (and here I am beating a dead horse‥) do I entirely trust post-LUA sanitisation not ruining any good work you can achieve. Oh, and stability of the solution within the wider wmf framework. I am being boring.
Yeah but it can calculate string lengths & such which would help set margins without the need for any manual input. And it did kill your old-school batch file-ish {{{fill}}} block didn't it. I get that rotating the leader symbol instelf is entirely another matter.
Granted all. Didn't you figure out that by the time I put in {{{fill}}} (good call by the way) I had pretty much given up on getting the whole thing to work? The whole concept of calculating and comparing percentage-based offsets, fixed px widths and proportional font occupancy in the same place quite frankly gives me hives. Good luck. Viewer2 (talk) 08:50, 12 January 2014 (UTC)[reply]
The "good call" was to use a named parameter ({{{fill}}}) rather than the next un-named number to begin with. I just refreshed Template:StripWhitespace to bring it into alignment with the known "quirk" for basically the same reason.
Oh sure... that's been working out well. Not. Anyway, please review the current version of your template. It seems to "work" much better now with the container hiding the overflow(s) instead of trying to with each new line. I added the option to give the entry text a right margin (though I'm not sold on making justified the default text alignment just yet) and an early test using letter spacing rather than applying non-breaking spacers. Check it out. -- George Orwell III (talk) 07:37, 12 January 2014 (UTC)[reply]
Do I detect some reverse sarcasm there? Good for you. I can hardly call it "my template" now you've put so much effort into it. Frankly I consider you have improved it out of sight, and I am unreservedly impressed. It was in fact one of my early hopes to incorporate the idea of having an outer container wrapping a block of led-lines ala a true TOC, so what you did to /doc was precisely in line with my intentions.
In short I think this is as good as it is likely to get. Would be nice if there was a mechanism for allowing any applied background colouring to leak through without being smashed over by color:white… but more than good enough for government work (your cultural joke, so I hope that is acceptable)!
Oh, and I had a look at the parser profiling data and every metric (see earlier comments re. reservations) except "Highest expansion depth" (15/40) is lower than my unsaved "rough" equivalent true-{{dotted TOC page listing}} equivalent. I would have thought less levels of expansion here but...?
Not following you there. Your template pulls 2 or 3 levels for a basic single "row" while the old template pulls 4 or 5 roughly. The resource issue has more to do with the calls to other templates to convert mainspace linkage, pagelist assignments and similar or additional table style parsing in addition to the core template. I'm not even sure the whole "stripping whitespace" portion is needed if a LUA script is generating the symbol "string" (I can't see any difference) but I leave it alone for fear of screwing folks customized applications up. -- George Orwell III (talk) 10:16, 12 January 2014 (UTC)[reply]
And here is a little side reading for you: [1]. I know you don't use this browser but (risking a bit more innuendo/comedy routine) sometimes the monkey follows the troupe if only to find out how much misery the other members might get themselves into. I have high hopes of this kind of thing if it takes off… Pretty much similar to the high hopes which have already died (in my case) regarding pretty much all of: [2]. Viewer2 (talk) 08:50, 12 January 2014 (UTC)[reply]
Don't get me started with CSS3 development/roll-out... all this dot leader dancing could have been handled by 2 or 3 css lines if they ever got around to it. Same story with my ordered list items wish - all I want is to modify the current default output suffix "dot" (III.) to wrapped-in-parenthesis ( (III) ) instead but nooooooooo..... <sigh> my life story. -- George Orwell III (talk) 10:16, 12 January 2014 (UTC)[reply]
Really, this is more trouble than its worth, but if you are going to count "in" the Template namespace like that, you need to rem or hide any other calls such as to {{documentation}}, completely reveal the code (i.e no "inlcudeonly" tags) and make sure all {{{params}}} default to something. Then you can really see what the template costs in resources in the home namespace. Next is to check the same bare bones variant when transcluded into or applied in the mainspace. Once you have your usage under "bare bones", you can just subtract/extrapolate those results from any totals found elsewhere when fully applied, etc. to get a rough estimate of the actual overhead when everything else is being rendered along with itat the same time. only now do I realize those are piped links to your test pages and not the to the template namespace.
All this is sort of moot because the div container is being applied manually right now yet its needed for what we do have in the template to render properly. -- George Orwell III (talk) 15:47, 12 January 2014 (UTC)[reply]
I quite agree all points (including some since struck out.) The whole thing was merely a quick-and-dirty comparison of alternate approaches which rendered approximately the same visual effect. I quoted all fields mainly as a convenience to myself—easier to see which ones changed when presented on the same page instead of flipping back and forth between tabs.
I certainly don't seriously expect to use this as any kind of justification outside of a matter of simple curiosity between ourselves.
Old habits die hard: I used to be the "annual raw metrics" guy for the front-end systems of a major distributed computing installation many, many moons ago. So I do in fact know a little of this kind of junk. Viewer2 (talk) 17:09, 12 January 2014 (UTC)[reply]
You know - I do believe {{StripWhitespace}} wasn't exactly broken yet not exactly "working" either until I refreshed it to mirror WP's current version earlier today. And I scrapped the Lua script for the previous bunch of {{{fill}}} params; now everything seems to eat less resources somehow - go figure.
Something is still not optimal when it comes to the "padding" of the spans as well. Oh well, I'm going to keep at it - thinking display:run-in might have a role in this somehow. -- George Orwell III (talk) 17:28, 12 January 2014 (UTC)[reply]
I was afraid you might come up with an idea like that because FF really dropped the ball there and it would break support for that. I'd start looking for another browser if it were just me affected, but perhaps it is not wise to offend the loyalists? Viewer2 (talk) 17:40, 12 January 2014 (UTC)[reply]
Really. I thought for sure it was supported. So you don't see the Sec. #.Section title. "run-in" to the begining of the paragraph body on this page [3] for example? -- George Orwell III (talk) 18:06, 12 January 2014 (UTC)[reply]
Well it degrades gracefully, but this is not as I understand you might expect it quite to look:
┌──────┘
Not quite though I'm happy to see it fail gracefully. Looks like some setting is mucking up my headings/usei class definitions by inserting (running in?) 1, 1.1, 1.1.1, 1.1.2, 1.1.3 etc. before it gets to the actual header text. Oh well. -- George Orwell III (talk) 19:31, 12 January 2014 (UTC) Scratch that - I see the powers that be don't plan to support it. At least now I know to drop that avenue completely. -- George Orwell III (talk) 19:48, 12 January 2014 (UTC)[reply]
Damn. Sorry, I just remembered I had "Auto-number headings" set in my Preferences, just to confuse things. I just got to the point of making another screen-grab when your latest missive arrived. Do you still want to see it, or is the point as moot as I suspect? Viewer2 (talk) 19:53, 12 January 2014 (UTC)[reply]
Thanks but everything that I've just read indicates there are no plans to develop this further for Gecko? (FF) browsers. Until that changes, its a lost cause and not worth fiddling with any further. Too bad - I was surprised to see it work rather easily in IE8 but in the end there isn't all that much need for it currently. Anyway, its clear now the crux of resource issue has a lot to do with how people are applying stuff. Between the various TOC schemes and this dot-leader sub-portion to them, things have become a bit overkill. Taking a look on how to standardize some of the basics - like table settings - for now. -- George Orwell III (talk) 21:30, 12 January 2014 (UTC)[reply]
Regrettably I rather overstated the "comments no longer apply" retraction above. What I meant was to draw attention to the fact the screen capture had changed to eliminate the "Auto-number" distraction. What I did not mean to imply was that Mozilla had weakened on its intransigence regarding not supporting run-in. They seem to be determined to turn their backs on the rest of the industry on this one item, and I really do not know why. Viewer2 (talk) 22:40, 12 January 2014 (UTC)[reply]
LUA v "batched" {{{fill|}}}: may be worth another look?=[edit]
I have been giving your decision to rescind use of LUA/strings in favour of the crude-batch approach some further thought and have a couple of misgivings. I know I have been a bit of a critic of LUA in the past and perhaps this gives the wrong impression. I like the language itself just fine; it is more-or-less the strange (strained?) implementation of it as a MW extension I have problems with.
In fact, this particular application of generating a fairly static string from equally static parameter ought to be ideal for it. I say ought because no matter how high the cost of running LUA if the caching system is living up to its intended duty, all subsequent #invoke's ought to note the same routine is being called with the same parameters and instead pull back the cached result of the first "real" LUA run. In other words after all unique cases have been encountered LUA actually does not get invoked any more and a cache result stands in each time instead.
So in short if your reason for backing out the LUA call was on the basis of poor initial performance, perhaps a few runs should be repeated to find out if only the first one got the heavy performance hit? Worth trying? Viewer2 (talk) 23:43, 12 January 2014 (UTC)[reply]
Umm. No. I am already too close to my monthly bandwidth limits and probably will not even be able to log in again for a fair while. Your reference points nowhere. Please ask again if nobody else will help you. Viewer2 (talk) 20:11, 14 January 2014 (UTC)[reply]
Thanks, can you find something to generate some test cases from? The new param (which I need to document) is noclip which expands out the margins of the text portion on a page where the sidenotes are absent, whilst attempting to respect the sidenoting layout in the transclusion. ShakespeareFan00 (talk) 09:39, 9 February 2014 (UTC)[reply]
As you so wisely said, what’s between friends? But I still feel they would’ve been better off naming them Indo-Arabic numerals -- after all, not all people in India are Hindus. And you're lucky -- my power is right: -6.50; left: slightly higher, possibly -7.00. :D (I agree, most probably dioptres.) Hehe. And nope, not too much information. My mother used to wear glasses, but that was long back (when she was in school, in fact). My father still is mildly shortsighted. But I don’t know where I got the excess of dioptres from -- probably from reading too much (that’s how I landed here). (I trust you aren’t now suffering from an informational overdose? :)
—Clockery Fairfeld (talk) 08:41, 23 December 2013 (UTC)
I've marked it as Proofread again, now only needs to be (re)validated. —Clockery Fairfeld [sic] 13:56, 17 January 2014 (UTC)