Academic Kids talk:Span tags

Contents

1 "New" votes 2 What does Span do 3 May discussion 4 Suggest unique headings 5 User-accessible classes in Wikipedia's CSS 6 Other tags 6.1 Another suggestion 6.2 Contrivance 6.3 Tags less important than <span> which are allowed 6.3.1 Tags which would be made unnecessary by <span> 6.3.2 Other tags 6.3.3 Comments about tags less important than <span> 7 Adding to style sheets 8 What do all the tags mean?

"New" votes

Why are "new" votes being seperated from old votes? I don't see any change in content that requires people who have voted to yet again vote. - Tεxτurε 18:33, 3 Aug 2004 (UTC)

It's just to keep things tidy. There's no reason to vote again unless you want to change your old vote. --Eequor 18:38, 3 Aug 2004 (UTC)

What does Span do

Can someone explain to me just what SPAN is used for? Apart from things handled by wikitax like bold and italics. Thanks. --Golbez 00:21, 4 Aug 2004 (UTC)

<span> is the correct way to change properties of text inline without dividing

paragraphs,

as <div> does. <font> can be used instead but that use is deprecated.

^*as should be the excessive use of styles in this paragraph.

--Eequor 21:10, 4 Aug 2004 (UTC)

Very pretty. I realise that you used <font> and <div> rather than <span> because the latter does not work, but are you saying that it works the same, or that other different syntax is needed as well? --Henrygb 00:05, 17 Aug 2004 (UTC)

For us standards buffs, the <span> tag is generally preferable for inline styles because the <font> tag is considered outdated (although it can be used in the same way). --neatnate 00:23, 17 Aug 2004 (UTC)

May discussion

To those who vote "no", I ask the following two questions:

• What do you recommend users do right now if they want to specify language, direction, or style for an inline run of text? Is your suggestion really better than the single change of allowing span tags?
• By voting "no", you are supporting the status quo of allowing all those other HTML tags but not span tags. How can you support the unequal support of all those other tags and not allowing span? On what philosophical basis do you allow big, small, and font tags but not span tags?

Nohat 17:13, 2004 May 4 (UTC)

What is the purpose of this poll? It's up to the developers to take on a project, not for us to try to force them to do anything. RickK 02:27, 4 May 2004 (UTC)

I am inclined to agree with Rickk. →Raul654 02:29, May 4, 2004 (UTC)

It's not really a "project". It's a single-line code change that could easily be a configuration option. Nohat 02:33, 2004 May 4 (UTC) As background, I along with several other users have requested allowing span tags on the mailing lists and have been rebuffed. I thought it was time to have a public debate on the Wiki with the goal of determining whether or not people want them or not. Nohat 02:38, 2004 May 4 (UTC)

Is there anyone who would like to summarise the (presumably technical) objections to allowing <span> tags? --Stormie 02:59, May 4, 2004 (UTC)

I haven't followed this particular discussion, but my main objection would be that every single HTML tag makes wiki pages more difficult to edit. Our replacements aren't always much better (the table syntax in particular can be very frustrating) but they at least go into the right direction. Imagine you're a Ph.D. historian and you're trying to improve an article about the Black Death. "Hey, this is cool, I can edit this page" you think - but then you see a page that is littered with HTML tags, and you are immediately scared away. --Eloquence* 03:18, May 4, 2004 (UTC)

Consider <div style="display:inline"/>, which is currently the only real alternative to <span>. Is that not scarier? Also consider that the entire internet uses HTML, whereas only MediaWiki projects use MediaWiki syntax. It is more reasonable to expect familiarity with HTML than with MediaWiki. I've seen comments by users who were clearly quite comfortable with HTML and totally confused by the new syntax that the wiki imposes on them. In particular, image syntax is not necessarily intuitive, and table syntax can easily become unintelligible. --Eequor 20:19, 1 Aug 2004 (UTC)

My inclination would be to move towards allowing HTML only in the forthcoming Template: namespace (which will replace the MediaWiki: namespace) and to completely cleanse the article source from it. Replace <br> with "\\", improve the image syntax further, etc. While I'm ranting: Why does the source have to include things like [[User:Stormie|Stormie]]? Why not just [[User:Stormie]] and indicate the fact that it's a user page using an icon? Also, the pipe trick shouldn't be resolved on save but on load.

