Aevar noted on the meta help for references that it might be possible to use only the <ref name> tags in the body, and keep all the actual reference text in a separate section at the bottom. The ref script would of course handle everything else.
But until then I think we should adopt some simple and minor use conventions for ref tags, the first of which being to begin ref tags on a new line in the code, and likewise end the ref tag on its own line. This makes it much easier to distinguish text from ref:
Text text text. <ref> {{cite|stuff}}</ref> Continued text.
Of course these will still show up normally when displayed: Text text text[1] continued text.
The second suggested convention is to avoid putting refs in mid sentence, placing them instead at the end of complete sentences. This might not resonate well, but I thought I'd throw it out there. -Stevertigo
On 3/19/07, stevertigo stvrtg@gmail.com wrote:
But until then I think we should adopt some simple and minor use conventions for ref tags, the first of which being to begin ref tags on a new line in the code, and likewise end the ref tag on its own line.
The problem with this is that starting a new line leaves whitespace in between the text and the reference superscript link, which is not normally present, and not desired.
If this is adopted as a standard, a little code fix to close up that whitespace would be nice.
What I normally do is start the <ref> tag on the same line, but immediately start a new line after it to place the actual reference info, like so:
Text text text.<ref> {{cite|stuff}}</ref> Continued text.
or for larger citation blocks, doing it more like:
Text text text.<ref> {{cite |author=foo |title=bar }}</ref> Continued text.
-Matt
On 3/19/07, Matthew Brown morven@gmail.com wrote:
The problem with this is that starting a new line leaves whitespace in between the text and the reference superscript link, which is not normally present, and not desired.
This does not appear to be the case: In display mode, text on the same level that doesnt have at least two returns after the line will concatenate. So this sentence even though its on separate lines, in code mode will display normally.
What I normally do is start the <ref> tag on the same line, but immediately start a new line after it to place the actual reference info, like so:
Text text text.<ref> {{cite|stuff}}</ref> Continued text. or for larger citation blocks, doing it more like:
Text text text.<ref> {{cite |author=foo |title=bar }}</ref> Continued text.
This works well enough. The point is of course to be organized.
-Stevertigo
On 3/19/07, stevertigo stvrtg@gmail.com wrote:
On 3/19/07, Matthew Brown morven@gmail.com wrote:
The problem with this is that starting a new line leaves whitespace in between the text and the reference superscript link, which is not normally present, and not desired.
This does not appear to be the case: In display mode, text on the same level that doesnt have at least two returns after the line will concatenate. So this sentence even though its on separate lines, in code mode will display normally.
I think you misunderstand; as with regular HTML, any number of space characters, tabs and single returns become a single logical space. However, a return gives a logical space in between the text and the reference superscript.
IOW, "text.<ref>foo</ref>" gives "text.[1]" (ignoring lack of superscripting), while
text. <ref>foo</ref>
gives "text. [1]". In other words, a space in between the period and the reference number.
-Matt
On 3/19/07, Matthew Brown morven@gmail.com wrote:
I think you misunderstand; as with regular HTML, any number of space characters, tabs and single returns become a single logical space. However, a return gives a logical space in between the text and the reference superscript.
IOW, "text.<ref>foo</ref>" gives "text.[1]" (ignoring lack of superscripting), while
text. <ref>foo</ref>
gives "text. [1]". In other words, a space in between the period and the reference number.
I see. Is that a major concern for you?
-Stevertigo
On 3/20/07, stevertigo stvrtg@gmail.com wrote:
I see. Is that a major concern for you?
It's annoying if there is a tradeoff between readable wikitext and precise control over formatting.
Someone should file a bug/wish requesting the change. It might be easy.
Steve
On 3/20/07, Steve Bennett stevagewp@gmail.com wrote:
On 3/20/07, stevertigo stvrtg@gmail.com wrote:
I see. Is that a major concern for you?
It's annoying if there is a tradeoff between readable wikitext and precise control over formatting.
Someone should file a bug/wish requesting the change. It might be easy.
I agree that using a convention<ref> {{cite|stuff on a new line}}</ref> and with the continued text on a new line
is a sufficient method, so that its easier to find the close tags and the continued text in a body of text. I think this addresses my concern of readability, as well as yours and Matt's concern that there be no spaces before the displayed ref number. I dont think a technical solution would work, because the current wrapping style, adding a space just in case, is necessary. Otherwise those of us who use block wrapping anyway just as an organizational convention (putting certain sentences on newlines, letting them wrap in display) AIUI would have to consciously be sure that there was a space after each sentence we want to wrap.
-Stevertigo
On 20/03/07, stevertigo stvrtg@gmail.com wrote:
On 3/19/07, Matthew Brown morven@gmail.com wrote:
text. <ref>foo</ref>
gives "text. [1]". In other words, a space in between the period and the reference number.
I see. Is that a major concern for you?
Am I alone in finding that more readable? Also, what's up with the bracketing? I'd expect a reference, if we're trying to make them look better, to look like the result of <sup><small>1</small></sup>. Piles of punctuation are better left to source code, not articles.
My answer has always been to put <ref>foo, pg. 72</ref> in the text of the article, and the full citation in a separate section at the end. I think it makes the wikitext much, much easier to read and edit, and is more intuitive to newbies. Makemi
On 3/20/07, Earle Martin wikipedia@downlode.org wrote:
On 20/03/07, stevertigo stvrtg@gmail.com wrote:
On 3/19/07, Matthew Brown morven@gmail.com wrote:
text. <ref>foo</ref>
gives "text. [1]". In other words, a space in between the period and the reference number.
I see. Is that a major concern for you?
Am I alone in finding that more readable? Also, what's up with the bracketing? I'd expect a reference, if we're trying to make them look better, to look like the result of <sup><small>1</small></sup>. Piles of punctuation are better left to source code, not articles.
-- Earle Martin http://downlode.org/ http://purl.org/net/earlemartin/
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: http://lists.wikimedia.org/mailman/listinfo/wikien-l
Mak-4 wrote:
My answer has always been to put <ref>foo, pg. 72</ref> in the text of the article, and the full citation in a separate section at the end. I think it makes the wikitext much, much easier to read and edit, and is more intuitive to newbies. Makemi
Before my laptop crashed and consigned my work to the great bit-bucket, I was working on augmenting the <ref> mechanism to allow something like this to be done automagically. Maybe I ought to see about resurrecting that sub-project... There was something about footnotes as well, whereby you could localise a set of notes to a structure like a table: I'll see what I can dredge up.
HTH HAND
On 3/20/07, Earle Martin wikipedia@downlode.org wrote:
Am I alone in finding that more readable?
It may be, but it's not the way it's normally done. Footnote/endnote markers normally go right next to the thing being marked. Also, as I just pointed out in reply to Steve, the spaces are breaking spaces, and word-wrap may end up putting the footnote marker at the start of the NEXT line. That's certainly not more readable.
-Matt
On 20/03/07, Matthew Brown morven@gmail.com wrote:
On 3/20/07, Earle Martin wikipedia@downlode.org wrote:
Am I alone in finding that more readable?
It may be, but it's not the way it's normally done. Footnote/endnote markers normally go right next to the thing being marked. Also, as I just pointed out in reply to Steve, the spaces are breaking spaces, and word-wrap may end up putting the footnote marker at the start of the NEXT line. That's certainly not more readable.
Very true. The problem for me, as I mentioned in the part you didn't quote, is the gratuitous use of square brackets. If reference links were to be formatted print-style as small raised numbers, that would help a lot in terms of reducing clutter.
On 3/21/07, Earle Martin wikipedia@downlode.org wrote:
Very true. The problem for me, as I mentioned in the part you didn't quote, is the gratuitous use of square brackets. If reference links were to be formatted print-style as small raised numbers, that would help a lot in terms of reducing clutter.
There is an assumption that HTML size formatting is a useful way to differentiate certain text. It is not, as some of us cant stand the common use of small text, and set our browsers to show an actual readable size. I know that a lot of times people use size formatting in templates, but these are negligible. Whatever convention for the display of reading basic text, including reference links, has to be functional for the rest of us.
-Stevertigo
On 21/03/07, stevertigo stvrtg@gmail.com wrote:
On 3/21/07, Earle Martin wikipedia@downlode.org wrote:
Very true. The problem for me, as I mentioned in the part you didn't quote, is the gratuitous use of square brackets. If reference links were to be formatted print-style as small raised numbers, that would help a lot in terms of reducing clutter.
There is an assumption that HTML size formatting is a useful way to differentiate certain text. It is not, as some of us cant stand the common use of small text, and set our browsers to show an actual readable size. I know that a lot of times people use size formatting in templates, but these are negligible. Whatever convention for the display of reading basic text, including reference links, has to be functional for the rest of us.
It would be a natural for user preference setting - that way both of us could be happy without affecting the other.
On 22/03/07, Earle Martin wikipedia@downlode.org wrote:
On 21/03/07, stevertigo stvrtg@gmail.com wrote:
There is an assumption that HTML size formatting is a useful way to differentiate certain text. It is not, as some of us cant stand the common use of small text, and set our browsers to show an actual readable size. I know that a lot of times people use size formatting in templates, but these are negligible. Whatever convention for the display of reading basic text, including reference links, has to be functional for the rest of us.
It would be a natural for user preference setting - that way both of us could be happy without affecting the other.
Too many preferences are an intrinsically bad thing. I suspect in this case setting a minimum font size in one's browser is actually the right answer. (Mozilla browsers allow this, but I don't know if any others do. Safari doesn't seem to.)
- d.
On 3/22/07, David Gerard dgerard@gmail.com wrote:
Too many preferences are an intrinsically bad thing. I suspect in this case setting a minimum font size in one's browser is actually the right answer. (Mozilla browsers allow this, but I don't know if any others do. Safari doesn't seem to.)
It's a truism of open-source software that every time there's a disagreement on interface, a new preference option gets added so that both sides can be happy. Unfortunately, this means preference panes or command-line arguments that grow beyond reason.
-Matt
On 3/20/07, stevertigo stvrtg@gmail.com wrote:
I see. Is that a major concern for you?
Yes. That it's correct style (IMO) is important, but also there's the issue of wrapping - I don't think the things should wrap to the next line, do you? If there's going to be a space, the least it should be is non-breaking.
-Matt
On 3/20/07, stevertigo stvrtg@gmail.com wrote:
The second suggested convention is to avoid putting refs in mid sentence, placing them instead at the end of complete sentences. This might not resonate well, but I thought I'd throw it out there.
This doesn't work well for some sentences with distinct facts coming from distinct sources:
Although Elbonia is the world's biggest exporter of mail-order brides[1], some analysts believe that Zamunda will overtake it in the next three years.[2]
Writing this with the two sources at the end of the sentence is less precise, and looks like the two sources agree with each other or are somehow mutually redundant. Due to Wikipedia's "special needs" with regards to referencing, I think we should be leaning towards more precise and explicit referencing, not less.
Steve
On 3/19/07, Steve Bennett stevagewp@gmail.com wrote:
On 3/20/07, stevertigo stvrtg@gmail.com wrote:
The second suggested convention is to avoid putting refs in mid sentence, placing them instead at the end of complete sentences. This might not resonate well, but I thought I'd throw it out there.
This doesn't work well for some sentences with distinct facts coming from distinct sources:
I agree with this. The first suggested convention will suffice.
-Stevertigo