Last modified: 2011-03-13 18:05:35 UTC
Colons are widely misused to create block quotations in articles (they become semantically-silly definition-list definitions).
Wikitext badly needs support for the HTML blockquote element.
Textile text renderer uses "bq. " to render blockquotes [http://textism.com/tools/textile/]. Example:
bq. This is a block quotation.
Markdown text renderer uses email-style greater-than signs [http://daringfireball.net/projects/markdown/
> This is a block quotation.
Some combination of quotation marks may also be a convenient mnemonic:
"" Block quotation indicated by two double quotation marks at the start of the line.
The dd tag is also visually inadequate: a block quotation should have margins on both the left and the right.
Is there something wrong with <blockquote>?
When I add HTML blockquote tags to an article, other editors tend to replace them with
colons, because they see this as the preferable wikitext equivalent.
Ideally, definitions and blockquotes could be given different visual rendering via style
sheets, to help remind editors of the difference (perhaps just wider margins on the right
and left will do). But for goodness' sake, not the big cartoon quotation marks in the
After a few months experience, it seems that the last is not so
serious a problem: there aren't that many block quotations in
Wikipedia, and they don't get converted to colon-indents all that
Still, it would be nice if there was a wikitext method. Ideally,
several other elements could be nested in a single block quotation,
something like this:
> First paragraph.
> Second paragraph.
> * list bullet 1
> * list bullet 2
> It would be great if this whole wikitext block remained in a
single blockquote element!
English Wikipedia's CSS now has distinctive formatting for blockquote elements, using them is recommended in the
Manual of Style, and I see more editors adding them.
A problem with using the HTML tag, not mentioned above, is that it has to be closed properly and balanced. Wikitext
editor shouldn't really be required to understand these HTML concepts. A wikitext version would automatically close
(In reply to comment #5)
> A problem with using the HTML tag, not mentioned above, is that it has to be
closed properly and balanced. Wikitext
> editor shouldn't really be required to understand these HTML concepts. A
wikitext version would automatically close
It's also hard to type and not wiki-like. If we wanted out site to be written
in HTML, we would just have it written in HTML. It's supposed to be a wiki. It
used to be, at least...
Gentlemen, the in the following input, a gratuitous new paragraph
is rendered from </blockquote> thru POINT-X. Just thought you would
like to know. As for me I now put the tags on their own lines to make
sure there are no such artifacts created. Seen in version that is on Wikipedia today.
We see <blockquote> some individuals to conclude that a well- designed
compression algorithm can compress any input, thus, constituting a
magic compression algorithm.</blockquote> My algorithm is to use POINT-X
several algorithms and pick the best (and noting in the header
produced which algorithm we chose, for easy uncompression) ---so
there! Yes, can't always compress, but when it does it is the best
algorithm on the block.
<blockquote> does already work, if people are not accepting it, talk to the people. If you don't like its appearance, change the CSS. You might do that in User:You/monobook.css, MediaWiki:Monobook.css or MediaWiki:Commons.css.
<blockquote> should be prefered over colons as it's the appropriate markup for quotes, allowing cli browsers or screen readers to display or highlight the quote appropriately.
(In reply to comment #8)
> <blockquote> does already work
<blockquote> is HTML, not wikicode.
(In reply to comment #9)
> <blockquote> is HTML, not wikicode.
I don't see a problem with this. If we invented a wikicode expression for <blockquote>, it would just be a synonym for <blockquote>. Wikicode is meant to offer simplified HTML solutions for common problems which occur in a wiki, like lists, where the * markup saves us from writing the additional <ul> tags etc. Creating a synonym doesn't save us from anything.
I moved my part of the bug to Bug #14489. Bye.