I don't know what the other developers think, but my focus is to make things easier, not more complicated, for people who know nothing about HTML.--Eloquence* 03:18, May 4, 2004 (UTC)

Well, that was eloquently put, Eloquence. :-) I think I will abstain from voting on this one, since on the one hand, I don't want to say "yes" because I largely agree with you, but I also don't want to say "no" without being convinced that the necessary work to remove the requirement for HTML is going strong.. --Stormie 05:27, May 4, 2004 (UTC)

Can't one override the standard Wikipedia CSS definitions if the span tag allows including one's own CSS definitions? Wouldn't that open the door to truly horrendous (malicious) hacks? At least, it seems to me that this would be the end of any uniform appearance of Wikipedia articles. I'm inclined to vote "no" because of this, but would like to see somebody more knowledgeable than me comment on this. It's been a while since I did anything with CSS... Lupo 14:44, 4 May 2004 (UTC)

If this were true (I don't know if it is or not), it would already be possible because inline CSS styles are allowed on all the permitted HTML tags, such as <div>. Nohat 14:51, 2004 May 4 (UTC)

We should be trying hard to get away from all HTML markup (to the point where I'd want no new article to be permitted to contain any)

• one day (soon) we'll want to transcode wikimarkup to something other than HTML (actually, we transcode to XHTML in the forthcoming version, and articles with user-supplied HTML will already make pages fail to validate). We mustn't break transcoding for speech, for any number of small-device XML markups, and for whatever the new new markup is in a few years are all made harder when HTML is present. Wikimarkup needs to outlast HTML.
• user HTML subverts the stylesheet. Everything in the final html code emitted should be styled, both for appearance and particularly for accessibility. Accessibility design in particular is hard and should be done once (in the html/css layer), not done badly or (more likely) not at all in the article's wikitext.
• I see entirely why folks want to use span, and it's very similar to the same reason people used floating DIV tags for images - this exposes a deficiency in the current wikimarkup. The fix is to add support in wikimarkup, not allow it to be circumvented.

• it's unportable - much effort is gone into the stylesheets to make wikimarkup transcode to something that works well on a wide variety of browsers. Authors frequently (>95% of the time) add HTML markup that they've only tested on one, current, browser (those floating image DIVs are notoriously non-portable, whereas the new floaty-image-wikimarkup is perfect everywhere).

These are, I think, good technical reasons for avoiding html beyond the "wikimarkup is easy, html is hard" mention above. -- Finlay McWalter | Talk 16:38, 4 May 2004 (UTC)

Great, I totally agree there should be A Better Way. But until there is, how does allowing span tags make things worse? We already allow tons and tons of other tags, why not span? Nohat 16:53, 2004 May 4 (UTC)

Just because they're allowed does not mean I use them. I personally use only wikicode in wikipedia. This is not because I can't use html, since I am a professional web developer and code css+xhtml1.1. I just know that (x)html is hard to get right even for people who know it really well. I personally would like zero html tags in wikipedia, and use only wikisyntax. If it can't be done in wikisyntax, maybe it shouldn't be done? Christopher Mahan 17:32, 4 May 2004 (UTC)

So correctly displaying runs of foreign text in context shouldn't be done? Nohat 17:36, 2004 May 4 (UTC)

You can't send a subway sandwich by FedEx. It's a limitation of the system.

If you want to change that, propose changes to wikisyntax to support such foreign text. The easy way is not always the best way. Christopher Mahan 18:22, 4 May 2004 (UTC)

I will, I will! But in the meantime, while we debate over the hundred possible permutations of the syntax and which one people want, people will continue to use HTML tags that were not meant for doing the things span tags should be used for, which is decidedly worse than using span tags appropriately. I'm only requesting that span tags be enabled in the interim until a better solution can be developed. We already allow nearly every other HTML tag. I have yet to see one legitimate explanation why all those other tags are allowed but span tags are not. People keep saying the same thing: "we should have less HTML; this should be done via wiki syntax" but no one, not a single person, has explained how allowing span tags would in any way make wikipedia worse. If anything it'll make it better, because it will allow a simple conversion from span tags to the new wiki syntax, whereas not allowing span tags will require figuring out every way people worked around the problem and converting that mess. Is that really what you want? People are already using <font lang="..."> and <font style="..."> tags. Shouldn't we at least make it possible to do it a better way, even if it's not the best way? Nohat 18:34, 2004 May 4 (UTC)

Well, of course. But the better way is to use wikisyntax. Anything short of that will have to be redone. By hand. Christopher Mahan 18:44, 4 May 2004 (UTC)

If people consistently use <span dir="rtl" lang="he"> or <span lang="fr"> then I don't see why after the introduction of a wikisyntax they couldn't be automatically converted by a search and replace through the database. "But the better way is to use wikisyntax." That doesn't mean that allowing span tags isn't better than using font tags.

I'd also like to add that I fully expect all those who vote no on this poll either to actively agitate the developers to disallow support of HTML tags or explain what in specific is wrong with span tags that is not wrong with the other HTML tags. To do otherwise would be hypocritical. Nohat 18:48, 2004 May 4 (UTC)

It's a horrible hack to use a font tag, and it's a horrible hack to use a span tag. Whether one is marginally less horrible is debatable. We shouldn't waste effort twiddling around with one broken solution vs another. I entirely agree that the text-direction thing is urgent (everything else certainly is not). We have to have a hack for it until the new syntax is ready, and we want a means of being able to find and destroy the hack (in whatever nasty form it is) once the syntax is available. Whether it's a span or a font, folks are going to use their own subtle variations, which makes that search-and-destroy phase more difficult. So can't we do something like:

• implement a couple of msg tags, e.g. {{msg:bidi-leftright}} and {{msg:bidi-rightleft}} which implement the text/lang thing using font, i, or whatever unpleasant means is currently necessary
• insist that the above msgs are the only way folks should be doing bidi stuff
• when the new syntax is done, it's easy (for a SQL query or a bot) to find all the bidi msgs and automatically replace them.

Isn't this a less hacky hack, with a credible exit-strategy, than either continuing to use font tags in the article wikitext or merely using span tags instead? -- Finlay McWalter | Talk 18:56, 4 May 2004 (UTC)

I'm not sure why you characterize using span tags as a "horrible hack". It's the HTML-correct way to specify direction or language of an inline run of text. Your solution also doesn't address the problem of language tagging. Farsi, Urdu, and Arabic all use the same alphabet, but Arabic is ordinarily rendered with lots of automatic ligatures and Farsi and Urdu are not. The Unicode characters are the same but the correct rendering is different. The correct way to specify for a run of arabic text what language it is is to use <span lang="ar"&gt: or <span lang="fa">, etc. Similarly, Serbian uses several different glyphs for certain Cyrillic characters when they are italicized, although the Unicode character codes are the same. The only way to tell the browser that a run of text should be rendered as Serbian is by a <span lang="sr"> tag. What is your proposal to solve this problem? Nohat 19:07, 2004 May 4 (UTC)

This isn't an html wiki. It's a wikimarkup wiki. So every use of html is a horrible hack, waiting the day someone writes some wikimarkup handling code to obviate the need for it. To address your specific concern, a lang= attribute can be attached to any tag, so you don't need span, and can use msgs comparable to the above ones. "To do otherwise would be hypocritical". Sigh, now this is turning from a civil technical discussion into mere bickering, and sorry, but that's not I game I'm willing to play. I've said my piece on this subject. -- Finlay McWalter | Talk 19:31, 4 May 2004 (UTC)

It seems to me that {{msg:bidi-rightleft}} rtl txt {{msg:bidi-rightleft-end}} is in fact a worse solution than <span dir="rtl"> rtl text </span>. Not only is it longer, but it's made-up, in that it doesn't conform to any already existing standard for marking up such text. And how is it any more difficult to search-and-replace for <span dir="rtl"> than it is for {{msg:bidi-rightleft}} ? Finally, do you propose creating separate {{msg:lang}}s for every language? How is that better than just allowing <span lange="..."> and replacing those tags with the wiki syntax when (if ever) it is implemented. In fact, in a recent vote, HTML-like syntax was voted for in favor of syntaxes which were more wiki-like, but less HTML-like. This shows me that for rarely-used options, like, say, labeling spans of foreign language text, or hieroglypics, or math, Wikipedians prefer an HTML-like syntax, which span tags are and {{msg:bidi-rightleft}} are not. Nohat 19:52, 2004 May 4 (UTC)

Don't really have the time not the inclination to do any active agitation of developers. They volunteer their time and talent, and I for one am glad they are doing as much as they are already doing. ... As far as the search and replace: good luck. Christopher Mahan 18:58, 4 May 2004 (UTC)

How can you stand against my simple request for allowing span tags but not stand against all the other HTML tags? Nohat 19:07, 2004 May 4 (UTC)

I didn't say I don't stand against other html tags. I just don't want to bother the developers about it. Yours is not a simple request, it's a step in the wrong direction. It's like a drunk at the bar saying: Ahm allreadee dr-unk, so it don't matter if I... burp....have a... one more drink... Christopher Mahan 20:59, 4 May 2004 (UTC)

Suggest unique headings

When setting up poll pages like this in the future, I suggest keeping all headings unique. To this end, I've "disambiguated" the various "Comment" headings. Why? After submitting comments to the page I would always be kicked back to the first "Comment" section rather than the one I was just editing. Very annoying. In addition, I think the "Yes" & "No" (and perhaps "May" & "August") headings should be disambiguated, as well. For example: "Yes to <span> tags", "No to <div> tags", etc. I haven't made these latter changes because I didn't want to disrupt the page too much. Besides, there are so many repeated headings, disambiguating them all would make the TOC very wordy. We should probably just avoid placing so many polls on the same page... - dcljr 00:18, 13 Aug 2004 (UTC)

User-accessible classes in Wikipedia's CSS

Look at the way many Wikipedians have been (incorrectly) putting id="toc" into their navboxes (By the way, a developer has added a class to monobook.css called "toccolours", so you can use class="toccolours" instead).

Has anyone made a systematic catalogue of every application that spans would be used for? User-accessible classes could probably satisfy many of these needs.

Inline styles might be necessary sometimes, but using pre-defined classes would be much better. I would love to see a few classes for common applications be added to the CSS, to compliment span tags. Classes could be profitably applied to spans, divs or tables (what else?).

Advantages of using pre-defined classes over inline styles:

• easier to enter
• less prone to errors (not everyone knows CSS)
• requires less code in the database
• renders less code in the HTML pages
• reinforces consistent style
• co-operates with skins
• more flexible—e.g., update appearance of all navboxes with one style sheet edit

potential applications of classes:

• taxoboxes
• navboxes
• tabular data
• what else?

Think of class attributes as wikimarkup for CSS.

—Michael Z. 00:41, 2004 Oct 27 (UTC)

If developers are worried that spans will be abused, perhaps only some attributes should be allowed, for example:

• allowed
  • lang
  • dir
  • class
• not allowed
  • style
  • id
  • title
  • onmouseover

I completely agree with Michael's proposal, and i think not allowing inline styles makes a lot of sense too. Will help to get an even look that can be tweaked by skin too. Smaller, simpler wiki src anyway. -- Gabriel Wicke 15:06, 30 Jan 2005 (UTC)

I do use inline styles often, mostly in tables. 90% of this would be obviated by two or three pre-set table formats.

I haven't seen any abuse of inline styles, but lots of inconsistency. I have only seen them in monobook.css, and I wonder what effect they have on other skins. —Michael Z. 2005-01-30 17:57 Z

Other tags

Whilst we're here and looking at them, what does <ruby> do, and should the various <table>-related tags be deprecated now we have the wiki-style table markup? --Phil | Talk 16:58, May 4, 2004 (UTC)

<ruby> and the related tags <rb>, <rp>, <rt> are used for the markup of Ruby text, which is not currently supported in most browsers. See that page for an example of marked-up Ruby (which will likely not be displayed correctly in your browser). Nohat 18:29, 2004 May 4 (UTC)

FWIW IE6 and mozilla can both display simple ruby. not sure about the others but ruby written with proper <rp> tags works well in most browsers.Zeimusu

Another suggestion

I agree with nohat that "...for rarely-used options, like, say, labeling spans of foreign language text, or hieroglypics, or math, Wikipedians prefer an HTML-like syntax".

Just as we have HTML-like tags for <math></math> and so on, we should consider having a Wikipedia-specific HTML-like tag for language, <lang="en"> and so on. This would not be HTML: this would be Wiki-markup (just as much so as <math>), which is then rendered to produce appropriate HTML, XHTML, TeX, SGML, etc. etc.

Because it's a pseudo-tag, we could also remove any requirement for nesting, and so allow things like <lang="ar"> <lang="en">...

There's also no need for a LTR/RTL tag: BiDi can be automatically inferred from language, and language tags convey more information than merely direction tags.

Oh, and let's move the en: Wikipedia to UTF-8 ASAP. The longer we wait, the more the pain. -- The Anome 09:20, 5 May 2004 (UTC)

What should the language be after <lang="ar"> ... <lang="en"> ... </lang>? --Eequor 20:28, 1 Aug 2004 (UTC)

Contrivance

It seems overly contrived to provide an example with three <span> tags in one paragraph, especially as the latter two are unlikely to have any effect. -_-;; --Eequor 22:02, 1 Aug 2004 (UTC)

Tags less important than <span> which are allowed

It's surprising how many HTML tags are allowed, given the purported opposition to them. Many are obsolete or redundant, yet they were included anyway.

It can be seen that HTML tags were not included by their merits. Rather, they appear to have been chosen arbitrarily, with no regard for how they might be used or for their appropriateness. Nearly all of the extraneous tags can be easily replaced with <span> or <div>.

Clearly, including <span> need not increase the number of allowed tags; instead, its inclusion would permit 16 tags to be removed. It makes little sense to argue <span> would force users to learn more HTML. If all of the following tags were removed, 18 of the currently allowed 45 would remain. --Eequor 03:44, 2 Aug 2004 (UTC)

Tags which would be made unnecessary by <span>

There are various reasons why the following tags should be removed.

• <b>, <strong>, <i>, <em>

These are redundant with each other and obsoleted by wiki code.

• <font>

Changing fonts mid-article would be very un-wiki.

• <strike>

Redundant with <s>.

For deleted text, use <del>.

• <cite>, <code>, <var>

<code> might have a place on Wikisource, but what of the other two? Where is <samp>?

• <h1>, <h2>, <h3>, <h4>, <h5>, <h6>

These should be the first removed. Non-wiki headings shouldn't be allowed anywhere; they would cause confusion if used because they wouldn't be treated as sections, would go unnoticed by the table of contents, and would not be usable for internal page links.

Other tags

• <dl>, <dt>, <dd>, <ol>, <ul>, <li>

Also obsolete.

• <caption>

Obsoleted by wiki markup.

• <rb>, <rp>, <rt>, <ruby>

These aren't even part of HTML.

• <hr>

Page breaks should not be customizable.

Comments about tags less important than <span>

<font> is unfortunately still necessary in order to set the font to Arial Unicode MS for certain special characters to display correctly. Ruby syntax is part of XHTML. <code> is handy. Otherwise, those should all go, and <span> should come in. — Chameleon Main/Talk/Images 10:12, 2 Aug 2004 (UTC)

Wouldn't using the <font> tag to "set the font to Arial Unicode MS" be exactly the kind of thing we should be discouraging in Wikipedia? Not everyone has Arial Unicode MS! Besides, why that particular font? Wouldn't any Unicode font do (provided it covered the right range of characters)? Why not just rely on the user to have their browsers configured to display Unicode for those who have an appropriate font? - dcljr 03:25, 7 Aug 2004 (UTC)

I agree with Dcljr. It's pretty bad style to assume the existence of any font in a webpage. The right way to do things is to use the standard SGML entities and hope for the best. The font tag is deprecated for good reasons, and we should not be perpetuating it — not even in green signatures. --Ardonik 04:24, 2004 Aug 7 (UTC)

No, no, no, no, no. You don't get it. This is for backward compatibility. If you are using Linux, or any alternative browser, this fix is not necessary and the worse it will do is make the text look slightly different if you have the font installed, and nothing at all if you don't. This is my case. However, Joe Normal is using IE under Windows with all basic Microsoft fonts installed, and no special configuration. The bottom line is that he will see certain special characters (Pinyin, IPA, certain languages...) correctly if we force the font, and see gobbledygook if we don't.

If you say "use the standard SGML entities and hope for the best", in other words "fuck IE users!" I totally understand, I feel like that too. But it's not very nice, is it? Another problem is that IE-using Wikipedians tend to remove such characters from articles (thus making transcriptions incorrect) because they don't display correctly for them. Forcing the font is necessary to stop them doing this. — Chameleon Main/Talk/Images 09:57, 7 Aug 2004 (UTC)

Then why not just place an <!-- HTML-comment --> warning in the source if that's your main concern? - dcljr 22:45, 12 Aug 2004 (UTC)

Or have the software automatically warn users that are editing pages that contain non-ASCII characters? Or something. - dcljr 23:50, 12 Aug 2004 (UTC)

Of course, it would be even cooler if it could be done by CSS. We could mark all special text with a class attribute, and the style sheet could alter the font as necessary Wikipedia-wide. The attribute could be set with <span class="Unicode">, or, even better, with some Wiki markup like <unicode> or __unicode__. — Chameleon Main/Talk/Images 10:04, 7 Aug 2004 (UTC)

I would disagree with the proposal to remove <cite>; eventually, we ought to see all references in the ==See also== and ==Further reading== use it, so that book and magazine titles can be changed with a single CSS setting. --Ardonik 20:20, 2004 Aug 4 (UTC)

It would be simpler to define a new wiki symbol for denoting citations. Perhaps `title` or ~title~ could be used. Better, though, would be a template or template-like directive, so all the parts of the citation can be appropriately formatted:

{{cite:title=title | author=author | publisher=publisher | publication=publication | edition=edition | date=date | pages=pages}}

Which would presumably be formatted into HTML as a number of <span> tags. A normal template of the sort could be made now, except:

• template parameters aren't optional
• <span> is not allowed and so one must use <font> instead
• templates are limited to five occurrences, so a long bibliography would be hopeless

--Eequor 07:06, 7 Aug 2004 (UTC)

You may have missed a few things:

• There is no wikimarkup equivalent for <b> and <i>. Those are presentation options. The wiki markup features '' and ''' are for semantic markup, not presentation. That's why we emphasize the subject of an article - we aren't making it bold, we're emphasising its importance. It happens that may browsers, but not all, display them as bold or italic. If you want bold or italic you should be using bold or italic, not emphasise or emphasise more.
• Changing font is not unwiki. It's necessary for some characters to display and necessary, until there is CSS for it, to do useful things like attractive and readily readable table layouts - see Periodic table for an example which also illustrates just much ugly and repetitive font use is required for an obviously good purpose because we don't have span.
• <cite>, <code> and <var> are cases where you're again confusing presentation and semantic markup. Code and cittions are common and provide useful hints to search engines about the nature of the content. Using presentation markup does not provide that semantic information.
• Headings are probably very uncommon - would be interesting to know where and why they are used. I expect there are cases where wiki markup breaks and heading levels are necessary, though.
• What markup do we have to replace <dl>, <dt> and <dd>? Those are definition lists. Again, you appear to be confusing presentation and semantic markup. We have list markup but lists are not definitions and won't be picked up as definitions by search engines looking for a definition.
• <hr> is not used for page breaks. It's used for logical division of content. Jamesday 15:10, 26 Sep 2004 (UTC)
• Headings <h2>, <h3>, <h4> are required where the heading fonts and structured display are required for readability of text on the page, but where the logic of the page and display favors excluding headings from the Table of Contents. See Human for an example. ---Rednblu | Talk 12:46, 23 Nov 2004 (UTC)

Adding to style sheets

"...since MediaWiki now has a way to add to the global stylesheets in the wiki (at least for the main skins)"

How? —Michael Z. 2005-01-29 07:15 Z

MediaWiki:Monobook.css, MediaWiki:Standard.css and so on. A generic MediaWiki:Contentstyles that's included by all skins is something i plan to add, just didn't get around to do it yet. Math exams coming up, life will be more relaxed by end of February.. -- Gabriel Wicke 15:01, 30 Jan 2005 (UTC)

What do all the tags mean?

It would be helpful if someone could add by all the html tags that are listed on the project page an explanation as to what each of them does? It would be helpful for those who are not familiar with html but are keen to use what we have available to us to improve Wikipedia. Thanks, jguk 07:48, 8 May 2005 (UTC)