Template talk:Blockquote/Archive 2

3084:

commodo tincidunt, sem dolor fringilla enim, et mattis tortor magna non mi. Duis sed facilisis nisl. Fusce luctus orci non orci ultrices sed tristique magna dapibus. Nullam facilisis porttitor neque. Pellentesque id felis vel leo volutpat suscipit. Praesent pellentesque odio diam. Nullam gravida fermentum velit, quis interdum ligula fermentum at. Quisque eget diam leo, pulvinar congue arcu. Proin id pellentesque nunc. Nunc non erat nunc. In hac habitasse platea dictumst. Nulla pulvinar, sem sit amet mollis pretium, lectus ligula accumsan urna, volutpat eleifend libero purus eget augue. Donec non sodales risus. Suspendisse ligula dolor, rutrum quis molestie a, tristique eget justo. Sed suscipit, eros a hendrerit accumsan, purus nulla euismod dui, eget sodales nisi est sit amet eros.

3074:

in elit. Etiam dui justo, mollis vel elementum eget, fringilla sit amet ligula. Maecenas sit amet diam a tortor bibendum varius. Phasellus a ligula non felis molestie pretium. Fusce congue magna eget odio tristique consequat. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Maecenas dolor nulla, eleifend vitae tristique ut, pellentesque ac mi. Aenean gravida justo vel justo gravida ornare. Mauris lacinia est sit amet massa tristique hendrerit. Vestibulum faucibus urna quis mauris posuere sed mollis sapien accumsan. Donec dui diam, malesuada eget aliquam in, feugiat aliquam sem. In vel turpis magna, quis mattis ipsum. In hac habitasse platea dictumst. Curabitur ut elementum libero. Sed lorem ante, bibendum ut hendrerit ut, porttitor vitae tortor.

4514:); it stayed the same using {{quote|text}}. If you narrow the window until the quote is pushed down below the images, the quote gets indented. If you widen the window, no matter how wide, the quote is not indented. (So it's not a matter of having sufficient room in the middle to indent both sides.) It's scary when a formatter has no effect whatsoever. ((The whole darn Web is busted!!!)) This behavior might be a mistake in "all" web browsers, or not; I can't say; but even if some browsers render it as expected (I haven't tried Safari, good (old) Opera, Chrome), it would probably never get corrected. 4928:

the URL blacklist and edit filters will work correctly with it (and if there's a requirement that the URL be duplicated in a manner visible in browsers, that lowers this concern even further). All that being said, though, now that you raise the point, I'm rather out of touch with the WP editing community by now (having been retired and mostly inactive for years), and thus am not in a position to answer whether the community would want this feature, or if so, how or where it would be applied, so as far as that goes, if it's really not wanted here, feel free to revert my addition. =)

4662:'When "they" left a template unprotected and someone dared to put in a tested edit, "they" hurriedly reverted it, saying (effectively) "I'm scared".' I know. It's a long-standing problem, and I'm not sure what the solution is. I run into this "you can's do anything with CSS without my 'permission' first"-style problem pretty frequently. It's difficult to get any action to take place at MW:Common.css, and the same parties who slow things down there have a tendency to go around reverting attempts to fix the issue with inline CSS at the template level, leading to protracted disputes. 1884:{{cquote|Within the framework of the entire enemy intelligence operations directed against Germany, the intelligence service of the Polish resistance movement assumed major significance. The scope and importance of the operations of the Polish resistance movement, which was ramfied down to the smallest splinter group and brilliantly organized, have been in (various sources) disclosed in connection with carrying out of major police security operations.||| ], 31 December 1942<ref name="occupation"/: --> 4979:, etc. The same document also says: "User agents may allow users to follow such citation links," though I can find zero that do so, and continues: "but they are primarily intended for private use (e.g. by server-side scripts collecting statistics about a site's use of quotations), not for readers." And we're not doing anything with them, nor do we have plans to. It does say that "To obtain the corresponding citation link, the value of the attribute must be resolved relative to the element." 4995:, but I think the likelihood of anything like this ever being implemented is very close to zero. A content-facing potential use could be bot-checking an external cite URL for non-404 periodically in case it breaks, on the theory that quotations should have higher verifiability requirements than other content, but there's no consensus at present that this is true, and no such bot planned. If we did have some uses like these in mind, this feature could be put back in. 31: 3997:. The bug is weird, because the content literally does disappear. It's not invisible. If you copy-paste the entire page into a text editor, the text of the missing quotation(s) is not there; but if you view the page source the code to display it is present, and there's no obvious indication why it would not be rendered. For me (Chrome browser, Mac OS X) the Nietzsche quote is there and rendered properly, while the Goethe one, and its 2639: 302: 4490: 3035: 4383: 3050: 2869: 4254: 4116: 2654: 2216: 1746: 1509: 215: 3794: 4186: 4518:

it work as intended. Or maybe there is just no way to make the images define a text box that has irregular sides, instead of residing inside a text box that has straight sides. As a last resort, a rearrangement of the page would be needed. (I didn't set out to redesign the page layout, so I'm not ready to start fiddling and fighting with it right now. Maybe later.) -

2738: 2510: 1195: 342: 3678: 3362: 2770: 2565: 2204: 2087: 1975: 1941: 1860: 1620: 1593: 1466: 994: 938: 410: 199: 93: 4599:. (I had to look around because you present several formulations, including some that only indent one side correctly.) (Also, I think it is preferable to override the template, not the HTML tag, as you recommend above.) (Also you do not show the complete HTML code above. The complete HTML code is embedded in your demo page: 4927:

tag in the byline of the quote (or something similar); if this template were to be converted to a module, this could even be enforced automatically. I don't think the spam angle is a real concern, either; the various spam report bots shouldn't be fooled by its lack of visible effects in browsers, and

4517:

Maybe a different CSS for {{quote|text}} would fix the indenting of text on the right side of images (or between left-side and right-side images). (The text has to indent both sides from effective margins, not the whole page or column's margins.) Or maybe changes to the images' HTML or CSS would make

3685:

There is something wrong with the template in splitting text into paragraphs. Previously when using the template, if one left a space between two paragraphs, the template would, naturally, recognise this and have the quoted text split into paragraphs as required. For some reason, it is not doing this

3594:

Lorem ipsum dolor sit amet, consectetur adipiscing 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

3533:

3503:

3063:

dolor sit amet, consectetur adipiscing elit. Morbi consectetur semper turpis, vitae gravida odio pulvinar in. In tincidunt purus a risus bibendum et dictum lorem laoreet. Proin vel nulla erat, vel commodo felis. Etiam dapibus dictum odio, nec eleifend neque volutpat in. Sed vel erat nibh, sed aliquam

2582:

2298:

2278:

4881:

In several browsers I've tried, this does nothing at all visible in the user agent, not even if you hover. If we enabled this feature at all, it would have be disabled in mainspace, and it's pretty much non-functional anyway. WP doesn't use every conceivable feature of HTML, just the useful ones for

3863:

The quotes essentially do not show (I changed my user page due to the same problem). And you are right about browser specificity. Works ok on Firefox 25 but I was checking in Chrome (desktop) Version 25.0.1364.97 but I thought I saw something similar in the inbuilt Android (a "recent" version, will

2368:

Anyway, I've now reduced the compensation in the sandbox from "font-size:larger" to "font-size:1.17em" which might also give more consistent results across browsers. See how the sandbox version looks now. We should probably hold off on making any changes at the moment to this template as the problem

143:

The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over

139:

136:

3073:

In dictum posuere elementum. Pellentesque gravida tristique sodales. Nulla vel purus ut arcu iaculis facilisis rhoncus in sapien. Etiam cursus lobortis eros, sit amet gravida sem commodo eget. Sed auctor mollis ligula, quis pretium ipsum malesuada et. Nam eget risus a risus tristique bibendum vitae

2094:

I enabled the "beta" Typography refresh setting. Since then, I have noticed that the black quotation marks generated by this template display on top of images, infoboxes, etc. In other words, they do not adjust to their surroundings. I did not notice this before enabling the new typography setting.

3115:

This is (I think) an issue with HTML standards - unless wikipedia defines its own unique blockquote element. normal text is not 'aware' of floating elements: blockquotes are defined by indenting the text a couple of ems from the left containing margin and when a float pushes the text more than a

3045:

I have tested this in both Safari 5.0 and Firefox 3.6.3 on OS X. As far as I can tell, there are (at least by default) no visible style attributes associated with the blockquote element except a left indent. If the text is not up against the left edge of the frame, then the quoted text is not

3083:

Ut consequat lorem sit amet elit posuere eget feugiat enim aliquam. Maecenas pellentesque ullamcorper orci vitae consequat. Phasellus sit amet nisl quis enim sagittis pellentesque. Sed fringilla hendrerit aliquet. Suspendisse nec lacus eget nunc venenatis condimentum. Mauris euismod, quam quis

4779:, about possibly having that element surround both the author and the source, which is permissible but not required in HTML5. If you think it would be desirable to have it do it that way, that would probably be the thread in which to say so, or your view might not be noticed on that point. 3738:, after a conflab with a couple of people with rather more experience than myself. This is rather an awkward bug, given that it sometimes means we have to abandon decent grammar. I might need to find an alternate template for this situation, but preferably not the blockquote HTML markup. - 2013:, but that's obviously a cheap hack. Could someone look into this? Maybe it's just my browser but I'm using FF fully updated under KUbuntu most current stable release (13.04). Anyways, I know jack about templates, so if this isn't the right place, please bring this to the proper place. 1650:/* Styling for Template:Quote */ blockquote.templatequote { margin-top: 0; } blockquote.templatequote .attribution { line-height: 1em; text-align: left; padding-left: 2em; margin-top: 0; } blockquote.templatequote .attribution .source { font-size: 85%; } 2962:

I saw that it was not appropriate. Decided to do it anyway as it is a workaround. What are the implications? It seems to "work" (better than before, take a look). Anyone can revert but please inform if there is a better way or even possible to fix this template in the meantime.

256:. Once the quote template is used, the box stops, and does not extend to the end of the discussion. I ran into this problem once before, and fixed it by nowiking the quote, but as it is a reoccuring problem, I think we need to fix it. I have sandboxed a fix for the template at 2939:, the visually distinctive repetition of text that is already present in the same article. In most cases, this is not appropriate for use in encyclopedia articles." "NOTE: This template should not be used for quotations if they are not repeated elsewhere in the main text." -- 2989:

If you saw that it was inappropriate, why did you do it anyway? There's no workaround for "it's inappropriate". The quotation at that page is not a pull quote, it's a block quote. I've put it back to using the correct template, like the rest of Knowledge does. Please see

4563:(It might be a duplicate of the above, but I see no similarity in the descriptions. The images display fine; the quoted paragraphs display incorrectly in the presence of images.) (You brought the above in from elsewhere, which links here, but the above doesn't link back.) 4665:

The test page was intended to show that some potential "solutions" only indent one side correctly, and/or do not scale; the solution actually under discussion at MW:Common.css is the correct one (the one you quote above), though someone wants to use a fixed, non-scaling

4964:

element (not attribute), then it serves no purpose as an attribute, and just adds to page loading time for no reason. I hadn't reverted because maybe someone has a reason to use it, like "Oh, this provides useful metadata for ", but no one's been forthcoming with any

1478:

around the {{{text|{{{1}}}}}} content, with no styling, no class, no id, no reason or use for a div being there? Did I miss some geeky reason this was added? Is it just a bit of leftover dead code from when all the styling was moved into the site-wide CSS file? —

3989:. Walk through the history of that page to see the tests proving it (I left the page blanked, because we don't want the page being categorized in user categories by the userboxes used in the test data). In the interim, the problem can be worked around by using 3064:

felis. Nullam neque nulla, vehicula nec ornare in, ultrices in magna. Fusce tempor ultrices tortor, vel tempus dolor mattis adipiscing. Donec vestibulum interdum fermentum. Integer vel tellus dolor. Nunc ligula sem, gravida quis eleifend vitae, auctor id purus.

1645:

Therefore, its current use in the template is invalid HTML5 and may cause problems down the road, and in particular may cause accessibility problems for screen readers. Therefore, I want to make two technical changes. First, common.css should be changed to:

4508:( or others before it), there are many block quotes, but one that has some images to its left does not get indented. (Just search for "A NEW ELEMENT".) Two browsers (Firefox, ie11) refuse to indent there. It was the same when it used <blockquote: --> 4066:

Ooh, good catch. I guess that'll need to be tested further there. That rule was added for a reason, too, so it probably shouldn't just be deleted. Might just be a matter of reordering where it appears. I've confirmed on that tescases page that using

104:

As mentioned a couple of times above, this template is not correctly placing things into paragraphs. Judging by the comments, and the template's help text, it once did, so I think that should be restored. For instance, this is the HTML result of

3484:

parameter, which suppresses the sign code, and to modify the sign code to display an error if it is empty and the anon parameter is empty or absent. That would appear to take care of all cases. Anyway, the bug reported here is still certainly

2009:

I came across an issue where a section heading following a quote was not displaying. The heading (The FCC’s new net neutrality rules) showed up in the TOC but not in the text. I corrected this by adding a '.' after the template at this edit

4634:

The same fix would probably help several more quotes on that page which have images only on the right, because the default template does not handle them properly either, indenting them on the left, but failing to indent them on the right.

4726:

tag. I would do so myself, except I feel URLs added in this way should be made available in/as the byline as well, but I'm not sure how best to go about that. I'm also not sure what parameter name might be preferred; my obvious choice is

2364:

There's a bigger problem here, that I've just realised by looking at this in FF, where I wasn't logged in. Monobook is rendering the entire quote smaller than the page font size, but Vector renders them the same font size. Are you using

1304:

00:37, 3 February 2012 (UTC) PS: If we really, really, really want to preserve the kinda pointless difference between the templates of spacing between the quote and the citation, we can add another if-test for it, but that's a serious

3404:

Any or all of these may or may not be intentional. At least, I think they should be documented better rather than the dreaded "why is this template not working?" syndrome. I'm happy to add stuff to the documentation once we agree what

2383:

Ok, I've marked the request as answered for now. When you're aware of a good fix, please feel free to make a new request. (Although I suppose you don't actually have to now that I've lowered the protection level to template editor.) —

4336:

Which ever of these you think is the best result, or if you think TfD is not the right venue for that discussion, you should probably comment in some way at the TfD in question, since at least two of these results would have a

2883:

Hello. I have an experience editing on Wikia. I'm just curious why doesn't have this the quotation mark thingy like those of the cquote template. The cquote template is used in some articles and it messes up with the infobox.

4581:

The actual template is not yet corrected. (When do "they" get around to that? (When "they" left a template unprotected and someone dared to put in a tested edit, "they" hurriedly reverted it, saying (effectively) "I'm

4867:, and the way the feature works (or, rather, mostly doesn't). We almost never want to link to a URL directly in article content except inside a reference citation, but a URL is the only permissible content of the the 3686:

one and the template is combining the text into a single solid block; I only noticed this issue yesterday. Does anyone know how to fix this, without having to resort to using multiple forced line breaks (<br/: -->

2593:

It seems to do this whether I put the "However" line on a different line or right after the quote. It looks weird to me, although if that's a MOS standard, I'll gladly yield. Thanks in advance for any edification.

3192:

I may try to some test casing if someone bugs me to do so (i.e. if people care enough about this to leave me a talk page message asking me to spend time on it). I'm reasonably good at figuring out CSS annoyances.

2042:, marking text from "Decision on Comcast v. FCC " to "The FCC released", copying to clipboard and pasting somewhere else - what gets pasted is "Decision on Comcast v. FCC The FCC's reaction The FCC released". 4449:

generally. But we might have to settle for fixing it in this template only, given the amount of resistance there usually is to implementing anything at that page, especially if only one person brings it up.

4310:

as an optional style that has not been subject to any consensus discussion; this would permit and effectively encourage the addition of random, editor-preferred styles that vary from article to article.

2341:

at the moment, the "Source" text appears bigger than the "Someone" text in my browser (Firefox, Ubuntu). This seems a bit unnatural - is it possible to make it the same size or slightly smaller? Best —

2901:. Since that works, maybe someone can figure out what is wrong with quote (compare quote and cquote, I don't understand template language) and fix that (and "revert" my change, only relevant part). 4595:

still display with the problem (quotes with no indentation on either side when between an image on the left and on image on the right). So I tried changing the worst affected paragraphs using your

253: 2036:, but I don't recall how we fixed it at the time. In this case, the headings were present but displaced off the right-hand edge of the screen. You can verify that they're present by going to 3409:

happen; this is not one of those "somebody should do something about this" calls. I think not having any text should be an error, but perhaps it is deliberately optional so you can just use

1284:. Even if someone finds some new use for it, there is no reason for the parameters to not be compatible so that templates can be converted between, at will with trivial ease in articles. — 3981:

element, and should be reported as one, if it hasn't been already (though I'm not sure what the procedure is these days, since they abandoned Bugzilla; there's a page of instructions at

3190:

I'd be surprised if there isn't a way around this (not with this particular template but with a deeper change, like another div added to the output of all pages. Bears looking into.

2537: 2315:

is desired then a reduction of around 92% at each step would leave the source at 85% of page font size, but would entail further tweaking via spans to partially offset the effect of

3455:

to be put out, an error should be generated if it's not supplied. I can see exactly where it's going "wrong" (from my perspective) in the template source, i.e. that parameter 3 (or

4886:, however; it should not be applied to just the title of the work and should not be auto-italicizing. We're still treating it like the pre-2013 HTML5 Draft version of the element. 3387:

parameter, because it's obvious from the context that we are quoting from Orwell, i.e. the subject of the article itself. While harmless, it's redundant and ugly (in my opinion).

2252:

tag on the source parameter is to reduce its rendered size to 78% of normal. This causes accessibility problems for visually impaired visitors and violates our recent guidance at

4268: 2422:

I've put that fix in the sandbox. The font size looks better on Firefox/Vector to me, but the sign and source parameters are no longer indented. Maybe we should fix the class in

4871:

attribute. Given that it does nothing visible in many browsers, what would be the encyclopedic point, anyway? It would be easily abusable to hide linkspam. See this example:

2263:

One simple solution which preserves the semantic markup would be to use a span with "font-size:larger" around the source parameter. I've made an example modification to the

2258:

Avoid using smaller font sizes in elements that already use a smaller font size .... In no case should the resulting font size drop below 85% of the page fontsize (or 11px).

4329:. Such a clarification might need to happen anyway, since there's some evidence that people are using inline CSS to elaborately mark up block quotations in unusual ways). 4232:, which might be worth considering integrating into the rest of the set of quotation templates. At the moment, it's only used in one article, but that might change. -- 3903:

Sorry for the bad description. The quoted text, quotes - everything gone, but the first quote shows up not the next. A white block appears where the text should be.

2155:

The blockquote changes are not part of the Typography Refresh, but were included in the Typography Refresh as part of the beta. If that doesn't make sense, then see

367:

appears to offer the main features of this template, and many others. Can anyone break it? I am aware from this talk page that sometimes people find ways to make

2466:

I've removed the offending font-size from Common.css, so there should be no more trouble in Monobook. I don't know why the source cite should be so small anyway.

3734:

It doesn't work if there is a colon prior to the opening braces, whether intended as an indent or otherwise. I've just experienced the problem and fixed it with

3474: 2174:

With the typography update applied yesterday, the Typography Refresh beta was removed and only the font CSS updates were applied. This is no longer an issue. --

3463:) is present (it's inside the if-condition). The fix, then, is fairly trivial (and I'll probably go do that in the sandbox), but of course we need consensus. 2994:. We don't want giant quotation marks in articles around block quotations. The use of actual pull quotes (which that was not) is very rare in WP articles. 4971:

that this content attribute can have a correponding IDL (i.e., Javascript) element, so in theory we could do something with this URL via a script, e.g. a

1130:

We can just hope that this "perennial bug" get fixed some day. They say they're working on a badass new parser, but they've been saying that for years. —

1877: 4317:

to more explicitly state that we have a single, consistent block quotation style. This is presently true, as we have one block quotation template at

3116:

couple of ems to the right, the parser decides that the indenting rule is satisfied. I don't think there's anything that can be done about that. --

2572:

Hi, I posted a comment today using the quote template and I notice one space precedes the quotation, and two spaces follow it. Is this on purpose?

3480:

Yeah, this should be fixed; it's kind of stupid. It also makes it impossible to quote anonymous works like the Bible. I would suggest an optional

3261:

Why was this proposal not implemented? Not being able to left-align images with a blockquote is a pain when designing an article. It needs fixing.

2253: 165:

Cannot reproduce this any longer. It was probably not a problem with this template, but something in the site-wide stylesheet long since fixed. —

4924:

It's a bit of metadata meant to aid in attribution. As far as visibility is concerned, it could be a requirement that the URL be replicated in a

2299: