Wikipedia talk:Line break handling

From Wikipedia, the free encyclopedia

Shortcut: WT:NOWRAP

Contents 1 Some initial notes and ideas 2 To-do ideas 3 POV, pedagogy and links 4 Simplified section links 5 Firefox bug 6 The current proposal for ,, as markup for the hard space 7 Horizontal scrolling trick for long words

[edit] Some initial notes and ideas

Some months ago we created several new {{nowrap}} related templates and CSS classes, since we had problems to handle line wrapping here at Wikipedia. But now people seem very confused about which nowrap handling method to use when and how. So now I made this how-to guide to explain things. (I hope it will not confuse people even more?)

Since this page might also be read by beginners I added a section about "Causing line breaks", mainly as background information. I hope we can keep that section short.

My intention is that the section "Preventing and controlling word wraps" should be the main focus of this how-to guide.

Some other notes:

• Page names I have considered for this page: Wikipedia:Line break handling, Wikipedia:Word wrap handling, Wikipedia:Line wrap handling and Wikipedia:Nowrap handling.

• Some shortcuts I have considered for this page: WP:NOWRAP, WP:WRAP, WP:NOBR, WP:NBSP, WP:BR and WP:BREAK. (Shortcuts that were already taken are striked out.)

• WP:NBSP links to the very related text Wikipedia:Manual of Style (dates and numbers)#Non-breaking spaces. We should probably link from there to this page. Done.

• We should test the existing {{wbr}} template and if it works well perhaps write something about it here. Didn't work well.

--David Göthberg (talk) 21:07, 11 March 2008 (UTC)

As you pointed out above, the MOS has some stuff to say about spaces and line breaks. We should poke around and see if any other policies have sections concerning this, and be careful to make sure this guide conforms, linking back to those policies where appropriate. We can then link from those policies to here for more general information. On a semi-related note, I added a note to the disambig text at the top of WP:BREAK about this page, but it may be removed, so keep an eye out and feel free to start a talk page discussion there if it does. Other than that, I'll be proofreading the main policy page and making corrections and tweaks as necessary. One final note, could you post a full list of whitespace-related templates here on the talk page? That could help shape the text of the main page. —Dinoguy1000 23:26, 11 March 2008 (UTC)

1. Sure, you can look around for anything related in the policies and guidelines. But what I have seen so far about line wrap handling in the policies and guidelines have mostly been friendly technical advice similar to what this how-to guide contains. But note, this how-to guide isn't a policy or guideline, its a technical how-to guide.
2. Agreed, we should link both to and from any related guideline pages and other pages too. My original purpose of this page was to link to it from all the different nowrap templates.
3. Personally I don't like such shortcuts at all. But I added the WP:NOWRAP shortcut since I expected that people soon would create a shortcut anyway, and then I wanted the shortcut to at-least have a good name. So I have no opinion about the disambig link you made from the WP:BREAK page. (Although I like disambig links in general, they help me as a reader pretty often.)
4. Yes, the page needs proofreading and probably improvements of the explanations too. I bet for starters it has many language errors, after all I am not a native English speaker. The current page is just the first rough version.
5. Eh? "Post a full list of whitespace-related templates here on the talk page"? I guess you mean many of the templates in Category:Wikipedia formatting templates (and those that not yet have been moved there who are still in the old Category:Formatting templates). Yeah there might be more templates like the {{wbr}} lurking around, perhaps not being categorised at all.

--David Göthberg (talk) 04:03, 12 March 2008 (UTC)

Hmm... in that case, I suppose it isn't necessary to worry about it so much.

Heh, I don't see what you could have against the shortcuts, I personally find them quite useful.

Actually, you've done a pretty good job on it. There weren't all that many grammatical errors that I could find – mostly missing commas – but other than that, it was better than some contributions I've seen from native English speakers. One other major thig I did was getting rid of all the <nowiki/> tags, in favor of HTML entities ("&lt;" and "&#123;" for "<" and "{", respectively).

I suppose so... I was referring to the templates similar to {{nowrap}} or {{nowraplinks}}, though if most of them are in a single category, there's probably little point to listing them here...

—Dinoguy1000 17:49, 12 March 2008 (UTC)

Oh, thanks for the work over of the text! (I do have a spell checking add-on in my Firefox, so I am cheating. :) I saw you added some nice improvements, I especially liked the anchor links to the sections. And yeah, the "&lt;" are probably more robust than using the <nowiki> tags, but I tend to be lazy about that...

--David Göthberg (talk) 19:24, 12 March 2008 (UTC)

Hey, no problem... Most of the time, I use IE (not by choice, though), so I usually can't use a spellchecker.

Yeah, I picked up on the anchor links by looking at policy pages (specifically WP:CFD) and wondering how redirects could point directly to sections.

—Dinoguy1000 20:06, 12 March 2008 (UTC)

[edit] To-do ideas

• Add a "Test your page" section about testing the result by dragging the web browser window width, and using several browsers.
• Add a "Dots, bullets and dashes" section about {{·}}, {{ndash}} etc. About how to use them in both link lists and normal text.
• Add a "Style" section:
  • Stating things like that nowrapped sections should never be very long since that will break on small screens and handheld screens.
  • Show less controversial wrapping style examples, like that formulas and equations may be completely surrounded by {{nowrap begin}}+{{nowrap end}}, unless they are humongous... (Of course such formulas should really use TeX.

--David Göthberg (talk) 04:41, 13 March 2008 (UTC)

Nah, that would amount to instruction creep.

--David Göthberg (talk) 05:15, 13 March 2008 (UTC)

[edit] POV, pedagogy and links

I guess it is time for a rant:

Remember that this page is a learning tool. It will hopefully be read by a lot of beginner editors, most of which have no idea about the inner workings of templates and never heard of things like CSS classes. So try to keep things simple and only introduce complicated concepts after the simpler concepts. After all, most editors just need to know how and when to use the nowrap templates, they don't need to understand what makes them tick. (What makes them tick is described on their own doc pages under "Technical details" and should not be in this how-to guide.)

Avoid the "sea of blue" effect. As the Manual of Style puts it: "Make links only where they are relevant to the context: It is not useful and can be very distracting to mark all possible words as hyperlinks. Links should add to the user's experience; they should not detract from it by making the article harder to read."

Should this page be written in a neutral point of view (NPOV)? No, since this is not a Wikipedia article, it is a Wikipedia project namespace how-to guide. It should instead teach best practises. It should not teach things like "You can even use the incorrect <some code>". And yes, it is perfectly okay that this page is mostly based on original research and doesn't have references.

--David Göthberg (talk) 20:01, 13 March 2008 (UTC)

[edit] Simplified section links

Based on the code by User:Dinoguy1000: I added simplified id's to the rest of the section headers that have special characters in their names. So now it is much easier to link to those sections. (Can be good from other pages or talk pages.) Here is a complete list of links to the sections:

• WP:NOWRAP#Causing line breaks
• WP:NOWRAP#Preventing and controlling word wraps
  • WP:NOWRAP#nbsp
  • WP:NOWRAP#nowrap
  • WP:NOWRAP#nowraplinks
    • WP:NOWRAP#Nowraplinks shortcomings
  • WP:NOWRAP#nowrap begin
  • WP:NOWRAP#nobr
• WP:NOWRAP#See also

--David Göthberg (talk) 02:47, 14 March 2008 (UTC)

[edit] Firefox bug

Ouch, I just discovered that the Firefox "expanding out of the box" bug doesn't only apply to {{nowraplinks}}. It applies to any span-nowrap tag, such as the one used in {{nowrap}}. That is, any span-nowrap tag that is immediately followed by text without any spaces between. And it doesn't matter if there is a link inside the span-nowrap tag or just normal text. Here is a code example:

{| class="wikitable"
| 
{{nowrap|[[Salt|some link]]}}SomeText 
{{nowrap|[[Salt|some link]]}}SomeText 
{{nowrap|[[Salt|some link]]}}SomeText 
{{nowrap|[[Salt|some link]]}}SomeText 
| 
{{nowrap|some text}}SomeText 
{{nowrap|some text}}SomeText 
{{nowrap|some text}}SomeText 
{{nowrap|some text}}SomeText 
|}

And here is how it renders. If you have Firefox, try dragging your web browser window so it gets smaller and smaller and see how the text in both cells will overflow:

some linkSomeText some linkSomeText some linkSomeText some linkSomeText

some textSomeText some textSomeText some textSomeText some textSomeText

This also happens if you put two {{nowrap|something}}{{nowrap|something}} next to each other without any space between them.

If you use spaces between the nowrap protected text and the normal text, then if doesn't overflow. Like this:

some link SomeText some link SomeText some link SomeText some link SomeText

some text SomeText some text SomeText some text SomeText some text SomeText

You can also use {{nowrap begin}} + {{wrap}} + {{nowrap end}}, but that also causes a space at the {{wrap}}. Perhaps that is why {{nowrap begin}} doesn't overflow in Firefox?

--David Göthberg (talk) 11:03, 22 March 2008 (UTC)

Note that when it comes to this bug then a non-breaking space   counts as a "normal" character, not as a space. That is, the bug also occurs if you use non-breaking spaces. Like this:

{| class="wikitable"
| 
{{nowrap|[[Salt|some link]]}} SomeText 
{{nowrap|[[Salt|some link]]}} SomeText 
{{nowrap|[[Salt|some link]]}} SomeText 
{{nowrap|[[Salt|some link]]}} SomeText 
| 
{{nowrap|some text}} SomeText 
{{nowrap|some text}} SomeText 
{{nowrap|some text}} SomeText 
{{nowrap|some text}} SomeText 
|}

This too will overflow in Firefox:

some link SomeText some link SomeText some link SomeText some link SomeText

some text SomeText some text SomeText some text SomeText some text SomeText

--David Göthberg (talk) 05:59, 10 April 2008 (UTC)

I found a discussion between Sardanaphalus and Psantora regarding this bug at the talk page of Psantora. Here is a copy of my explanation from there:

I stumbled over your discussion here. As perhaps both of you know this "expanding out of the box" bug is a Firefox bug. So first of all you need to use Firefox to see it. Since we talked before I have learnt more about it and written down parts of it here: Wikipedia talk:Line break handling#Firefox bug. And yes, {{·}} actually does provoke the bug. However, the width of the text you add after each nowrapped string matters. And since {{·}} is fairly narrow (only one non-breaking space and a dot) it only shows the bug a little. That is, the dots usually do not flow outside the box, they just touch the box border. So if that should be considered a problem or not is a matter of taste. Personally I usually don't convert lists to use {{nowrap begin}}+{{·w}}+{{nowrap end}} that only has that minor problem, but I also do not convert lists back to {{·}} just to get the simpler {{·}} code, since {{nowrap begin}} etc renders better.

The bug only becomes a serious problem when one has nowrap protected strings followed or surrounded by several other characters. Like for instance nowraplinks protected links with text around it, like this: [[Some link]] (2008){{·}} or "[[Some link]]"{{·}}. Those two texts have 9 and 4 characters respectively outside the link before the real space. That's enough many characters to expand outside the box and become a real problem.

--David Göthberg (talk) 05:48, 10 April 2008 (UTC)

Thanks as ever for your input, David. I hadn't clocked that ultimately the problem is a bug in Firefox. I don't know whether or not the Firefox developers are aware of it and planning to address it, but if so, that'd be good news as I agree {{·}} would be preferable. I hardly know anything about the world of software development, so I'd be grateful if either of you could point me toward what looks the most appropriate place to make enquiries; there seem to be various possibilities (forums, webpages, perhaps even irc?). Thanks. Sardanaphalus (talk) 14:27, 10 April 2008 (UTC)

I assume you mean you want to report the bug to the Firefox developers? I have been thinking of doing that for some time too. So I took a quick look over at bugzilla.mozilla.org and searched for "nowrap", it turned up at least two bug reports that clearly is the exact same bug:

• Bug report 225946
• Bug report 278891

And there are several other "nowrap" bug reports that seem related. I am going to get myself an account over there so I can write comments at those bug reports telling them those two bugs are the same bug. And also link back here to Wikipedia:Line break handling and it's talk page.

But even if the next version of Firefox is fixed we still have to handle the bug for the next two years or so. And we have the problems with wrapping in several Internet Explorer versions which means we need to use {{nowrap begin}} etc in many places anyway.

By the way, I will copy parts of this discussion to Wikipedia talk:Line break handling#Firefox bug.

--David Göthberg (talk) 15:28, 10 April 2008 (UTC)

Okay, I have reported the bug at bugzilla.mozilla.org. But ouch! The bug was first reported to the Firefox devs at bugzilla.mozilla.org in 2001, then again in 2003 and 2005. But those reports were really bad and confused. (I didn't make a new report, instead I wrote a little at the existing bug reports. But I should probably add a better explanation.) I guess we might have to wait several years before they fix it...

--David Göthberg (talk) 17:10, 10 April 2008 (UTC)

[edit] The current proposal for ,, as markup for the hard space

Editors may be interested in this new section at WT:MOS, where I propose this talkpage for continued discussion of the proposal that we use ,, as markup for the hard space. Here is the current text of the proposal, as recently modified following discussion at WT:MOS:

See a full draft of the proposal

[Stable draft; last amended 11:04, 27 March 2008 (UTC). Development page: WT:NOWRAP.] Better markup for the hard space A proposal to implement ,, as markup for the hard space (&nbsp;) 1. Overview 2. Technical details 3. Objections and replies 4. Implementation 1. Overview The hard space is an important but neglected element in good Wikipedia editing. It stops an unwanted line break, so it is also called no-break space, or non-breaking space. An example (one sort from very many): no line break should occur in "17 sq ft". At present there are two ways to achieve this: first, with the raw HTML &nbsp; code (17&nbsp;sq&nbsp;ft); second, with the {{nowrap}} template ({{nowrap|17 sq ft}}). These options are hard to remember, hard to input, and hard to interpret on the screen. Some cases are far more complex. The solution? Introduce simple new Wikipedia markup, similar to the existing markup for italic (''italic text'') and bold ('''bold text'''). Although these are converted by the system into HTML code (<i>italic text</i> and <b>bold text</b> respectively), the text always appears in the edit box with the markup '' or '''. The proposal simply adapts this useful and accepted idea, to include the hard space. Extensive discussion among interested editors, followed by a poll, shows that ,, (two ordinary commas) is the best markup. When it is implemented, one could type 17,,sq,,ft in the edit box, which would be converted internally to 17&nbsp;sq&nbsp;ft, so that the reader of the article always sees an unbroken "17 sq ft". Editing, we would always still see 17,,sq,,ft. This innovation is easy for experienced editors and welcoming to Wikipedia newcomers, since it is the same style as markup for bold and italics. Analysis shows that comma-based markup could be extended for other formatting and punctuation; but that is beyond the present simple proposal. 2. Technical details The system's existing parsing of markup for italics ('') or bold (''') is a little complex. Those markups are "dual", requiring distinct interpretations as either beginnings (<i>, <b>) or ends (</i>, </b>). Those markups have to coexist with the use of ' as a single quote mark and as an apostrophe. Italics and bold are often applied together: sometimes overlapping, but more often nested like 'this' (markup: ''nested '''like 'this''''''). The WP community accepts the occasional ambiguity, and where the system fails to parse as an editor intends, there are workarounds available. The proposed markup for the hard space will be much more straightforward – for originating editors, subsequent editors, and the system itself. There are no beginnings and ends, just single applications. Still, some slight complexities will arise, and they are easily dealt with. We start with the simplest case: The case of ,, Exactly two adjacent commas will always be parsed as a hard space, yielding the HTML code &nbsp;. Inadvertent typing of ,, instead of , will cause no serious damage: its effect can easily be detected and repaired. The case of ,,, The markup ,, must coexist with the use of , as an ordinary comma in the text, though it will rarely be adjacent to such a comma. If this ever does happen, the natural parsing of ,,, would be as comma + &nbsp;. This could conceivably be needed in a complex subscript, like this: W1, 2, 3, ... , n (markup: W<sub>1,,,2,,,3,,,...,,,n</sub>). It is hard to think of a case in which the reverse would be needed (&nbsp; + comma); but if that ever did arise, <nowiki></nowiki>, &nbsp;, and {{nowrap}} would always be available, as they are now. The case of ,,,, (and higher even numbers of commas) Sometimes more than one hard space is called for: in fine-tuning spacing in tabular work, for example. (This is deprecated by some, but often a convenient solution.) The natural parsing of ,,,, would be as &nbsp; + &nbsp;. A similar interpretation would apply to any string of 2·n commas: it would be parsed as n instances of &nbsp;. And similarly for longer even-numbered strings of commas. If the editor intended comma + &nbsp; + comma, the existing alternative resources should be used. The case of ,,,,, (and higher odd numbers of commas) The sequence ,,,,, would be most unlikely to occur, and might arise more often as an error than as meaning anything specific. But the natural parsing would be comma + &nbsp; + &nbsp;. And similarly for longer odd-numbered strings of commas. If the editor intended &nbsp; + comma + &nbsp;, the existing alternative resources should be used. In short, there is a single rational parsing for any comma-based markup that could arise; and in the rare cases in which no comma-based markup will yield the desired non-breaking HTML code, alternative resources will meet the need as they do now. 3. Objections and replies Objection 1 Hard spaces? I never use them! Why should I care? Good editing requires hard spaces, even if many editors know nothing about them. Wikipedia's Manual of Style (MOS) explains some of their uses; and more uses would be added there, if only the markup were simple enough. Objection 2 The no-break space can already be input with &nbsp;. Recently this code has been attached to a button for insertion, under the edit box. Isn't that enough? There are three points to make. First, the code &nbsp; is hard to remember, hard to type, and hard to interpret on the screen, especially to those who are unfamiliar with HTML. One simple example: an en dash often needs a hard space before it. Consider "89 sq in – 3 sq ft". To keep this from breaking improperly you need to type, or later edit, this code: 89&nbsp;sq&nbsp;in&nbsp;– 3&nbsp;sq&nbsp;ft. Under the proposal, you would simply type this instead: 89,,sq,,in,,– 3,,sq,,ft. Second, note that the goal of wikitext is to abstract HTML codes away from the user, especially for common markup such as ''italics'' and '''bold'''. If the hard space is to be used as often as MOS advocates, it also needs this treatment. Third, the new insert button does not help with interpreting the code seen in the edit box. It helps with inserting: but you still have to find the button, then find your place in the text again. Do you really want to do all that three times, for the example just given? Objection 3 Why not use the Unicode character for the no-break space, attached to an insert button? There is still a problem with insert buttons as a solution. In contrast to &nbsp;, the Unicode non-breaking space is visually indistinguishable from the ordinary space. This is unacceptable, since the editor needs to be able to see the difference in the edit box. Objection 4 There is also a {{nowrap}} template. Why not use that? This template may be useful in some longer phrases that shouldn't be wrapped at any point; but again it is too visually intrusive to be used extensively for single no-break spaces. With the example above, the code would be {{nowrap|89 sq in –}} {{nowrap|3 sq ft}}. And many cases are more complex than that. Currently, {{nowrap}} does not behave well, since a space at the start or end of the enclosed text is rendered in HTML outside of that text, leading to unexpected breaks. There are other templates similar to {{nowrap}} that cater for specialised requirements; but all of these come up against technical inadequacies in the template system itself. And they all use the HTML <span> tag, which is interpreted differently by different browsers with unpredictable results. Use of &nbsp; instead is simpler, more intuitively understandable, and more reliable in its results on the reader's screen no matter which browser is used. That is what the proposal for ,, achieves. Objection 5 I use a non-standard editor with aliasing, so when I want a hard space I type /h to get &nbsp;. Easy! So what's the problem? There are two problems. The code you make is still hard to read and edit; and not everyone can do what you can do. Objection 6 I'm used to &nbsp;. That's what I'll always type! You could do that, of course. You'd still make markup text that's hard to read and hard to edit. Some people (very few!) type <i> and </i> in the edit box. But they'd make life easier for themselves and others if they just typed '' instead. Objection 7 The proposal is technically too hard to implement, and is not standard anywhere. It is in fact easier to implement than '', ''', and other non-standard markup used at Wikipedia (see Technical Details). Wikipedia is the leader in these matters. Our developers have the capacity to innovate, and others would almost certainly respect their precedent, and follow it. Objection 8 The new markup is unintuitive, and unlike anything we have already. In fact it is quite intuitive, at least for editors who are already used to '' and '''. Beginners have to learn that markup: the new markup simply uses , instead of ': similar but distinct characters, both with their own stand-alone uses as apostrophe (or single quote mark) and comma, and both also used in markup. Objection 9 Markup with commas is impractical, and a dead end in development. The comma markup has potential to be extended in all sorts of useful ways. Because a comma hardly ever occurs without a space or a digit after it, it is quite readily available for alternative use. We might in future consider markup like this: ,., (to force a break: equivalent to <br>; ,--, (for an en dash: equivalent to – or &ndash;); and so on. Such markup could be combined: ,,,--, (for an en dash with a hard space before it: equivalent to &nbsp;– or &nbsp;&ndash;). But any such extensions would be negotiable. Accepting the present proposal does not commit anyone to any such extensions. Objection 10 German and some other European languages use the character „ as an opening quote. Markup with ,, could easily be confused with that; and that markup might be needed in future for „ or for some other purpose. In fact there is little likelihood of the two being confused. Their appearances on the screen in common fonts are less similar than the appearances of '' and " are: and we all live with those quite happily. As for reserving ,, for some other purpose, the present proposal makes its own strong case. If others want to make their claim as well, well and good. But we see no evidence of any such claim; and the hard space is of such importance that it is unlikely to be trumped by anything more pressing. After all, those who use „ already have their own established ways of inputting it, just as we do for ". Objection 11 Other changes in the wiki-markup system would be more sweeping and more "wiki-like". Certainly the suggestion is unusual in that it proposes substitution of the single HMTL-entity &nbsp; for the single marker ,,. But the fact that this is easy to implement is not a principled objection, and certainly not a convincing technical objection. The logic of the subsitution is laid out in full above. As for the possibility of overall changes that would make this change redundant, this can be no serious objection either. We have been promised solutions to problems like the one we address here for a long time; but they are not forthcoming, and there seems to be no consultation about them beyond the technical development community within Wikipedia. The present problem has been identified by serious, active editors concerned with style and ease of use, and we find that the proposed solution does all that is needed. If a better solution eventually comes along, no harm has been done in the meantime. Objection 12 It's all too hard! How can editors bring about a change like this? It is hard work to bring about such a change. But the rewards for this simple innovation are significant. And Wikipedia is made up of editors with good ideas that they pursue energetically. That's really what it's all about! Developers and decision-makers will take seriously a proposal that grows out of the concerns of competent and committed editors. 4. Implementation After appropriate discussion at WT:NOWRAP, and possibly at MetaWiki, the coding and system changes for the new markup are a matter for developers. This proposal simply outlines the desired behaviour of the markup (see full specification in Technical details, above), and responds to predicted and actual objections so far. Once the new feature is in place, it would remain harmless and unnoticed by most editors, since they would rarely if ever input two adjacent commas. (This is a virtue of the proposed markup, in fact.) The community will therefore need to be informed of the change. This can be done at a variety of forums, including: Village pump (proposals); Village pump (technical); Village pump (policy); and other Village pump pages Manual of style; Manual of style (dates and numbers); and other MOS pages and talkpages Various community noticeboards Helpdesk; New contributors' help page; How to edit a page; Cheat sheet; and other articles outlining basic editing and markup The details can be determined once the new markup has been accepted for incorporation. In the meantime, nothing is lost through uncertainty and confusion, since the proposal adds a feature, but does not take anything away. In this respect it is safer than almost any alternative. For example, :: has meanings in mathematics (and : has meaning in current wiki markup); ;; may occur when HTML entities fall adjacent to a semicolon (and ; has meaning in wiki markup); `` has a meaning in some existing systems of wiki markup; etc. By notifications as outlined above, and through general community interactions, the new ,, feature should soon become a part of accepted practice, just as '' and ''' are already accepted and appreciated.

Myself, I'll be taking no further part in this in the foreseeable future. But I do hope that other editors will continue their good work on it, and that new editors will join in the effort.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 11:41, 27 March 2008 (UTC)

(Is this where we are supposed to comment?) I am very happy with this proposal. Thanks for the good work, it looks as if you got all the details right. --Hans Adler (talk) 12:58, 27 March 2008 (UTC)

So what's going on with this? —Random832 (contribs) 17:06, 28 March 2008 (UTC)

We are resuming discussion on the proposal after a long interruption, using this page as a venue. The proposal is quite self-explaining; is there any further information that you require? I should be glad to help if I can do so. Waltham, The Duke of 19:17, 28 March 2008 (UTC)

I've read through the proposal a couple of times now, and I've gotta say, it's pretty solid, straightforward, and simple, and I'd really like to see it implemented. —Dinoguy1000 20:04, 28 March 2008 (UTC)

• Yes, I agree – these missing "hard space"s between numbers and abbreviations are something I've become more and more aware of recently. It would also provide an alternative to the {{ndash}} template I've used in this comment. If folk have got used to seeing double/triple primes for italics and bold, I reckon they can adapt to double commas. Thanks to any/all for drawing up the proposal. Sardanaphalus (talk) 12:28, 30 March 2008 (UTC)

If you pull up the source in your browser on "X !", you'll see that the Mediawiki software just inserted an invisible no-break space character. I'm wondering if it would serve our purposes well to get permission for a style bot that wanders around and inserts the same no-break space characters in places where they are almost certain to be an improvement, such as in "p. 1" and "8 sq ft". That might change the argument to make it easier to win, from "Please grant us this special software for this new purpose that people haven't cared about much before" to "Please insert the double-comma in place of the current no-break space character, so that we don't get invisible no-break spaces building up over time in the text, as a result of people not realizing that there was a special character there that needed deleting." WP:STYLE1.0 is a good place to talk about style-standardization bots. - Dan Dank55 (talk) 20:18, 30 March 2008 (UTC)

I think that strategy would be a violation of Wikipedia:Do not disrupt Wikipedia to illustrate a point.

By the way, I checked, there was an invisible space between the "X" and the "!" in the rendered wiki page. How did you make it so that happened? Or why did it happen? But when I added this text and previewed it disappeared and instead the quotes changed to ". But when I saved the text the invisible space was back. (Previous sentence added later.) Weird.

--David Göthberg (talk) 22:57, 30 March 2008 (UTC)

No, running a style-standardization bot without wide consensus from the wikiprojects, or without going through the WP:BOT approval process, would be disruptive; I'm not proposing that we skip any of the required steps. And, if everyone is largely in agreement where the hard spaces should go, it doesn't disrupt Wikipedia to insert them. My point is that, when we go to bugzilla to ask for new markup, it would be a very good idea for the no-break spaces that need replacing with ",," already to be in wide use, to prove the need for the new markup.

The special case of no-break spaces in "X !" and "X ?" was done for the French Wikipedia people, since ! and ? often require a leading space in French, and they didn't want it to wrap. It serves as evidence that the Mediawiki people are willing to write rules for automatic insertion of no-break spaces. - Dan Dank55 (talk) 23:41, 30 March 2008 (UTC)

P.S. And, while there's no particular need to use WP:STYLE1.0 for help with the no-break spaces issue, I have in fact covered two of the required steps already, if you want to take advantage. I've already been to WP:VPP to get approval to gather consensus on style-standardization bots (see discussion at the top of WT:STYLE1.0 if you like), and I've already been to the Wikiproject Council, and they now have a noticeboard available, which they believe is a good, non-spammy way to widely notify wikiprojects about matters of general interest. - Dan Dank55 (talk) 23:50, 30 March 2008 (UTC)

The proposal looks really good. Just one question (please give a link if it has already been answered): have you searched through the WP article database to see if there are any existing uses of ,, that would be affected? Doesn't seem likely, but life is full of surprises... If there are a few cases, that doesn't mean the proposal is wrong, but that the existing ,, would need to be escaped with < nowiki >. --Itub (talk) 16:44, 1 April 2008 (UTC)

That step was taken months ago, and yielded absolutely nothing—not even the proposal's own discussion page. And I have just checked again. I fear that this is beyond the capabilities of Wikipedia's search engine. Waltham, The Duke of 17:16, 1 April 2008 (UTC)

One possible case is programming languages in which you can skip optimal parameters in a function: function(a,b,c,,,f). But it's better style to use spaces after the commas anyway. Of course that's extremely rare, and probably not worth worrying about. --Hans Adler (talk) 19:00, 1 April 2008 (UTC)

That should be a moot point anyways, as I can't think of any situation in which code wouldn't be surrounded by a <source/>, <code/>, or <pre/> tag, except maybe for the occasional one-line snippet. And even in those cases, it's easy enough to just use <nowiki/> or {{nowiki}}. —Dinoguy1000 17:02, 2 April 2008 (UTC)

The vast majority of search engines don't add punctuation characters to their index. Therefore you won't find anything using Wikipedia search or Google. One way to make sure is to take the complete database dump and do a full substring search on it (it could be done using database software or a tool such as grep). --Itub (talk) 08:18, 2 April 2008 (UTC)

If anyone here would do that, a lot of people would be grateful.

In the meanwhile, I shall ponder the propriety of the usage of the word dump for the entirety of Wikipedia's content. :-D Waltham, The Duke of 02:34, 3 April 2008 (UTC)

 :) - Dan Dank55 (talk) 03:39, 3 April 2008 (UTC)

• I'd like to emphasise the importance of this proposal. Its significance, in fact, goes beyong the immediate improvement in MediaWiki's functionality—if we can get something moving here, it will foreshadow more changes to the system, which are much needed after years of relative stasis. TONY (talk) 14:04, 5 April 2008 (UTC)

As a first step, what do you guys think of increasing the number of no-break spaces currently in Wikipedia, before we get the double-commas? I think it's a necessary step. I don't think a "good argument" for why Wikipedia articles should have a lot more no-break spaces (no matter what the markup) is good enough at WP:VPP or bugzilla; they need to see that it has been done already, and that it had wide acceptance. Obviously this could be tedious, but a limited-scope bot (with approval from WP:BOT of course) might help. By hand or by bot, one good place to start sticking no-break spaces in would be in current and recently passed and failed GAN articles, since editors of those articles just recently volunteered their articles to MoS scrutiny ... it would deflect any potential criticism that we're a bunch of marauding wikignomes, inserting new punctuation without being asked. Before we get the double-comma, I would think the invisible no-break space (the one auto-inserted in "X !") would be the least likely to raise a fuss; the fact that it's not great for long-term use because it could build up invisibly in text would give us a great argument for why ",," would be better. Thoughts? - Dan Dank55 (talk) 19:35, 5 April 2008 (UTC)

Bugzilla request for no-break spaces, copied from WT:MoS: "See Bugzilla:13619 for a proposal to add non-breaking spaces automatically. — Omegatron 02:40, 9 April 2008 (UTC)"

- Dan Dank55 (talk) 03:03, 9 April 2008 (UTC)

That doesn't seem to have gone far, does it? Waltham, The Duke of 19:25, 16 April 2008 (UTC)

I don't draw any conclusion from that; nothing in WT:MoS is going far. I'm either talking to myself or answering help questions. I must say, it's much nicer hearing the birds chirp than the usual elephant stampede, but I'm getting a bit lonely. - Dan (talk) 20:06, 16 April 2008 (UTC)

[edit] Horizontal scrolling trick for long words

I wonder if we should suggest this as a general solution, or not. Here's an example of <div style="overflow:auto"> in practice:

It's not elegant, but it gets past the problem of no soft hyphens in MediaWiki. The hard-coding of line breaks is possible, but will have little relationship to the text and browser window size in use by a reader. Note that in such articles only the body text can be given this treatment; the article title will still run off the right margin. --Dhartung | Talk 00:32, 8 April 2008 (UTC)

Unfortunately the "overflow:auto" markup seriously breaks the entire page in older web browsers. That is, in my older web browsers every paragraph on this page now becomes as wide as your "Lopadote" word. I now have to scroll sideways a lot to read each paragraph on this page, making this page pretty unreadable in older browsers.

