Template talk:Dropinitial
- this talk was at Template talk:Dropinitial-span; Template:Dropinitial-span, an experimental fork, has been pasted over this template.
status of -span fork
[edit]Where is the status of this template in terms of testing? Finished or still experimental? I am not sure whether the Technical Note relates to this template, or whether it relates to future changes of browser specifications. -- billinghurst (talk) 05:00, 4 May 2009 (UTC)
- Hi. I'm pretty sure this is the way to go; i.e. this should be pasted over {{Dropinitial}} and be the norm. It is in use and I've not looked closely at how things are going, but will do so. I made very similar changes to {{Float right}}, {{Float left}} and {{RunningHeader}} over the last few days. The tech note was copied over from Dropinitial and when css3 is better supported we'll look at refactoring the implementation further.
- The original discussion of this is at
- and while most of the usages discussed there were cut, it was for other reasons; that discussion is mostly on
- The reasons mostly had to do with indenting and white-space on the second line of the poems and was not due to a problem with this template.
- Cheers, Jack Merridew 08:10, 4 May 2009 (UTC)
- Happy to move it over Dropinitial, just want to check what quality control for which we need to check in the replacement of the existing template of that name. No differences in the controls? -- billinghurst (talk) 11:22, 4 May 2009 (UTC)
- Give me a few days to look things over; this is some months old. I expect to paste this over that and redirect this. May do the bot trick on the extant usages. There should be no compatibility issues; it's a folk of the other template and I nearly just made the change there in the first place. Thanks for the patrolled bit ;) Cheers, Jack Merridew 11:59, 4 May 2009 (UTC)
- I am happy to sit on my hands and do nothing, to move it, or whatever.
-- billinghurst (talk) 12:23, 4 May 2009 (UTC)
- below ec'd; I'm going to review and will paste it over when I'm sure things are good (which I basically am already). Cheers, Jack Merridew 12:46, 4 May 2009 (UTC)
- I am happy to sit on my hands and do nothing, to move it, or whatever.
- example
Before we do this switch over, please look at an example;
This is currently using the other template and the drop-initial is done with a div-element. See the 'paragraph' that uses it; begins with 'In 1857'. If you examine the MediaWiki generated code, you'll see that there is no paragraph element around that text. This is because MediaWiki knows that p-elements may not contain other block-level elements, such as div, and so it spits out the drop-initial div and the remaining text is just text in the page without a paragraph wrapped around it. If you look at:
which is the transcluded bit, you'll see that there's no "¶" next to that paragraph; it's not really a paragraph (the "¶" a line above is different). fyi, I did the css that's generating that paragraph marker. Compare with:
and note that while they look about the same, the paragraph here does enclose all of the text; the very similar "¶" is due to a br-element in this case.
So, what's the big deal? w:Semantic markup. Right now, there's not a great deal of styling difference between text on a page and text on a page that's in a paragraph. This could change; it surely will change, and mechanisms like the floated-div serve as impediments to future change and limit the site's flexibility. It should be a core concern that anything that amounts to a 'paragraph' is, in fact, served-up with p-elements around it. This really applies to other elements, too, but paragraphs are the Big Kahuna — we surely have millions. Cheers, Jack Merridew 12:46, 4 May 2009 (UTC)
- Umm, you are talking to a person who has never bothered much with html/css, so I all can do is nod my head and say so? Followed by, Can I help fix it, and what do we want done? I follow instruction well. :-) -- billinghurst (talk) 11:52, 5 May 2009 (UTC)
- I looked for issues yesterday; I thought I found one, but it turned out to be something else. Absent finding any issues, or objections, I'll paste this over (nicking the comment about being a fork) when I have time to focus on any issues that come up. I'd rather find any up-front. The old template is used on 500-1000 pages; I can't check'em all, so once I'm sure enough, I'll cut-over and post an fyi to ws:s so the alert know to watch for issues. Cheers, Jack Merridew 08:53, 6 May 2009 (UTC)
- a side issue
Even after this is swapped-in, there will still be some cases where it does not fix everything; not saying anything will be broken, however. See here; the important change is adding a div-element inside the poem-tag; this causes the correct paragraph generation (and I'm not quite sure why). I previewed this with the other template and it doesn't work properly with or without the div. Also note that yanking "compact" out of the poem-tag fixes this-up, too. Hmm... Cheers, Jack Merridew 13:59, 6 May 2009 (UTC) (this is as much a note to myself as to others...;)
- Per request, I took a look at this. It seems like a fairly minor change; for the most part it won't have any visible affect. The main difference is that MediaWiki has somewhat complex handling of divs, so the exact behavior w.r.t paragraphs can be hard to predict. I do see a visible change when this is used in a line in the middle of a poem; this div version will force a paragraph break, while the span will not. Anyway, span is probably more typical, and behaves more predictably. -Steve Sanbeg (talk) 21:11, 6 May 2009 (UTC)
- Thanks. I've read-up on the compact option and it may be that it, along with the div in that diff, should be removed. That work is far from complete and is still in a formatting test-mode.
- Absent any serious issue arising, I'll past the core of this template over the other one in a day or two and see how it goes. I've looked at fair number of example and have previewed the span-version to good effect. Cheers, Jack Merridew 08:35, 7 May 2009 (UTC)
- bold
I've gone ahead and done this; Off to ws:s. Cheers, Jack Merridew 08:58, 7 May 2009 (UTC)
Not top aligning
[edit]At Page:English as She is Spoke.djvu/17 a larger dropinitial has the top of the initial NOT top aligning with the remainder of the first sentence in the paragraph. billinghurst (talk) 20:52, 5 December 2009 (UTC)
dropinitial and text-indent
[edit]dropinitial and indentation through css doesn't play nicely together, three test, the first w/o indent, the two last add a div style="text-indent:2em"; the third is the actual dropinitial code + "text-indent:0em;". Can we add this piece of code in the template? (assuming dropcased text is never indented). Note this doesn't fix all trouble, dropinitial and text-indent through css will work only if a double line-feed is inserted before the call to the template. Phe (talk) 07:04, 16 April 2010 (UTC)
- <div class="prose"><span class="dropinitial" style="display: block; font-size:3em; line-height: 1em; float: left; margin: 0em .1em 0em 0em;">
- <div class="prose" style="text-indent:2em"><span class="dropinitial" style="display: block; font-size:3em; line-height: 1em; float: left; margin: 0em .1em 0em 0em;">
- <div class="prose" style="text-indent:2em"><span class="dropinitial" style="display: block; font-size:3em; line-height: 1em; float: left; margin: 0em .1em 0em 0em;text-indent:0em;">
- It probably is me, though I am not quite sure what you are asking to be inserted, and I cannot exactly say that I note the issue, though that may be that I have never seen an indented drop initial. I was wondering whether the issue is the closing </div> after a carriage return. I have noticed that such a process seems to have significant impact. — billinghurst sDrewth 11:31, 16 April 2010 (UTC)
- I'm asking to insert a text-indent:0em; in the css style of this template to ensure paragraph starting with a dropinitial will be never indented, the second test case above show the actual and wrong behaviour. The first test show a correct behaviour because no indentation is asked, the third show a right behaviour, auto-indent is asked but the text-indent:0em; avoid this auto-identation for paragraph starting with a dropinitial. Phe (talk) 14:50, 16 April 2010 (UTC)
Done by Phe — billinghurst sDrewth 07:11, 25 April 2010 (UTC)
unwanted line wrap
[edit]The addition of the template to this page caused the second line to wrap, the format uses {{Float center}} and this seems to be the conflict. Cygnis insignis (talk) 17:28, 19 April 2010 (UTC)
- add: I bogged up the last line here and that stopped the second (longer) line breaking. Cygnis insignis (talk) 17:36, 19 April 2010 (UTC)
- The template is a table centred on a page, and for some reason it doesn't seem to expand under its own steam. The easy solution would be to add an optional width parameter where you could force it to a width as necessary (somewhat akin to the offset parameter used for the RIGHT templates); and we would probably can do that in whichever measure(s) that you would prefer. — billinghurst sDrewth 12:35, 20 April 2010 (UTC)
- I'm not aware of the template (Float center) failing to expand in other uses, only when using this template. I doubt forcing width is the solution. Is the suggestion to add that parameter to float center? Cygnis insignis (talk) 08:10, 25 April 2010 (UTC)
- The template is a table centred on a page, and for some reason it doesn't seem to expand under its own steam. The easy solution would be to add an optional width parameter where you could force it to a width as necessary (somewhat akin to the offset parameter used for the RIGHT templates); and we would probably can do that in whichever measure(s) that you would prefer. — billinghurst sDrewth 12:35, 20 April 2010 (UTC)
font family
[edit]Can we remove the default to serif font, it is more likely to have appeared in an initial, but it is likely to be mixing with one without. Reader choice, blah blah Cygnis insignis (talk) 01:28, 26 June 2010 (UTC)
- I removed it, it was mixing families by default. I assume it will render in whatever setting is applied to the rest of the text. cygnis insignis 18:54, 4 September 2010 (UTC)
- Sorry i didn't come around back when you asked/discussed. I didn't understand the problem exactly, i suspect the default of serif would conflict where a page-wide font has been specified ? I just put it back, but modified, where there is no default font ; the "fontfam=" parm is heeded only when present. --Jerome Charles Potts (talk) 06:18, 2 November 2010 (UTC)
- The default is sans serif, but the template worked if the user chose something else. When would the parameter be needed? cygnis insignis 06:46, 2 November 2010 (UTC)
- Whichever contributor uses this template can specify (actually, suggest) some decorative fonts to be tried by the end-user's browser for an aesthetic effect similar to that in print. The browser tries to display the drop-cap using the first of the specified fonts that it finds available ; for any such result, the user must have installed some decorative fonts on his machine, otherwise the default font of the rest of the text is used, that is, you get a plain drop-cap, without the embellishments. I am trying to find out which decorative fonts are popular, since there are tons available here and there ; however, for instance, my Ubuntu Linux hardly offers any of those, i had to search the Net for some. So far, my list includes, in no particular order : SchneidlerInitialen, Nabel, SquareCaps, SchneidlerSchwabachInitials, Ann, FloralCapsNouveau, and Isabella (the order of preference really depends on the context, that is, on each web page). This article at about.com suggests an "Edwardian Script ITC", "Brush Script MT", and "cursive", but i have yet to see what they look like. This is all still new, but i anticipate that things will somewhat standardize at some point, meaning that some day soon it will be known which decorative fonts (with names like "caps", "initials", "majuscule", et al.) are popular, and desktop operating systems will be including those, in which case we will know to specify those in this template (or any other similar mechanism), down the font-family list. --Jerome Charles Potts (talk) 09:06, 2 November 2010 (UTC)
- Unless we set all fonts, it creates a mix; the option is not an option, it overrides the default. The aim of the page you modified is to produce a maeaningful transcript, not to assign or imitate the decorative elements in a vain attempt at photo-facsimile. Completing that work is the priority, changing the font to anything other than the default means changing it all, an undesirable burden that has one choice imposed over many. A plain transcript allows a user to opt for these, from their devices or in printing. I removed the italic font for the same reason, you need to get a consensus from workers here to change it. cygnis insignis 09:37, 2 November 2010 (UTC)
- I haven't figured out yet how to try a template change in a sandbox, so i work "live", and revert if it doesn't work as expected. I really need to learn to play in my own sand pit.
- I am just noticing this Template:Blackletter/doc, which looks interesting, making use of the user's monobook.css . This is something that i want to explore. --Jerome Charles Potts (talk) 09:51, 2 November 2010 (UTC)
- That would be the way to go, note that the user needs to specify that display. We have {{sandbox}} for experiments. This sort of thing seems like a good idea, but the effort becomes tedious when applied accross thousands of pages. Users want the text, they have access to the printed page scans if they want that type of facsimile. cygnis insignis 10:10, 2 November 2010 (UTC)
- I understand your frowning on what seems like trivial cosmetics when there is so much more important work that needs tending to, but i just had a peek at this month's featured text page where the one on Houston is listed : it contains a bunch of flowery arabesques at the beginning, and they went as far as including an image file as a decorative dropcap (whereas i'm trying to deal with text). So, i'm a bit puzzled. Not to forget that such cosmetics are little things that can keep a contributor to stick around longer, to find important stuff to fix along the way, and possibly draw some new recruits in as well. --Jerome Charles Potts (talk) 10:28, 2 November 2010 (UTC)
- In my experience, the enthusiasm for imitating the scan lasts about 20 pages. This is not surprising, proofreading a page to standard takes about 30 seconds, fiddling with inconsequential elements, that have a knock on effect of 'needing' to fix every other one, takes a lot more time. Multiply that by thousands of pages, and the time for two or three checks by others. Generating content is done by those interested in the same, not as a by-product to experimenting with page design. This is not the page to discuss that, the reasons for avoiding something that is meaningless have been well explored. Users want the text, others enjoy sharing the books they like. cygnis insignis 10:57, 2 November 2010 (UTC)
- If someone wants to add an image of a decorative element, they can indulge in that, this is quite a different matter. cygnis insignis 10:59, 2 November 2010 (UTC)
- I understand your frowning on what seems like trivial cosmetics when there is so much more important work that needs tending to, but i just had a peek at this month's featured text page where the one on Houston is listed : it contains a bunch of flowery arabesques at the beginning, and they went as far as including an image file as a decorative dropcap (whereas i'm trying to deal with text). So, i'm a bit puzzled. Not to forget that such cosmetics are little things that can keep a contributor to stick around longer, to find important stuff to fix along the way, and possibly draw some new recruits in as well. --Jerome Charles Potts (talk) 10:28, 2 November 2010 (UTC)
- That would be the way to go, note that the user needs to specify that display. We have {{sandbox}} for experiments. This sort of thing seems like a good idea, but the effort becomes tedious when applied accross thousands of pages. Users want the text, they have access to the printed page scans if they want that type of facsimile. cygnis insignis 10:10, 2 November 2010 (UTC)
- Unless we set all fonts, it creates a mix; the option is not an option, it overrides the default. The aim of the page you modified is to produce a maeaningful transcript, not to assign or imitate the decorative elements in a vain attempt at photo-facsimile. Completing that work is the priority, changing the font to anything other than the default means changing it all, an undesirable burden that has one choice imposed over many. A plain transcript allows a user to opt for these, from their devices or in printing. I removed the italic font for the same reason, you need to get a consensus from workers here to change it. cygnis insignis 09:37, 2 November 2010 (UTC)
- Whichever contributor uses this template can specify (actually, suggest) some decorative fonts to be tried by the end-user's browser for an aesthetic effect similar to that in print. The browser tries to display the drop-cap using the first of the specified fonts that it finds available ; for any such result, the user must have installed some decorative fonts on his machine, otherwise the default font of the rest of the text is used, that is, you get a plain drop-cap, without the embellishments. I am trying to find out which decorative fonts are popular, since there are tons available here and there ; however, for instance, my Ubuntu Linux hardly offers any of those, i had to search the Net for some. So far, my list includes, in no particular order : SchneidlerInitialen, Nabel, SquareCaps, SchneidlerSchwabachInitials, Ann, FloralCapsNouveau, and Isabella (the order of preference really depends on the context, that is, on each web page). This article at about.com suggests an "Edwardian Script ITC", "Brush Script MT", and "cursive", but i have yet to see what they look like. This is all still new, but i anticipate that things will somewhat standardize at some point, meaning that some day soon it will be known which decorative fonts (with names like "caps", "initials", "majuscule", et al.) are popular, and desktop operating systems will be including those, in which case we will know to specify those in this template (or any other similar mechanism), down the font-family list. --Jerome Charles Potts (talk) 09:06, 2 November 2010 (UTC)
- The default is sans serif, but the template worked if the user chose something else. When would the parameter be needed? cygnis insignis 06:46, 2 November 2010 (UTC)
- Sorry i didn't come around back when you asked/discussed. I didn't understand the problem exactly, i suspect the default of serif would conflict where a page-wide font has been specified ? I just put it back, but modified, where there is no default font ; the "fontfam=" parm is heeded only when present. --Jerome Charles Potts (talk) 06:18, 2 November 2010 (UTC)
alignment
[edit]The top alignment of the character is near the bottom of the first line, mac osx: safari (latest versions). 09:26, 22 August 2010 (UTC)
- Yeah, I think that the alignment has gotten kind of far off in various browsers compared to earlier versions of this template... I plugged the last version of the code I worked on in 2008 into the sandbox and set up a simple testcase based on that first example in the docs and took screenshots, you can see that in IE and Chrome the top of the initial is now pretty far above the top of the rest of the text. I don't have Safari installation handy but I had been testing with Safari for Windows back then and it looked okay... maybe someone on a Mac can contribute a screen shot of what's described above. --❨Ṩtruthious ℬandersnatch❩ 16:43, 13 January 2011 (UTC)
| IE8 | FF | Chrome | Opera |
|---|---|---|---|
 |  |  | <- Windows XP (w/o ClearType obviously) |
