This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | Archive 4 | Archive 5 |
A new policy says:
<var>...</var>
HTML element, which renders the variable in italics (<var>E</var> = <var>mc</var><sup>2</sup>
renders as E = mc2).Great. We switched from doing it that way to the more efficient way at about the beginning of 2003, IIRC. Normally one might write such code between 50 and 75 times in an article that it takes one 30 minutes (under the present conventional practice) to write, and if one writes maybe ten such articles in a day, that adds up to enormously more time it takes to write them. Was this policy written by someone who's never written a math article? How did this policy get there? I see it finally being mentioned at Wikipedia talk:WikiProject Mathematics after it's been put into the style manual. Michael Hardy ( talk) 20:46, 12 September 2008 (UTC)
<var>...</var>
too inconvenient to do somehow, then don't do it; some gnome will fix it later. It's not like much of anyone but gnomes pays any attention to this or other MOS pages. And please keep it
civil and a lot less
WP:OWNish. I'm no noob nor an "outsider"; I've been editing MOS pages for years. Just because a handful of editors seem to sometimes like to treat this particular MOS page as if it were somehow magically special does not make it immune from editing by others, much less those with legitimate concerns that math-focused editors may be unaware of, not fully understand, or simply ignore because they aren't personal concerns of those editors or they do not personally see the benefits to resolving them. One such concern is failure in various places in Wikipedia to use the XHTML semantic phrase elements for what they were intended for, an oversight that has implications for
accessibility,
metadata, the
semantic Web, external repurposing of Wikipedia content, etc., etc. Just because this guideline touches on mathematics in a few places does not mean it should be dicated by the convenience of math editors.<var>x</var>
too difficult in some way, try {{
VAR|x}}
{{
var|x}}
(same output). Given that some editors simply won't care, I don't see a problem with the guideline being more flexible (will edit it in a minute to do so). The fact that this was discussed 5 years ago, before many Wikipedians were thinking about Web semantics, Web 2.0, accessibility, repurposing of content, metadata, and using simple inline templates to ease repetitive keyboarding tasks, isn't particularly persuasive. "It's more convenient the sloppy way" is not a strong argument against doing something properly. I'm frankly shocked that mathematics editors would even use such an argument to begin with, given how insistent they are that the codes and conventions they use be done with absolute precision, to the great inconvenience of all other editors (who do not notice or recognize any difference between the minus and hyphen characters, etc.). I also have to ask how many new articles are being created that use italicized variables 75 times? Surely not many. I'm also skeptical about the claim that such an article would require an extra 20 or 30 minutes to write as a result; this would only be true for someone who doesn't know how to copy-paste. As I said, a gnome (or a bot) can fix it later, so it really doesn't matter if some editor will ignore the var recommendation. If someone finds even the template version tedious, a simple solution is to write the article in a text editor, and use \\x\\\
as a temporary token, instead of ''x''
, and then simply search/replace all instances of \\\
with
and \\
with <var>
(in that order), once each, and it'll change document-wide. I do this sort of stuff all the time. Try it. Major time-saver for all sorts of things.Out-dented mass reply; this is a lot to cover in one message, so I'm going to number the points.
''
, and then restoring italics to the non-variables. The changes do not have to all be done by hand, though they cannot be totally automated, and yes, mistakes will sometimes be made as with anything else wiki.— SMcCandlish [ talk] [ cont] ‹(-¿-)› 03:36, 13 September 2008 (UTC)
{{
VAR}}
is now {{
var}}
(the original {{var}}
turned out to be disused cruft, so I moved it and updated the 5 or so pages that actually used it). I have also created a {{
varserif}}
variant. Someone elsewhere asked if XHTML treats math and programming variables differently. The answer is "no"; a var is a var is a var. The same person also says that math vars must be italicized and serif font, while computer vars must be italicized and monospace font. The {{var}}
template presently italicizes and monospaces.
Firstly I have to observe that I can't find a single math article that actually adheres to this. I find all sorts of things in actual WP practice, including italicization of entire expressions (search my edit history for "economic" and you'll find me fixing one of those), italicization of variables only and the entire expression in the same font as the regular text (almost all math articles seem to go this route), and (rarely) italicization of variables inside an expression that has been serifized as a whole with a larger span or div. I was unable to locate an example of a mathematical expression in default font, but variables italicized-and-serifed. Yet that seems, if this person's facts are correct (and the source for them is correct), to be the desired result.
Secondly {{varserif}}
can be used to "enforce" what is apparently actually proper math notation. I created it because I and l are pretty much indistinguishable in most sans-serif fonts, something I've found irritating for a long time and only just now go around to fixing, but it looks like it might just be quite a bit more broadly useful. Gist: Instead of attacking me, try working with me, eh? I kind of breathe wiki template code, and can whip these things up pretty darned quickly. —
SMcCandlish [
talk] [
cont] ‹(-¿-)› 08:45, 14 September 2008 (UTC)
SMcCandlish, you are being vague. You speak of benefits of semantic markup. Be specific, with examples. You speak of accessibility being impaired. Can you say how that could happen? I have only your assertion and no specifics.
And yes, I think you're an inexperienced outsider if you find it implausible that a new article could contain 75 italicized variables. And how does copy-and-paste speed things up when the variable in the middle of <var>m</var> is different each time (this time it's m, next time it's x, after that it's a, etc.)?
You're proposing a HUGE extra burden. And with no discussion until after you put it into the manual.
And why Wikipedia:Manual of Style (dates and numbers) rather than Wikipedia:Manual of Style (mathematics)? Michael Hardy ( talk) 02:30, 13 September 2008 (UTC)
{{
VAR|x}}
is as bad as repeatedly typing <var>x</var>
. OK, so you say there are concerns that math editors may not know about, and that somehow the simpler way of doing things impairs accessibility. Can those statements impress anyone if you don't say specifically what those concerns are or how accessibility could be impaired?
Michael Hardy (
talk) 02:16, 13 September 2008 (UTC){{
VAR|x}}
{{
var|x}}
is just an option for people who love wikicode and hate HTML. I've already explained this. What part of it wasn't clear? The accessibility one is simple: For most users with screen-reading software there is no difference at all between <i>E</i> = <i>mc</i><span style="vertical-align:super; font-size:.75em;">2</span>
(E=mc2) or its partially wikified equivalent ''E'' = ''mc''<span style="vertical-align:super; font-size:.75em;">2</span>
(E = mc2), on the one hand, and E = mc2
(E = mc2). This is all presentational markup. When you do <var>E<var> = <var>mc</var><sup>2</sup>
(E = mc2) there is a big difference (the variables are identified as variables, and the superscript as a superscript), and there is no impact at all on sighted users. I can go into the other reasons in more detail if requested, but really, shouldn't it be enough to know that without semantic markup, math (and other, e.g. computer science) articles are complete gibberish to a significant subset of users? (PS: Yes, I know no one would do the span thing to get a superscript; I just did not want to mingle both presentational and semantic markup in the same examples.) —
SMcCandlish [
talk] [
cont] ‹(-¿-)› 02:47, 13 September 2008 (UTC)<var>...</var>
is presented as an alternative markup, but totally oppose anything describing it as the normal, general or recommended markup. It is overly cumbersome, unnecessary, and we will only have to rescue maths articles from well-meaning editors who try to implement the guideline without properly understanding it or the articles and mess stuff up - as I recently had to sort out a bunch of well intended but disastrous markup changes in
triangle group.
Gandalf61 (
talk) 08:37, 13 September 2008 (UTC)<var>
, not <i>
(which is what ''
wikimarkup is, when XSLT trasformed and sent to the end-user browser), is the the "normal, general and recommended" markup for variables according to the W3C HTML 4 and XHTML 1 specifications (the only standards that exist for such markup), then I'm not sure what you are trying to say. I'm genuinely sorry that some dwid mangled the
triangle group article and wasted your time – I have to clean up well-meaning but severely misguided edits like that all the time, so I can directly empathize – but that has absolutely nothing to do with the topic at hand. —
SMcCandlish [
talk] [
cont] ‹(-¿-)› 10:05, 14 September 2008 (UTC)
<var>
does in a semantic way. I.e., I've yet to see anyone produce any actually viable evidence that <var>
is somehow not the appropriate markup. —
SMcCandlish [
talk] [
cont] ‹(-¿-)› 08:07, 16 September 2008 (UTC){{
VAR}}
has advantages over <var>x</var>. The inner workings of the template can be easily changed so at some point in the future its content could be changed to mathml or whatever. Mixing wiki markup with html seems wrong to me{{
v}}
can be usurped, since {{
view}}
seems to be the same thing (to the extent they differ, probably mergeable), and it is not used manually, but is rather a part of other templates, namely the ones that put "v - e - w" and other such utility shortcuts at the far top right of navboxes, to-do lists and other contentful, boxy templates. MathML could not reasonably be applied to C++ source code and other uses of variables. What I'm talking about now is general use of variables, which presently includes most math articles (which are not doing math-specific things like serif font, etc., anyway). Math wants MathML. Count me in as a supporter. In the interim there needs to be a compelling reason to not use XHTML properly, and so far I haven't seen one. But I realize that Hardy and some others have put the ball in my court to provide the other side more compellingly, so I will do that. I just need a bit of time. I have 10+ relatives showing up in between 9 and 16 hours... Nothing is going to break in the interim. I'm not ignoring you, I'm just pulled too thin by the coincidence of timing to provide the full rationale - the version that does not presume anyone has been steeped in web development for years on end - right this instant. This will be my wikipriority #1, however. —
SMcCandlish [
talk] [
cont] ‹(-¿-)› 10:05, 14 September 2008 (UTC)SMcCandlish wrote:
"Other"? As in: you've given some reasons, and there are also others? You've said it makes no difference at all to sighted users. That's not a reason for the change. You've also illustrated how it makes things more difficult for those editing articles. That's also not a reason for the change. Then you say you can go into other reasons as well.
How does that make sense? Michael Hardy ( talk) 23:03, 13 September 2008 (UTC)
{{v|x}}
is only two characters longer than ''x''.
. Anyway, please, please centralize this discussion at
WT:MOSTEXT (which is the talk page of the disputed material). It is a very hair-pulling exercise to have to deal with detailed, emotional comments mostly from the same parties on three different talk pages. [I refer here to near-duplicate threads at
WT:MOSMATH and
WT:MATH.]—
SMcCandlish [
talk] [
cont] ‹(-¿-)› 10:05, 14 September 2008 (UTC)SMcCandlish keeps expressing how frustrated he feels with the inability of some of us to understand that the more difficult and cumbersome method, that would make all editing take three or four times as long, would achieve results that are no different, and that's a reason to prefer the more cumbersome methods.
He says if we don't adopt the more cumbersome methods things "will just keep getting worse". As far as I can see, the more cumbersome methods would only make things worse by being more cumbersome. In order for his comment about things "getting worse" to make sense, there would have to be something bad, that will get worse. What that bad thing is, he doesn't tell us, and the fact is that I don't know. Why doesn't SMcCandlish inform us on this matter? Or at least attempt to? The proposed change can only discourage contributions to Wikipedia by making editing difficult or impossible.
He tells us that there is some significant portion of Wikipedia users to whom articles will be incomprehensible without the more cumbersome editor-hostile conventions that he wants. Well, I could tell him that gremlins on the planet Pluto have difficulty reading Wikipedia because SMcCandlish is here, and I would at least have the virtue of being specific about who those readers are (gremlins on Pluto) and he would have just as much reason to believe they exist as I have to believe those users he mentions exist. Who are the people who are having difficulties because we're not using his proposed more cumbersome ways of editing? He doesn't say! How do those difficulties come about? Not even a hint from SMcCandlish. He asks whether it isn't enough to know those people exist. But I don't know that they exist. I don't know who they are, what they do, why or how the proposed editor-hostile methods are better for them, and SMcCandlish doesn't see fit to say. Can SMcCandlish even name one such user? If so, he hasn't tried to do so.
More than five years ago we switched from using <var>x</var> to using ''x'', and I and many others have devoted efforts over some years to improving articles by changing the obsolete form <var>x</var> to the improved ''x''. If we are asked to go back to the old form, at least some attempt should be made by someone to give some reason why that should be done. SMcCandlish doesn't want to even attempt to do that. Michael Hardy ( talk) 23:49, 13 September 2008 (UTC)
<var>
tag, that number is an exponent. That would not be a logical assumption for the software to make if the character preceding were simply italicized. The intent of semantic code is to allow software, including but not limited to search engines and screen readers, to make decisions such as this with much greater authority in a wide variety of situations.
Sswonk (
talk) 15:27, 14 September 2008 (UTC)
...Oh, I should have said, not that he "tells us that there is some significant portion of Wikipedia users to whom articles will be incomprehensible without the more cumbersome editor-hostile conventions that he wants", but rather that he acts as if we already know that. I still don't see any reason to suspect that any such people exist. Michael Hardy ( talk) 00:42, 14 September 2008 (UTC)
This thing is crap. I reject it. Loisel ( talk) 10:09, 14 September 2008 (UTC)
Patience please. Because my requests to centralize discussion here have largely been ignored, I've been trying to address all of these concerns in three different places, and am now out of time for today. I will try to get back to all of this as soon as possible, probably in a bit under 24 hours as of this timestamp. In the interim, I have addressed some of this already at both WT:MOSMATH and WT:MATH before I tiredly arrived back here again. Please respond here not there, or the discussion will continue to be pointlessly fragmented. Very short response to a couple of the above issues: "Getting worse": I thought I made that really clear, but I'll spell it out again. The fact that a pretty conceptually simple change is angsty is entirely because of the failure to fully separate the content from the presentation despite the fact that this has been advised since ca. 1993 and codified in HTML 4 (now XHTML 1) and CSS 2 ca. 1998 (or maybe 1996; I'm tired and misremembering). Continued failure to get this right will only lead to more and far worse (scale-wise) problems of this sort as WP continues to grow and grow; 20,000 is a much preferable number to 120,000. "Significant portion of Wikipedia users": I must be writing very poorly this week if it isn't clear that the large paragraph of usability material immediately preceding my mention of this significant proportion didn't make it entirely clear that the referents are the visually impaired users I had just been talking about (was that a bad place for a paragraph break or something?), for whom in most cases non-semantic italicization simply doesn't exist. More later. I haven't even gotten to metadata, the semantic Web, more basic reasons for content-presentation separation, actually-proper mathematical style, etc. — SMcCandlish [ talk] [ cont] ‹(-¿-)› 20:06, 14 September 2008 (UTC)
''E'' = ''mc''<sup>2</sup>
and <var>E</var> = <var>mc</var><sup>2</sup>
will be read as "ee is em cee superscript two" (I forgot what they do with superscript, and it probably depends on the actual software you use).sin(''x'' + ''y'')
even though it is better to use non-breaking spaces, as in sin(''x'' + ''y'')
, because I can't be bothered to write the latter. Similarly, I probably won't bother to use <var>.<subject>This</subject> <verb>is</verb> <complement>retarded</complement> <punctuation>.</punctuation> <signature> Loisel ( talk) 14:53, 15 September 2008 (UTC)</signature>
<subject>
). —
SMcCandlish [
talk] [
cont] ‹(-¿-)› 08:20, 16 September 2008 (UTC){{v|E}} = {{v|mc}}<sup>2</sup>
is "variable capital E equals variable m c, superscript 2" (and maybe even better; it will depend on the screen reader app), instead of "e equals m c, superscript 2". Failure to use every feature of XHTML that can be used to enhance accessibility is a decision to intentionally alienate a substantial subset of our readers simply because we can't be bothered.{{v|E}}
is only 2 characters longer than ''E''
, but much richer. The "expense" of 2 characters in human editing time is practically nil, even in an article with 100 cases. If template name length were a significant factor, no one would use template names like {{fact}}
or {{
clarifyme}} – frequently used ones would shortened as much as possible to things like {{f}}
and {{cm}}
, and people would rather have template names like {{f2}}
than {{fact}}
if {{f}}
were already taken.<em>
for emphasis (another good semantic and accessibility move to begin with!) and <i>
for typographic-only italics (e.g. book titles). All that is left italicized will be variables (and perhaps other mathematical items that are also italicized, but which you will already have converted to <i>
markup). A quick global search-replace will convert these variable remainders to {{v}}
. If you personally find this too much work, then just ignore it and do something else you find more interesting; someone else will deal with it later.<div>
and <span>
– but it can be done much more interestingly and seamlessly by applying the microformat classes to even more semantic elements (see some off-WP tutorials for good examples). While I have not researched every single microformat in existence, I would be shocked if there were not some already making use of <var>
, and more will surely come. The rel-tag microformat could certainly make use of <var>
, as could some potential uses of the XOXO mf and obviously the forthcoming measurements mf which will necessarily have to include mathematics. The
semantic Web, the ongoing natural evolution of the Web into a more meaning-rich (as opposed to simply pretty) environment, more easily processed by software to do things helpful for readers, likewise depends completely on
separation of presentation and content. Wikipedia must do this, or it will fall behind and become technologically and information-architecturally archaic in only a handful of coming years. The constantly-developing "
Web 2.0" demands semantic content, not author-side convenience or 1994-style "just make it look right, forget other concerns" markup techniques.{{v|E}}
will be quite specific.<var>
, respecting the maths world's specification that variables are italic and serif.{{v}}
in a selected block). There is also already a WP user script for making {{
and }}
highlighted in the editing window, and other tools will be developed over time that make editing more visually clear.<var>
is for: Despite someone's strained reading above, the HTML/XHTML specs clearly state that <var>
is for "a variable", not "a computer variable" in particular. Specs documents like that are very, very carefully worded and reviewed by hundreds of people for precision and clarity; they mean exactly and quite literally what they say probably >99% of the time. The allegedly problematic distinction between mathematic and other variables is not helped at all by simply italicizing them both. That makes things far worse, because the markup is instantly confused with both emphasis and italics-for-display-purposes-only, by many if not most editors. The different between the eventual {{v}}
(italics and serif) and {{var}}
(italics only) tags and their attendant CSS will help not hinder distinguishing between these two variable types and displaying them properly.<var>
works synergistically with other semantic markup in the
CS context, including <code>
, <kbd>
, and <samp>
. (Not all of these are presently enabled in MediaWiki; a MW Bugzilla bug report has been filed on the matter.)That's all I can think of in one sitting, and sorry it took so long. I'm going to go self-revert the change to the guideline until this plays out more, especially since the solution now advanced requires convincing anyone with an interest in the extant {{ v}} to merge it with {{ view}} and convert existing deployment to the latter so that we can usurp the former. — SMcCandlish [ talk] [ cont] ‹(-¿-)› 10:07, 16 September 2008 (UTC)
<var>E</var> = <var>mc</var><sup>2</sup>
should in fact read <var>E</var> = <var>m</var><var>c</var><sup>2</sup>
as {{
v|m}}
and {{
v|c}}
are two seperate variables and not a single variable {{
v|mc}}
which needs to be squared. (or while I'm nitpicking it should read <var>E</var> = <var>m</var>c<sup>2</sup>
because c is a constant.) Basically your asking too add markup to almost every other character appearing in formula much like the example given above of a sentence in which every word has been marked. A consequence of unreadable code is the it will increase the number of mistakes made in editing and thereby deteriorating the factual accuracy of the wikipedia math content.{{v| }}
template is already much better, and may in fact improve readability over the use quotation marks which can be confusing if a single formula contains both scalar and vector variables.<var>
" position, in favor of {{v}}
(i.e., the code presently at {{
varserif}}). For vector variables, {{
vv}} is available, and it would take about 1 minute to create that, using <var>
to correctly semantically identify it as a variable ([X]HTML not being any more specific than that today), but using CSS to style it as you say, non-italic and boldface - locally-specified styles override globals (that's the "C" in CSS; apologies to all readers who already know this, but I don't want to assume everyone understands how the style cascade works just because I do; such assumptions have already bitten me in the butt here). So, we should (at least so far!) be able to do the full semantic markup with XHTML, though as you note not with wikimarkup ('', etc.) It won't be godlike, but it should suffice and (perhaps more to the point for maths editors) it will also provide a really clear way to identify particular items that need to someday be converted to equivalent by differently-coded particular items in MathML when MediaWiki almost-inevitably but who-knows-when finally supports that. I would agree that an inability to apply the markup consistently would be worse than useless, but fortunately we aren't actually stuck with that, because CSS is so flexible. NB: We could also add XHTML classes to {{v}}
and {{vv}}
to make them further identifiable, and styleable as a class. Question: Would vv need to be non-italic but bold (only), or non-italic, bold and serif? It's 5 seconds coding difference; just want to be clear. PS: My "incorrect use of the markup" was actually an incorrect assumption about relativity; I was not certain at the time of writing that m and c needed to be treated separately or I would have coded it that way, certainly. The idea did occur to me, but I went with the simpler markup on a (bad) hunch. That's probably hysterically funny to you maths geniuses. :-) The really funny part is I actually knew that c was a constant already, from another context, and just plain forgot. So, yes, I certainly agree with your final version – if we were to propose simply using <var>
which obviously isn't viable. Templates with embedded style actually get us much closer to where we want to be (MathML being the actual location...) In closing for now, yes, I am asking to add markup to almost every other character appearing in a formula. But this is already being done anyway. It's simply different, richer markup, that is slightly more complex on a character-by-character basis (more keystrokes) but far richer, and easier to read, and more likely to lead to better formating in 6 months or 6 years or however long it takes for MediaWiki/MathML integration. —
SMcCandlish [
talk] [
cont] ‹(-¿-)› 12:04, 17 September 2008 (UTC)''f''('''x''', ''t'') = ''t''<sup>α</sup>'''x'''•'''v'''
{{v|f}}({{vv|x}}, {{v|t}}) = {{v|t}}<sup>α</sup>{{vv|x}}•{{vv|v}}
class="var-scalar"
.α
referred to your code-form α
, but the latter was not boldfaced in your example, while v
was, and both are said to be constants. But shortly after you say that v
is a vector variable, not a constant. I am thus confused on various points, such as whether constants should be bolded, italicized or neither, and/or whether other typographic constraints are needed. As an example, I will assume for the sake of argument (trusting your prose over your code, since after all we write in natural language better than we do in code) that:<var>
for variables, only, the rest being <span>
s, and in both cases with classes identifying them by type).
{{fn|f}}({{vv|x}}, {{v|t}}) = {{v|t}}<sup>{{ct|α}}</sup>{{vv|x}}•{{ct|v}}
{{v|E}} = {{v|m}}{{ct|c}}<sup>2</sup>
''f''('''x''', ''t'') = ''t''<sup>α</sup>'''x'''•'''v'''
<var>foo</var>
or {{
var|foo}}
<math>
example that the "f" for the function is not actually a regular "f" at all, but the "florin" symbol or something very close to it: ƒ{{maths}}
or {{physics}}
, that contain a <div class="maths">
and end it with a {{mathsend}}
or {{physicsend}}
that closes the div. The site-wide stylesheet would define all this stuff, and {{fn}}
(with <span class="function">)
would simply inherit: div.maths span.function { styles here; }
versus div.physics span.function { different styles here; }
– the CSS wouldn't actually be in {{fn}}
, {{v}}
, etc., just classes. If chemistry and geology and whatever use further different styles, just add more classes. Trivial.{{ct}}
) from the list. Actually we could drop everything but variables, the only one we have an XHTML element for; I just came up with the rest mainly to show that it could be done. Perhaps this is a good
KISS principle case. The simpler version would just be (using non-physics function style in this case) ''f''({{vv|x}}, {{v|t}}) = {{v|t}}<sup>α</sup>{{vv|x}}•v
, and {{v|E}} = {{v|m}}c<sup>2</sup>
.<var>
with appropriate styles as applied by a template with embedded classes or local CSS. Screen readers can recognize them as variables since marked up as such. I don't think users of them turning on the feature to read out all formatting (italics, etc.) can be depended upon just because someone hits a math article, and math appears in many, many pages that are not math articles. At least identifying variables will be a boon to them. —
SMcCandlish [
talk] [
cont] ‹(-¿-)› 19:29, 17 September 2008 (UTC)<var>
tag was never intended to be used in formula markup, its main purpose is to identify variables when used inside a sentence. In which case identifying it as such may be useful. But in the context of a formula it just isn't unless all the other semantics are also tagged and identified. (
TimothyRias (
talk) 08:33, 18 September 2008 (UTC)){{fn|f}}
but {{fnr|ch}}
(fnr = "function, roman").<var>
case (styled as per {{v}}
and {{vv}}
as needed, and with {{
var}} for CS variables), since that's not just a <span>
with visual style attached via a class, but is an actual XHTML element intended for variables that we are simply wasting.<math>
output, with a larger, italic, serif "f", maybe something like div.maths span.function { font-size: 200%; font-style: italic; font-family: serif; }
). XSLT could then be used to transform such markup into MathML or whatever by scripts, other scripts or applications could extract the data from the article (e.g. just "rip" the equation, and insert it into a LaTeX document). And so on. That's quite a bit more ambitious than simply getting <var>
used more often, but it could be done pretty easily (not counting the implementation in extant articles, of course) if
WP:MATH or
WP:UF saw a need for it. So far it sounds like this would be too difficult to use from an editing perspective.{{fn}}
and {{fnr}}
instead of as very specific objects. Some hardcore CSS purists might object, being a little too gung-ho about object-oriented Web development, but they'd be missing the point that there's nothing wrong with a more generic style class to apply if it obviates the need to have an ever-growing number of objects that would eventually exceed the ability of people to remember them all, which would clearly be the case here. But this sounds like a moot point anyway. —
SMcCandlish [
talk] [
cont] ‹(-¿-)› 19:29, 17 September 2008 (UTC)(copied from above) To reply to your last point, screenreaders identifying every variable in an equation as such explicitly will in most cases actual hinder the understanding of a formula. Of all the possible things that in mathematics as a language are expresses through the formatting wether something is a variable is probably the least relevent. The <var>
tag was never intended to be used in formula markup, its main purpose is to identify variables when used inside a sentence. In which case identifying it as such may be useful. But in the context of a formula it just isn't unless all the other semantics are also tagged and identified. (
TimothyRias (
talk) 08:33, 18 September 2008 (UTC))
<mathml xmlns=\"http://www.w3.org/1998/Math/MathML\"> <apply> <eq/> <ci>E</ci> <apply> <times/> <ci>m</ci> <apply> <power/> <csymbol encoding="OpenMath" definitionURL="http://www.openmath.org/cd/physical_consts1.xhtml#speed_of_light" >c</csymbol> <cn>2</cn> </apply> </apply> </apply> </math>
-- Salix alba ( talk) 09:36, 18 September 2008 (UTC)
<math>
work better. If we reached the point where it was always appropriate to use <math>
for any equation or expression, then we could make it contain the marked-up equation in <eqn>
(or not include it, if it turns out not to work). At that point, it might be reasonable for the MoS to specify use of <math>
for any equation or expression and use of <var>
for any isolated variable, constant, or other bit of notation. Unfortunately, changing the operation of <math>
seems to be a bit like fantasizing about proving the
Riemann hypothesis.
Ozob (
talk) 15:24, 18 September 2008 (UTC)<eqn>
that would more likely be <div class="equation">
, and handled with a {{eqn}}
template. That's all also a strictly maths issue, so I think that the discussion has resolved itself for the purposese of
WP:MOSTEXT. Thanks for your participation! :-) —
SMcCandlish [
talk] [
cont] ‹(-¿-)› 21:29, 18 September 2008 (UTC)<var>
in mathematical contexts.
Silence equals assent in consensus debates. Do you really think we need to go through this entire debate all over again? If so, what new arguments do you expect to see from either side? —
SMcCandlish [
talk] [
cont] ‹(-¿-)› 19:26, 19 September 2008 (UTC)
<var>
a "best practice", and I think you're only person vocally arguing for its consistent use. That doesn't mean it's wrong (as I said quite a while ago, I think it's the right thing), but it's not reached consensus. (Yet?)
Ozob (
talk) 20:42, 19 September 2008 (UTC)If there are <var>x</var> apples per basket...
" was an example of a mathematics variable, not a program variable, which further misled me.<var>
is intended for maths after allSee
http://www.whatwg.org/specs/web-apps/current-work/#the-var – the W3C has clarified that in fact <var>
is intended to be used in mathematical formulae. I'm willing to not push on this particular sub-issue, since the
WP:MATH crowd have made a reasonable case that implementation would be difficult. —
SMcCandlish [
talk] [
cont] ‹(-¿-)› 19:26, 19 September 2008 (UTC)
<var>
.
Ozob (
talk) 22:48, 19 September 2008 (UTC)The specification for var
has been changed. The new description of var
reads:
The
var
element represents a variable. This could be an actual variable in a mathematical expression or programming context, or it could just be a term used as a placeholder in prose.In the paragraph below, the letter "n" is being used as a variable in prose:
<p>If there are <var>n</var> pipes leading to the ice cream factory then I expect at <em>least</em> <var>n</var> flavours of ice cream to be available for purchase!</p>For mathematics, in particular for anything beyond the simplest of expressions, MathML is more appropriate. However, the
var
element can still be used to refer to specific variables that are then mentioned in MathML expressions.In this example, Pythagoras' theorem is solved for the variable a. The expression itself is marked up with MathML, but the variable is mentioned in the figure's legend using
var
.<figure> <math> <mi>a</mi> <mo>=</mo> <msqrt> <msup><mi>b</mi><mn>2</mn></msup> <mi>+</mi> <msup><mi>c</mi><mn>2</mn></msup> </msqrt> </math> <legend> Pythagoras' theorem solved for <var>a</var> </legend> </figure>
We did mostly come to a consensus before, so I see no need to reopen the discussion. But I thought that some of you might be interested in this change to the meaning of var
.
Ozob (
talk) 05:24, 18 December 2008 (UTC)
I have to admit I haven't read all of the above, but gather that most maths editors prefer to use ''x'' than <var>x</var>. What seems to have been forgotten is the merge proposal that started at
Wikipedia talk:Manual of Style (dates and numbers)/Archive 111#Text formatting math section merge proposal and
Wikipedia talk:WikiProject Mathematics/Archive 41#Variable format and led to the discussion above and presumably several improvements but apparently no decision on the merge. The merge proposal of the computing and maths variable sections was to
Wikipedia:Manual of Style (dates and numbers), which was disputed and seems clearly wrong to me, and indeed I don't see any current overlap with that WP:MOSNUM. In fact, there is minimal overlap with
MOS:MATH and a "Main" redirect to there. What is currently on this page is suitable for non-technical editors who might quickly want to know how to format scientific terms, and as such I think it should stay. The actual method used to produce italics is less important than what should be italicised (otherwise I might insist that the <dfn>
tag be respected by Mediawiki). I think the merge proposal has fallen by default, so I've removed the template. --
Cedders
tk 21:49, 8 October 2009 (UTC)
In articles about cities and countries, should demonyms be in bold (in the lead)? Dabomb87 ( talk) 22:14, 6 December 2008 (UTC)
In the When not to use emphasis section, why does it state "The following are proposed guidelines"? If that section is being proposed, then should it not be in this guideline? -- Silver Edge ( talk) 05:22, 4 January 2009 (UTC)
It is standard practice in Wikipedia to italicise representations of bird songs and calls (in the real world this is also a standard, but not universal, convention). Following this discussion, Sandy suggested that it should be added to the list of italic usages, but looking at the project page I'm not sure where it fits best. Any ideas? jimfbleak ( talk) 15:18, 10 April 2009 (UTC)
Wikipedia should avoid the use of any font wherein the capital i is an homograph of the lower case l. The font currently used for the titles of articles suffers from this defect. Fonts should be chosen so that there are absolutely no homographs. Jwray ( talk) 03:23, 12 April 2009 (UTC)
There's a trend on Wikipedia for many terms in the Latin language to be set in all-caps, like so:
I understand the rationale — the Latin alphabet didn't gain lower case letterforms until after the time of the Romans. Personally, though, I find this both distracting (in much the same way as overuse of bold or italics) and less accessible (readers with astygmatisms, including myself, find blocks of capital letters more difficult to read).
I'd suggest the spirit of the "don't overemphasise" rule would argue against this use of smaller capital letters, but I don'think there's ever been any discussion on the issue. I'd like to propose that this practice be discontinued. Thoughts, anyone? — OwenBlacker ( Talk) 20:13, 15 April 2009 (UTC)
Follow your sources. These should not be the Pantheon, but a secondary source (that way you get the emendations); this will almost invariably be lower case. This can be modified for uniformity within an article (there's no reason to confuse the reader by switching between upper and lower case just because you changed source), just like the choice between u and v. Septentrionalis PMAnderson 17:00, 16 April 2009 (UTC)
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | Archive 4 | Archive 5 |
A new policy says:
<var>...</var>
HTML element, which renders the variable in italics (<var>E</var> = <var>mc</var><sup>2</sup>
renders as E = mc2).Great. We switched from doing it that way to the more efficient way at about the beginning of 2003, IIRC. Normally one might write such code between 50 and 75 times in an article that it takes one 30 minutes (under the present conventional practice) to write, and if one writes maybe ten such articles in a day, that adds up to enormously more time it takes to write them. Was this policy written by someone who's never written a math article? How did this policy get there? I see it finally being mentioned at Wikipedia talk:WikiProject Mathematics after it's been put into the style manual. Michael Hardy ( talk) 20:46, 12 September 2008 (UTC)
<var>...</var>
too inconvenient to do somehow, then don't do it; some gnome will fix it later. It's not like much of anyone but gnomes pays any attention to this or other MOS pages. And please keep it
civil and a lot less
WP:OWNish. I'm no noob nor an "outsider"; I've been editing MOS pages for years. Just because a handful of editors seem to sometimes like to treat this particular MOS page as if it were somehow magically special does not make it immune from editing by others, much less those with legitimate concerns that math-focused editors may be unaware of, not fully understand, or simply ignore because they aren't personal concerns of those editors or they do not personally see the benefits to resolving them. One such concern is failure in various places in Wikipedia to use the XHTML semantic phrase elements for what they were intended for, an oversight that has implications for
accessibility,
metadata, the
semantic Web, external repurposing of Wikipedia content, etc., etc. Just because this guideline touches on mathematics in a few places does not mean it should be dicated by the convenience of math editors.<var>x</var>
too difficult in some way, try {{
VAR|x}}
{{
var|x}}
(same output). Given that some editors simply won't care, I don't see a problem with the guideline being more flexible (will edit it in a minute to do so). The fact that this was discussed 5 years ago, before many Wikipedians were thinking about Web semantics, Web 2.0, accessibility, repurposing of content, metadata, and using simple inline templates to ease repetitive keyboarding tasks, isn't particularly persuasive. "It's more convenient the sloppy way" is not a strong argument against doing something properly. I'm frankly shocked that mathematics editors would even use such an argument to begin with, given how insistent they are that the codes and conventions they use be done with absolute precision, to the great inconvenience of all other editors (who do not notice or recognize any difference between the minus and hyphen characters, etc.). I also have to ask how many new articles are being created that use italicized variables 75 times? Surely not many. I'm also skeptical about the claim that such an article would require an extra 20 or 30 minutes to write as a result; this would only be true for someone who doesn't know how to copy-paste. As I said, a gnome (or a bot) can fix it later, so it really doesn't matter if some editor will ignore the var recommendation. If someone finds even the template version tedious, a simple solution is to write the article in a text editor, and use \\x\\\
as a temporary token, instead of ''x''
, and then simply search/replace all instances of \\\
with
and \\
with <var>
(in that order), once each, and it'll change document-wide. I do this sort of stuff all the time. Try it. Major time-saver for all sorts of things.Out-dented mass reply; this is a lot to cover in one message, so I'm going to number the points.
''
, and then restoring italics to the non-variables. The changes do not have to all be done by hand, though they cannot be totally automated, and yes, mistakes will sometimes be made as with anything else wiki.— SMcCandlish [ talk] [ cont] ‹(-¿-)› 03:36, 13 September 2008 (UTC)
{{
VAR}}
is now {{
var}}
(the original {{var}}
turned out to be disused cruft, so I moved it and updated the 5 or so pages that actually used it). I have also created a {{
varserif}}
variant. Someone elsewhere asked if XHTML treats math and programming variables differently. The answer is "no"; a var is a var is a var. The same person also says that math vars must be italicized and serif font, while computer vars must be italicized and monospace font. The {{var}}
template presently italicizes and monospaces.
Firstly I have to observe that I can't find a single math article that actually adheres to this. I find all sorts of things in actual WP practice, including italicization of entire expressions (search my edit history for "economic" and you'll find me fixing one of those), italicization of variables only and the entire expression in the same font as the regular text (almost all math articles seem to go this route), and (rarely) italicization of variables inside an expression that has been serifized as a whole with a larger span or div. I was unable to locate an example of a mathematical expression in default font, but variables italicized-and-serifed. Yet that seems, if this person's facts are correct (and the source for them is correct), to be the desired result.
Secondly {{varserif}}
can be used to "enforce" what is apparently actually proper math notation. I created it because I and l are pretty much indistinguishable in most sans-serif fonts, something I've found irritating for a long time and only just now go around to fixing, but it looks like it might just be quite a bit more broadly useful. Gist: Instead of attacking me, try working with me, eh? I kind of breathe wiki template code, and can whip these things up pretty darned quickly. —
SMcCandlish [
talk] [
cont] ‹(-¿-)› 08:45, 14 September 2008 (UTC)
SMcCandlish, you are being vague. You speak of benefits of semantic markup. Be specific, with examples. You speak of accessibility being impaired. Can you say how that could happen? I have only your assertion and no specifics.
And yes, I think you're an inexperienced outsider if you find it implausible that a new article could contain 75 italicized variables. And how does copy-and-paste speed things up when the variable in the middle of <var>m</var> is different each time (this time it's m, next time it's x, after that it's a, etc.)?
You're proposing a HUGE extra burden. And with no discussion until after you put it into the manual.
And why Wikipedia:Manual of Style (dates and numbers) rather than Wikipedia:Manual of Style (mathematics)? Michael Hardy ( talk) 02:30, 13 September 2008 (UTC)
{{
VAR|x}}
is as bad as repeatedly typing <var>x</var>
. OK, so you say there are concerns that math editors may not know about, and that somehow the simpler way of doing things impairs accessibility. Can those statements impress anyone if you don't say specifically what those concerns are or how accessibility could be impaired?
Michael Hardy (
talk) 02:16, 13 September 2008 (UTC){{
VAR|x}}
{{
var|x}}
is just an option for people who love wikicode and hate HTML. I've already explained this. What part of it wasn't clear? The accessibility one is simple: For most users with screen-reading software there is no difference at all between <i>E</i> = <i>mc</i><span style="vertical-align:super; font-size:.75em;">2</span>
(E=mc2) or its partially wikified equivalent ''E'' = ''mc''<span style="vertical-align:super; font-size:.75em;">2</span>
(E = mc2), on the one hand, and E = mc2
(E = mc2). This is all presentational markup. When you do <var>E<var> = <var>mc</var><sup>2</sup>
(E = mc2) there is a big difference (the variables are identified as variables, and the superscript as a superscript), and there is no impact at all on sighted users. I can go into the other reasons in more detail if requested, but really, shouldn't it be enough to know that without semantic markup, math (and other, e.g. computer science) articles are complete gibberish to a significant subset of users? (PS: Yes, I know no one would do the span thing to get a superscript; I just did not want to mingle both presentational and semantic markup in the same examples.) —
SMcCandlish [
talk] [
cont] ‹(-¿-)› 02:47, 13 September 2008 (UTC)<var>...</var>
is presented as an alternative markup, but totally oppose anything describing it as the normal, general or recommended markup. It is overly cumbersome, unnecessary, and we will only have to rescue maths articles from well-meaning editors who try to implement the guideline without properly understanding it or the articles and mess stuff up - as I recently had to sort out a bunch of well intended but disastrous markup changes in
triangle group.
Gandalf61 (
talk) 08:37, 13 September 2008 (UTC)<var>
, not <i>
(which is what ''
wikimarkup is, when XSLT trasformed and sent to the end-user browser), is the the "normal, general and recommended" markup for variables according to the W3C HTML 4 and XHTML 1 specifications (the only standards that exist for such markup), then I'm not sure what you are trying to say. I'm genuinely sorry that some dwid mangled the
triangle group article and wasted your time – I have to clean up well-meaning but severely misguided edits like that all the time, so I can directly empathize – but that has absolutely nothing to do with the topic at hand. —
SMcCandlish [
talk] [
cont] ‹(-¿-)› 10:05, 14 September 2008 (UTC)
<var>
does in a semantic way. I.e., I've yet to see anyone produce any actually viable evidence that <var>
is somehow not the appropriate markup. —
SMcCandlish [
talk] [
cont] ‹(-¿-)› 08:07, 16 September 2008 (UTC){{
VAR}}
has advantages over <var>x</var>. The inner workings of the template can be easily changed so at some point in the future its content could be changed to mathml or whatever. Mixing wiki markup with html seems wrong to me{{
v}}
can be usurped, since {{
view}}
seems to be the same thing (to the extent they differ, probably mergeable), and it is not used manually, but is rather a part of other templates, namely the ones that put "v - e - w" and other such utility shortcuts at the far top right of navboxes, to-do lists and other contentful, boxy templates. MathML could not reasonably be applied to C++ source code and other uses of variables. What I'm talking about now is general use of variables, which presently includes most math articles (which are not doing math-specific things like serif font, etc., anyway). Math wants MathML. Count me in as a supporter. In the interim there needs to be a compelling reason to not use XHTML properly, and so far I haven't seen one. But I realize that Hardy and some others have put the ball in my court to provide the other side more compellingly, so I will do that. I just need a bit of time. I have 10+ relatives showing up in between 9 and 16 hours... Nothing is going to break in the interim. I'm not ignoring you, I'm just pulled too thin by the coincidence of timing to provide the full rationale - the version that does not presume anyone has been steeped in web development for years on end - right this instant. This will be my wikipriority #1, however. —
SMcCandlish [
talk] [
cont] ‹(-¿-)› 10:05, 14 September 2008 (UTC)SMcCandlish wrote:
"Other"? As in: you've given some reasons, and there are also others? You've said it makes no difference at all to sighted users. That's not a reason for the change. You've also illustrated how it makes things more difficult for those editing articles. That's also not a reason for the change. Then you say you can go into other reasons as well.
How does that make sense? Michael Hardy ( talk) 23:03, 13 September 2008 (UTC)
{{v|x}}
is only two characters longer than ''x''.
. Anyway, please, please centralize this discussion at
WT:MOSTEXT (which is the talk page of the disputed material). It is a very hair-pulling exercise to have to deal with detailed, emotional comments mostly from the same parties on three different talk pages. [I refer here to near-duplicate threads at
WT:MOSMATH and
WT:MATH.]—
SMcCandlish [
talk] [
cont] ‹(-¿-)› 10:05, 14 September 2008 (UTC)SMcCandlish keeps expressing how frustrated he feels with the inability of some of us to understand that the more difficult and cumbersome method, that would make all editing take three or four times as long, would achieve results that are no different, and that's a reason to prefer the more cumbersome methods.
He says if we don't adopt the more cumbersome methods things "will just keep getting worse". As far as I can see, the more cumbersome methods would only make things worse by being more cumbersome. In order for his comment about things "getting worse" to make sense, there would have to be something bad, that will get worse. What that bad thing is, he doesn't tell us, and the fact is that I don't know. Why doesn't SMcCandlish inform us on this matter? Or at least attempt to? The proposed change can only discourage contributions to Wikipedia by making editing difficult or impossible.
He tells us that there is some significant portion of Wikipedia users to whom articles will be incomprehensible without the more cumbersome editor-hostile conventions that he wants. Well, I could tell him that gremlins on the planet Pluto have difficulty reading Wikipedia because SMcCandlish is here, and I would at least have the virtue of being specific about who those readers are (gremlins on Pluto) and he would have just as much reason to believe they exist as I have to believe those users he mentions exist. Who are the people who are having difficulties because we're not using his proposed more cumbersome ways of editing? He doesn't say! How do those difficulties come about? Not even a hint from SMcCandlish. He asks whether it isn't enough to know those people exist. But I don't know that they exist. I don't know who they are, what they do, why or how the proposed editor-hostile methods are better for them, and SMcCandlish doesn't see fit to say. Can SMcCandlish even name one such user? If so, he hasn't tried to do so.
More than five years ago we switched from using <var>x</var> to using ''x'', and I and many others have devoted efforts over some years to improving articles by changing the obsolete form <var>x</var> to the improved ''x''. If we are asked to go back to the old form, at least some attempt should be made by someone to give some reason why that should be done. SMcCandlish doesn't want to even attempt to do that. Michael Hardy ( talk) 23:49, 13 September 2008 (UTC)
<var>
tag, that number is an exponent. That would not be a logical assumption for the software to make if the character preceding were simply italicized. The intent of semantic code is to allow software, including but not limited to search engines and screen readers, to make decisions such as this with much greater authority in a wide variety of situations.
Sswonk (
talk) 15:27, 14 September 2008 (UTC)
...Oh, I should have said, not that he "tells us that there is some significant portion of Wikipedia users to whom articles will be incomprehensible without the more cumbersome editor-hostile conventions that he wants", but rather that he acts as if we already know that. I still don't see any reason to suspect that any such people exist. Michael Hardy ( talk) 00:42, 14 September 2008 (UTC)
This thing is crap. I reject it. Loisel ( talk) 10:09, 14 September 2008 (UTC)
Patience please. Because my requests to centralize discussion here have largely been ignored, I've been trying to address all of these concerns in three different places, and am now out of time for today. I will try to get back to all of this as soon as possible, probably in a bit under 24 hours as of this timestamp. In the interim, I have addressed some of this already at both WT:MOSMATH and WT:MATH before I tiredly arrived back here again. Please respond here not there, or the discussion will continue to be pointlessly fragmented. Very short response to a couple of the above issues: "Getting worse": I thought I made that really clear, but I'll spell it out again. The fact that a pretty conceptually simple change is angsty is entirely because of the failure to fully separate the content from the presentation despite the fact that this has been advised since ca. 1993 and codified in HTML 4 (now XHTML 1) and CSS 2 ca. 1998 (or maybe 1996; I'm tired and misremembering). Continued failure to get this right will only lead to more and far worse (scale-wise) problems of this sort as WP continues to grow and grow; 20,000 is a much preferable number to 120,000. "Significant portion of Wikipedia users": I must be writing very poorly this week if it isn't clear that the large paragraph of usability material immediately preceding my mention of this significant proportion didn't make it entirely clear that the referents are the visually impaired users I had just been talking about (was that a bad place for a paragraph break or something?), for whom in most cases non-semantic italicization simply doesn't exist. More later. I haven't even gotten to metadata, the semantic Web, more basic reasons for content-presentation separation, actually-proper mathematical style, etc. — SMcCandlish [ talk] [ cont] ‹(-¿-)› 20:06, 14 September 2008 (UTC)
''E'' = ''mc''<sup>2</sup>
and <var>E</var> = <var>mc</var><sup>2</sup>
will be read as "ee is em cee superscript two" (I forgot what they do with superscript, and it probably depends on the actual software you use).sin(''x'' + ''y'')
even though it is better to use non-breaking spaces, as in sin(''x'' + ''y'')
, because I can't be bothered to write the latter. Similarly, I probably won't bother to use <var>.<subject>This</subject> <verb>is</verb> <complement>retarded</complement> <punctuation>.</punctuation> <signature> Loisel ( talk) 14:53, 15 September 2008 (UTC)</signature>
<subject>
). —
SMcCandlish [
talk] [
cont] ‹(-¿-)› 08:20, 16 September 2008 (UTC){{v|E}} = {{v|mc}}<sup>2</sup>
is "variable capital E equals variable m c, superscript 2" (and maybe even better; it will depend on the screen reader app), instead of "e equals m c, superscript 2". Failure to use every feature of XHTML that can be used to enhance accessibility is a decision to intentionally alienate a substantial subset of our readers simply because we can't be bothered.{{v|E}}
is only 2 characters longer than ''E''
, but much richer. The "expense" of 2 characters in human editing time is practically nil, even in an article with 100 cases. If template name length were a significant factor, no one would use template names like {{fact}}
or {{
clarifyme}} – frequently used ones would shortened as much as possible to things like {{f}}
and {{cm}}
, and people would rather have template names like {{f2}}
than {{fact}}
if {{f}}
were already taken.<em>
for emphasis (another good semantic and accessibility move to begin with!) and <i>
for typographic-only italics (e.g. book titles). All that is left italicized will be variables (and perhaps other mathematical items that are also italicized, but which you will already have converted to <i>
markup). A quick global search-replace will convert these variable remainders to {{v}}
. If you personally find this too much work, then just ignore it and do something else you find more interesting; someone else will deal with it later.<div>
and <span>
– but it can be done much more interestingly and seamlessly by applying the microformat classes to even more semantic elements (see some off-WP tutorials for good examples). While I have not researched every single microformat in existence, I would be shocked if there were not some already making use of <var>
, and more will surely come. The rel-tag microformat could certainly make use of <var>
, as could some potential uses of the XOXO mf and obviously the forthcoming measurements mf which will necessarily have to include mathematics. The
semantic Web, the ongoing natural evolution of the Web into a more meaning-rich (as opposed to simply pretty) environment, more easily processed by software to do things helpful for readers, likewise depends completely on
separation of presentation and content. Wikipedia must do this, or it will fall behind and become technologically and information-architecturally archaic in only a handful of coming years. The constantly-developing "
Web 2.0" demands semantic content, not author-side convenience or 1994-style "just make it look right, forget other concerns" markup techniques.{{v|E}}
will be quite specific.<var>
, respecting the maths world's specification that variables are italic and serif.{{v}}
in a selected block). There is also already a WP user script for making {{
and }}
highlighted in the editing window, and other tools will be developed over time that make editing more visually clear.<var>
is for: Despite someone's strained reading above, the HTML/XHTML specs clearly state that <var>
is for "a variable", not "a computer variable" in particular. Specs documents like that are very, very carefully worded and reviewed by hundreds of people for precision and clarity; they mean exactly and quite literally what they say probably >99% of the time. The allegedly problematic distinction between mathematic and other variables is not helped at all by simply italicizing them both. That makes things far worse, because the markup is instantly confused with both emphasis and italics-for-display-purposes-only, by many if not most editors. The different between the eventual {{v}}
(italics and serif) and {{var}}
(italics only) tags and their attendant CSS will help not hinder distinguishing between these two variable types and displaying them properly.<var>
works synergistically with other semantic markup in the
CS context, including <code>
, <kbd>
, and <samp>
. (Not all of these are presently enabled in MediaWiki; a MW Bugzilla bug report has been filed on the matter.)That's all I can think of in one sitting, and sorry it took so long. I'm going to go self-revert the change to the guideline until this plays out more, especially since the solution now advanced requires convincing anyone with an interest in the extant {{ v}} to merge it with {{ view}} and convert existing deployment to the latter so that we can usurp the former. — SMcCandlish [ talk] [ cont] ‹(-¿-)› 10:07, 16 September 2008 (UTC)
<var>E</var> = <var>mc</var><sup>2</sup>
should in fact read <var>E</var> = <var>m</var><var>c</var><sup>2</sup>
as {{
v|m}}
and {{
v|c}}
are two seperate variables and not a single variable {{
v|mc}}
which needs to be squared. (or while I'm nitpicking it should read <var>E</var> = <var>m</var>c<sup>2</sup>
because c is a constant.) Basically your asking too add markup to almost every other character appearing in formula much like the example given above of a sentence in which every word has been marked. A consequence of unreadable code is the it will increase the number of mistakes made in editing and thereby deteriorating the factual accuracy of the wikipedia math content.{{v| }}
template is already much better, and may in fact improve readability over the use quotation marks which can be confusing if a single formula contains both scalar and vector variables.<var>
" position, in favor of {{v}}
(i.e., the code presently at {{
varserif}}). For vector variables, {{
vv}} is available, and it would take about 1 minute to create that, using <var>
to correctly semantically identify it as a variable ([X]HTML not being any more specific than that today), but using CSS to style it as you say, non-italic and boldface - locally-specified styles override globals (that's the "C" in CSS; apologies to all readers who already know this, but I don't want to assume everyone understands how the style cascade works just because I do; such assumptions have already bitten me in the butt here). So, we should (at least so far!) be able to do the full semantic markup with XHTML, though as you note not with wikimarkup ('', etc.) It won't be godlike, but it should suffice and (perhaps more to the point for maths editors) it will also provide a really clear way to identify particular items that need to someday be converted to equivalent by differently-coded particular items in MathML when MediaWiki almost-inevitably but who-knows-when finally supports that. I would agree that an inability to apply the markup consistently would be worse than useless, but fortunately we aren't actually stuck with that, because CSS is so flexible. NB: We could also add XHTML classes to {{v}}
and {{vv}}
to make them further identifiable, and styleable as a class. Question: Would vv need to be non-italic but bold (only), or non-italic, bold and serif? It's 5 seconds coding difference; just want to be clear. PS: My "incorrect use of the markup" was actually an incorrect assumption about relativity; I was not certain at the time of writing that m and c needed to be treated separately or I would have coded it that way, certainly. The idea did occur to me, but I went with the simpler markup on a (bad) hunch. That's probably hysterically funny to you maths geniuses. :-) The really funny part is I actually knew that c was a constant already, from another context, and just plain forgot. So, yes, I certainly agree with your final version – if we were to propose simply using <var>
which obviously isn't viable. Templates with embedded style actually get us much closer to where we want to be (MathML being the actual location...) In closing for now, yes, I am asking to add markup to almost every other character appearing in a formula. But this is already being done anyway. It's simply different, richer markup, that is slightly more complex on a character-by-character basis (more keystrokes) but far richer, and easier to read, and more likely to lead to better formating in 6 months or 6 years or however long it takes for MediaWiki/MathML integration. —
SMcCandlish [
talk] [
cont] ‹(-¿-)› 12:04, 17 September 2008 (UTC)''f''('''x''', ''t'') = ''t''<sup>α</sup>'''x'''•'''v'''
{{v|f}}({{vv|x}}, {{v|t}}) = {{v|t}}<sup>α</sup>{{vv|x}}•{{vv|v}}
class="var-scalar"
.α
referred to your code-form α
, but the latter was not boldfaced in your example, while v
was, and both are said to be constants. But shortly after you say that v
is a vector variable, not a constant. I am thus confused on various points, such as whether constants should be bolded, italicized or neither, and/or whether other typographic constraints are needed. As an example, I will assume for the sake of argument (trusting your prose over your code, since after all we write in natural language better than we do in code) that:<var>
for variables, only, the rest being <span>
s, and in both cases with classes identifying them by type).
{{fn|f}}({{vv|x}}, {{v|t}}) = {{v|t}}<sup>{{ct|α}}</sup>{{vv|x}}•{{ct|v}}
{{v|E}} = {{v|m}}{{ct|c}}<sup>2</sup>
''f''('''x''', ''t'') = ''t''<sup>α</sup>'''x'''•'''v'''
<var>foo</var>
or {{
var|foo}}
<math>
example that the "f" for the function is not actually a regular "f" at all, but the "florin" symbol or something very close to it: ƒ{{maths}}
or {{physics}}
, that contain a <div class="maths">
and end it with a {{mathsend}}
or {{physicsend}}
that closes the div. The site-wide stylesheet would define all this stuff, and {{fn}}
(with <span class="function">)
would simply inherit: div.maths span.function { styles here; }
versus div.physics span.function { different styles here; }
– the CSS wouldn't actually be in {{fn}}
, {{v}}
, etc., just classes. If chemistry and geology and whatever use further different styles, just add more classes. Trivial.{{ct}}
) from the list. Actually we could drop everything but variables, the only one we have an XHTML element for; I just came up with the rest mainly to show that it could be done. Perhaps this is a good
KISS principle case. The simpler version would just be (using non-physics function style in this case) ''f''({{vv|x}}, {{v|t}}) = {{v|t}}<sup>α</sup>{{vv|x}}•v
, and {{v|E}} = {{v|m}}c<sup>2</sup>
.<var>
with appropriate styles as applied by a template with embedded classes or local CSS. Screen readers can recognize them as variables since marked up as such. I don't think users of them turning on the feature to read out all formatting (italics, etc.) can be depended upon just because someone hits a math article, and math appears in many, many pages that are not math articles. At least identifying variables will be a boon to them. —
SMcCandlish [
talk] [
cont] ‹(-¿-)› 19:29, 17 September 2008 (UTC)<var>
tag was never intended to be used in formula markup, its main purpose is to identify variables when used inside a sentence. In which case identifying it as such may be useful. But in the context of a formula it just isn't unless all the other semantics are also tagged and identified. (
TimothyRias (
talk) 08:33, 18 September 2008 (UTC)){{fn|f}}
but {{fnr|ch}}
(fnr = "function, roman").<var>
case (styled as per {{v}}
and {{vv}}
as needed, and with {{
var}} for CS variables), since that's not just a <span>
with visual style attached via a class, but is an actual XHTML element intended for variables that we are simply wasting.<math>
output, with a larger, italic, serif "f", maybe something like div.maths span.function { font-size: 200%; font-style: italic; font-family: serif; }
). XSLT could then be used to transform such markup into MathML or whatever by scripts, other scripts or applications could extract the data from the article (e.g. just "rip" the equation, and insert it into a LaTeX document). And so on. That's quite a bit more ambitious than simply getting <var>
used more often, but it could be done pretty easily (not counting the implementation in extant articles, of course) if
WP:MATH or
WP:UF saw a need for it. So far it sounds like this would be too difficult to use from an editing perspective.{{fn}}
and {{fnr}}
instead of as very specific objects. Some hardcore CSS purists might object, being a little too gung-ho about object-oriented Web development, but they'd be missing the point that there's nothing wrong with a more generic style class to apply if it obviates the need to have an ever-growing number of objects that would eventually exceed the ability of people to remember them all, which would clearly be the case here. But this sounds like a moot point anyway. —
SMcCandlish [
talk] [
cont] ‹(-¿-)› 19:29, 17 September 2008 (UTC)(copied from above) To reply to your last point, screenreaders identifying every variable in an equation as such explicitly will in most cases actual hinder the understanding of a formula. Of all the possible things that in mathematics as a language are expresses through the formatting wether something is a variable is probably the least relevent. The <var>
tag was never intended to be used in formula markup, its main purpose is to identify variables when used inside a sentence. In which case identifying it as such may be useful. But in the context of a formula it just isn't unless all the other semantics are also tagged and identified. (
TimothyRias (
talk) 08:33, 18 September 2008 (UTC))
<mathml xmlns=\"http://www.w3.org/1998/Math/MathML\"> <apply> <eq/> <ci>E</ci> <apply> <times/> <ci>m</ci> <apply> <power/> <csymbol encoding="OpenMath" definitionURL="http://www.openmath.org/cd/physical_consts1.xhtml#speed_of_light" >c</csymbol> <cn>2</cn> </apply> </apply> </apply> </math>
-- Salix alba ( talk) 09:36, 18 September 2008 (UTC)
<math>
work better. If we reached the point where it was always appropriate to use <math>
for any equation or expression, then we could make it contain the marked-up equation in <eqn>
(or not include it, if it turns out not to work). At that point, it might be reasonable for the MoS to specify use of <math>
for any equation or expression and use of <var>
for any isolated variable, constant, or other bit of notation. Unfortunately, changing the operation of <math>
seems to be a bit like fantasizing about proving the
Riemann hypothesis.
Ozob (
talk) 15:24, 18 September 2008 (UTC)<eqn>
that would more likely be <div class="equation">
, and handled with a {{eqn}}
template. That's all also a strictly maths issue, so I think that the discussion has resolved itself for the purposese of
WP:MOSTEXT. Thanks for your participation! :-) —
SMcCandlish [
talk] [
cont] ‹(-¿-)› 21:29, 18 September 2008 (UTC)<var>
in mathematical contexts.
Silence equals assent in consensus debates. Do you really think we need to go through this entire debate all over again? If so, what new arguments do you expect to see from either side? —
SMcCandlish [
talk] [
cont] ‹(-¿-)› 19:26, 19 September 2008 (UTC)
<var>
a "best practice", and I think you're only person vocally arguing for its consistent use. That doesn't mean it's wrong (as I said quite a while ago, I think it's the right thing), but it's not reached consensus. (Yet?)
Ozob (
talk) 20:42, 19 September 2008 (UTC)If there are <var>x</var> apples per basket...
" was an example of a mathematics variable, not a program variable, which further misled me.<var>
is intended for maths after allSee
http://www.whatwg.org/specs/web-apps/current-work/#the-var – the W3C has clarified that in fact <var>
is intended to be used in mathematical formulae. I'm willing to not push on this particular sub-issue, since the
WP:MATH crowd have made a reasonable case that implementation would be difficult. —
SMcCandlish [
talk] [
cont] ‹(-¿-)› 19:26, 19 September 2008 (UTC)
<var>
.
Ozob (
talk) 22:48, 19 September 2008 (UTC)The specification for var
has been changed. The new description of var
reads:
The
var
element represents a variable. This could be an actual variable in a mathematical expression or programming context, or it could just be a term used as a placeholder in prose.In the paragraph below, the letter "n" is being used as a variable in prose:
<p>If there are <var>n</var> pipes leading to the ice cream factory then I expect at <em>least</em> <var>n</var> flavours of ice cream to be available for purchase!</p>For mathematics, in particular for anything beyond the simplest of expressions, MathML is more appropriate. However, the
var
element can still be used to refer to specific variables that are then mentioned in MathML expressions.In this example, Pythagoras' theorem is solved for the variable a. The expression itself is marked up with MathML, but the variable is mentioned in the figure's legend using
var
.<figure> <math> <mi>a</mi> <mo>=</mo> <msqrt> <msup><mi>b</mi><mn>2</mn></msup> <mi>+</mi> <msup><mi>c</mi><mn>2</mn></msup> </msqrt> </math> <legend> Pythagoras' theorem solved for <var>a</var> </legend> </figure>
We did mostly come to a consensus before, so I see no need to reopen the discussion. But I thought that some of you might be interested in this change to the meaning of var
.
Ozob (
talk) 05:24, 18 December 2008 (UTC)
I have to admit I haven't read all of the above, but gather that most maths editors prefer to use ''x'' than <var>x</var>. What seems to have been forgotten is the merge proposal that started at
Wikipedia talk:Manual of Style (dates and numbers)/Archive 111#Text formatting math section merge proposal and
Wikipedia talk:WikiProject Mathematics/Archive 41#Variable format and led to the discussion above and presumably several improvements but apparently no decision on the merge. The merge proposal of the computing and maths variable sections was to
Wikipedia:Manual of Style (dates and numbers), which was disputed and seems clearly wrong to me, and indeed I don't see any current overlap with that WP:MOSNUM. In fact, there is minimal overlap with
MOS:MATH and a "Main" redirect to there. What is currently on this page is suitable for non-technical editors who might quickly want to know how to format scientific terms, and as such I think it should stay. The actual method used to produce italics is less important than what should be italicised (otherwise I might insist that the <dfn>
tag be respected by Mediawiki). I think the merge proposal has fallen by default, so I've removed the template. --
Cedders
tk 21:49, 8 October 2009 (UTC)
In articles about cities and countries, should demonyms be in bold (in the lead)? Dabomb87 ( talk) 22:14, 6 December 2008 (UTC)
In the When not to use emphasis section, why does it state "The following are proposed guidelines"? If that section is being proposed, then should it not be in this guideline? -- Silver Edge ( talk) 05:22, 4 January 2009 (UTC)
It is standard practice in Wikipedia to italicise representations of bird songs and calls (in the real world this is also a standard, but not universal, convention). Following this discussion, Sandy suggested that it should be added to the list of italic usages, but looking at the project page I'm not sure where it fits best. Any ideas? jimfbleak ( talk) 15:18, 10 April 2009 (UTC)
Wikipedia should avoid the use of any font wherein the capital i is an homograph of the lower case l. The font currently used for the titles of articles suffers from this defect. Fonts should be chosen so that there are absolutely no homographs. Jwray ( talk) 03:23, 12 April 2009 (UTC)
There's a trend on Wikipedia for many terms in the Latin language to be set in all-caps, like so:
I understand the rationale — the Latin alphabet didn't gain lower case letterforms until after the time of the Romans. Personally, though, I find this both distracting (in much the same way as overuse of bold or italics) and less accessible (readers with astygmatisms, including myself, find blocks of capital letters more difficult to read).
I'd suggest the spirit of the "don't overemphasise" rule would argue against this use of smaller capital letters, but I don'think there's ever been any discussion on the issue. I'd like to propose that this practice be discontinued. Thoughts, anyone? — OwenBlacker ( Talk) 20:13, 15 April 2009 (UTC)
Follow your sources. These should not be the Pantheon, but a secondary source (that way you get the emendations); this will almost invariably be lower case. This can be modified for uniformity within an article (there's no reason to confuse the reader by switching between upper and lower case just because you changed source), just like the choice between u and v. Septentrionalis PMAnderson 17:00, 16 April 2009 (UTC)