(anonymous guest) (logged out)

Copyright (C) by the contributors. Some rights reserved, license BY-SA.

Sponsored by the Wiki Symposium and the Nuveon GmbH.

 
View Attach Info

Add new attachment

Only authorized users are allowed to upload new attachments.

This page (revision-67) was last changed on 26-Sep-2007 09:44 by ChuckSmith  

This page was created on 09-Jan-2007 20:54 by RadomirDopieralski

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 400 added 22 lines
I am absolutely not in favor of leaving this as a configuration option. Anything that can be configured will be misconfigured. When there is disagreement over the right way to do something, putting in a switch is the easy way out. This tendency has a large part to do with the unusabilty of Unix systems compared with, say, Macs.
[Wikipedia:Darin Adler] told me the way they dealt with these kinds of things at Apple. When an engineer proposes an option, they are forced to choose, and justify, what the default should be. Then, you go back to the question of whether the non-default option is actually needed. According to Darin, and I believe him, most of the time it isn't.
Implementors are, of course, free to vary from the spec. The cost, of course, is reduced interoperability. For some things, like Web protocols, that's a problem, but for linebreaks, people will live. It will just make life less pleasant, that's all.
In the straw poll, we see about a 50-50 split. If implementations follow the same pattern, that about maximizes the probability of problems when cutting and pasting between blogs, and of the user learning experience when contributing to multiple blogs. If we didn't care about those problems, then why bother with a Creole effort at all? Just let each implementor choose the markup language that's best suited to their particular needs.
The arguments against newlines becoming line breaks are clear. First, the probability of unintended linebreaks is high. This is based on empirical evidence: in the blogs that have this behavior, I see them all the time ([example from yesterday|http://atrios.blogspot.com/2007_01_21_atrios_archive.html#116960121787431331]). Second, the long lines make editing painful in many environments other than a textarea with the wrap attribute set to "soft" (which isn't even in current W3C specs, believe it or not). One important such environment is for markup within source code. There are others.
The arguments for newlines becoming line breaks are less compelling to me. First, what is the //real// problem that needs to be solved here. Is it to make it as easy as possible for unsophisticated users to put <br> tags in their markup? Or is the real issue somewhat deeper? After all, there's nothing all that great about <br> itself. It has no real meaning; it's essentially for presentation. So I think it's relevant to ask: are there other, perhaps better, ways of achieving similar presentation goals?
And, to me, the answer is clearly "yes." If you define the problem as the unsightly large vertical gaps between paragraphs, then the obvious solution is to reduce the default paragraph margins (1.33em according to the HTML 4.0 "typical formatting" [stylesheet|http://www.w3.org/TR/REC-CSS2/sample.html]), perhaps adding a text-indent of 1em or so, in line with standard book practice. There are good reasons for the way books are laid out as they are, but I'm inclined to believe that the default large paragraph margins are largely an accident from the early Mosaic implementation.
Another argument I find less than compelling is consistency with Microsoft Word. In fact, the Return key in Word generates a paragraph break, not a line break--the latter is mapped to Shift-Return. Of course, since the default //presentation// of a paragraph break is virtually indistinguishable from a line break, most people don't know the difference. I publish a newsletter where I override these defaults, and I'm constantly having to fix up paragraph vs. linebreak markup. So the linebreak proposal is totally //inconsistent// at the semantic level. (It is, of course, more consistent at the purely presentation level with default settings, because HTML <br> looks just like a Word paragraph break, and HTML <p> looks just like two Word paragraph breaks in a row, but as with anything presentational, that illusion of consistency goes away when you change the stylesheets from the defaults).
I am not arguing that the <br> tag should disappear. I am, rather, arguing that it should be a conscious choice on the part of the author, that they should learn to type {{{\\}}} when they want it. It's relatively rare markup and arguably should be even rarer (especially if we have bulletless lists, which I'm increasingly thinking are a good thing). Therefore, it does not deserve to be mapped to the second-biggest key on the keyboard. And I am also arguing that coming to agreement would ultimately be very beneficial to users, as opposed to encouraging implementors to do their own incompatible things.
So I cannot agree to the compromise currently under consideration. At the very least, I think we need to go through the exercise of deciding which should be the default.
-- [[RaphLevien]], 2007-01-24
Version Date Modified Size Author Changes ... Change note
67 26-Sep-2007 09:44 49.696 kB ChuckSmith to previous restore
66 26-Sep-2007 01:47 49.716 kB 63.241.9.240 to previous | to last
65 25-Sep-2007 23:34 49.696 kB RadomirDopieralski to previous | to last restore
64 25-Sep-2007 19:40 49.72 kB 207.44.238.95 to previous | to last
63 01-Mar-2007 09:06 49.696 kB ChristophSauer to previous | to last typo
62 08-Feb-2007 18:29 49.696 kB YvesPiguet to previous | to last No headings and rules in lists
61 08-Feb-2007 18:07 49.284 kB RadomirDopieralski to previous | to last how do we do it in other contexts?
« This page (revision-67) was last changed on 26-Sep-2007 09:44 by ChuckSmith