So I find it better to manually line break such words down to a width below 800x600 pixels. That means in newer browsers (and I hope on the handhelds too since they are new) if they run in less resolution than that only that word will stick out to the right and the user has to use the window scroll bar to read that word. While on the older browsers the page will look okay at any resolution from 800x600 and up. And it will also be better for the old browsers even at lower resolutions such as 640x480, since then all the paragraphs on the page will "only" be 800 wide instead of say 2000 wide.

For users with newer browsers I don't see much difference in using the window scroll bar or the scroll bar next to the word. But for the users with older browsers this pretty much makes the difference between being able to read the page or not.

And by the way, from what I remember last time I tested: It is not MediaWiki who removes the soft hyphens. You can add Unicode soft hyphens and they do get rendered in the XHTML output from MediaWiki, just that even some modern web browsers do not understand them correctly. Some render them as visible spaces, some as visible hyphens, and several don't line wrap at them. So we can not use them.

So sorry. I think we have to stick to manually line wrapping long words such as URLs.

--David Göthberg (talk) 11:33, 8 April 2008 (UTC)

Is there a guideline about what browsers we try to support? Just curious. --Dhartung | Talk 06:18, 10 April 2008 (UTC)

He, good question. I haven't seen any such guideline apart from Wikipedia:Accessibility. But as far as I have understood people here at Wikipedia want to support "all" browsers, even handhelds and screen readers for the blind and so on. (Some of my friends actually read Wikipedia from their mobile phones.) And people often mention that third world users probably often use old computers who can not run the more modern web browsers. (That is, they can not run newer Internet Explorers. They could run Firefox...)

Personally I test in the three browsers I have installed: Internet Explorer 5.5, Firefox 2.0 and Opera 9.02. If it works in all three of them then usually it works in most other browsers too. That IE 5.5 from 2001 is the last IE version that works on my Swedish WinME as far as I know. Yes, some people are still using computers that can not run WinXP but that runs Win98 and WinME fine.

By the way, you are right about that this how-to guide probably should contain some kind of recommendation or discussion about how to handle really long words such as URLs.

--David Göthberg (talk) 07:11, 10 April 2008 (UTC)