| Ubuntu -> |  |  |  |
Broken in Chrome
[edit]This template is broken in Chrome: the initial appears just as in {{Largeinitial}}. Seems to be a relatively recent change. Any ideas? —Spangineer (háblame) 21:56, 23 February 2011 (UTC)
- Doesn't this have to be applied in conjunction with something like Block_Center at the same time or something like that? That template was fiddled with recently but has since been reverted before I could come back to looking at it - maybe that has something to do with it; maybe not (just guessin'). — George Orwell III (talk) 22:23, 23 February 2011 (UTC)
- It is broken in Firefox and Chrome, which would tend to indicate that it may be changes made elsewhere, Mediawiki:common.css file???? — billinghurst sDrewth 22:52, 23 February 2011 (UTC)
- That hasn't been edited for over a month, so what else may have an effect? — billinghurst sDrewth 22:54, 23 February 2011 (UTC)
- It is broken in Firefox and Chrome, which would tend to indicate that it may be changes made elsewhere, Mediawiki:common.css file???? — billinghurst sDrewth 22:52, 23 February 2011 (UTC)
- This template does call <span class="dropinitial" style... maybe something changed in the main or shared CSS's relating to that during the recent "upgrades"? — George Orwell III (talk) 23:02, 23 February 2011 (UTC)
- I can see that to an earlier revision that it works (see today's Template:Dropinitial/testcases so I will drop it back to there. — billinghurst sDrewth 00:30, 24 February 2011 (UTC)
Returned to a version from 2 Nov
- Checked and works in Firefox, Chrome and IE
- Checked that the doc file is sufficiently accurate, protection in place.
- check that - font-family is gone and at some-point text-indent was added in its place. Doc needs a refresh if the current state works out over a day or 2. — George Orwell III (talk) 01:15, 24 February 2011 (UTC)
If someone wishes to advance forward in time testing in the sandbox to the point of failure, be my guest. The failure of the template may have been the template itself or in association with any other recent changes.<shrug> I don't have the opportunity to do a post-mortem at this point. — billinghurst sDrewth 00:41, 24 February 2011 (UTC)
- Looks like a spacer "nugget" in the form of a second span was being used to "force" alignment or something. No matter - I'm sure whoever it was helping will be by sooner or later.
- I did take the extra-step of re-adding the 7th un-named parameter controling text-indent in case folks have been applying it since last Nov. or something. Please verify I did not break your restoration somehow ( the prior hard-coded value of 0em remains the default so I don't how I might of if I did! ) — George Orwell III (talk) 01:11, 24 February 2011 (UTC)
Thanks, it's working now. I suspected it was related to the upgrade but <shrug>, who knows? —Spangineer (háblame) 03:52, 24 February 2011 (UTC)
Not working in ePub export
[edit]This template looks like this on a Kobo:
)-:
— Sam Wilson ( Talk • Contribs ) … 11:30, 4 November 2013 (UTC)
- Well that is crap. It seems to be more the Kobo than the Epub, as I can export them and they look fine. Is it the graphic image or the template itself? So does it happen with text letters that are 'dropped'? — billinghurst sDrewth 13:03, 4 November 2013 (UTC)
- Yeah, it's annoying :-) but I read on nonetheless! It's fine with text dropcaps (well, the top of them doesn't quite line up, but that's no great drama). I'm sure this is a problem with the Kobo's rendering rather than the ePub... I'll do some more digging tonight, and see if I can isolate it. I was hasty to add this here, without looking into it much, just in case someone knew of some easy fix. — Sam Wilson ( Talk • Contribs ) … 01:03, 5 November 2013 (UTC)
- I've re-downloaded Vanity Fair, and all is well. This time I used the export tool directly, via the CLI (lodging a bug fix while I was at it). So I guess whatever I was seeing before was just a transient thing with the Kobo... :) Hurrah! — Sam Wilson ( Talk • Contribs ) … 08:35, 5 November 2013 (UTC)
Float left
[edit]1.I have added some newlines, that are commented out, to the template for readability. I also added an optional float left feature to the beginning of the drop initial, so that I can use it in Matthew Henry's Exposition of the Bible, for example: Page:An Exposition of the Old and New Testament (1828) vol 2.djvu/464. I hope that the added complexity is not excessive. In any case, I think that it is a nice alternative to using {{floatleft}}. Usage example: {{Dropinitial|T|fl="}}HIS. Heyzeuss (talk) 09:07, 10 May 2014 (UTC)
please document your changes
[edit]@ShakespeareFan00: if you are making changes to long-term templates, please document what you are changing, especially if you not changing by putting through sandbox and testcase changes. — billinghurst sDrewth 12:59, 4 June 2018 (UTC)
- Given your comments about certain other templates, I'll revert the change and put it in the sandbox. Thanks. ShakespeareFan00 (talk) 13:01, 4 June 2018 (UTC)
- And having used a test case, it's not a simple as that. what I'd like to do is have an an end initial that does what drop initial does but at the end of a content insted of the start. Sandboxed example here - User:ShakespeareFan00/end inital, It doesn't yet work as I can't figure out how to flow the body text around it. ShakespeareFan00 (talk) 15:38, 4 June 2018 (UTC)
Still not working in EPUB export
[edit]I tried several works that use {{dropinitial}} and the same thing as above happens in my Kobo Aura. —Genesis Bustamante (talk) 20:26, 24 October 2021 (UTC)
Bug: li but no di
[edit]At Page:The English Dancing Master-John Playford-1651.pdf/3, there is a Template:Large initial which should be a dropcap, but changing "li" to "di" means you get no large cap at all. HLHJ (talk) 02:30, 17 October 2024 (UTC)