On Mon, Mar 9, 2009 at 10:02, Vincent Massol <[email protected]> wrote: > > On Mar 6, 2009, at 3:17 PM, Thomas Mortagne wrote: > > [snip] > >> I think we can extract 3 concepts from different conversations: >> >> 1) do nothing and let things as it is, meaning spaces are meaningful >> everywhere >> + nothing to do ;) >> - it's not possible to indent content in scripts like velocity or >> cleanly align tables for example >> >> 2) make spaces non-meaningful everywhere and have two different spaces >> in XDOM (space and non breaking space) for "readability" spaces to not >> desapear >> + it's easier to align and indent things everywhere >> - this means XDOM contains useless information for renderer >> - the user has to understand that when he write multiples space it >> will render only one >> - to not break spaces other than non breaking spaces when switching >> from WYSIWYG to wiki, we have to find a way to store the information >> in rendered XHTML >> >> 3) let spaces meaningful by default (in pure wiki content) and modify >> behavior by macros (like make spaces/new lines non meaningful for HTML >> macro etc...) >> + it's more logical for user that HTML macro content apply HTML >> behavior on spaces/newline and in the other hand in the simple wiki >> syntax it's easier to understand for user that 2 spaces will render 2 >> spaces >> - it's not possible to cleanly align table >> >> Notes that spaces before list (<space><space>* item list) or headers >> and generally before standalone blocks, etc. are not part of the >> debate since this was already voted as part of the syntax. >> >> WDYT ? >> >> -1 for 1) I think we have to do something at least about indentation >> in scripts >> >> -0 for 2) I really don't like the idea of having two different spaces >> in XDOM one of them being useless for renderer, for me it's look too >> much like a hack. Also I really think having non meaningful spaces >> does not makes much sense for users, I remember it was a difficult >> concept for me the first time I started to do HTML so I imagine how a >> user that knows nothing about HTML and don't want to can think about >> that. >> >> +1 for 3) since the table align issue is not critical (it's the only >> "issue" I can think of for pure wiki content) and it makes lots of >> sense that HTML macros, Velocity macro and wiki content for example >> are very different contents and should have their own behavior on >> spaces and new lines. Also note that it's still possible align tables >> with spaces but this could not render exactly the same thing that non >> meaningful spaces (sometime the columns will be larger), it's a hack >> but it makes the table align issue a very small issue compared 2) > > Some points: > > A) If the user sets the page syntax to a syntax that has non- > meaningful spaces then the parser (wikimodel for ex) will surely > remove these non meaningful spaces which means any round trip will > loose them. The problem is that all other rendering engines don't > usually do round tripping and don't have this notion of special spaces > that are non meaningful. > > B) After discussing with thomas, we think we could add a new event in > XWiki's rendering for this use case. Something like > onMarker(MarkerType type, String markerString) that would be a generic > marker event. This would be similar to the macro marker event we had > and which I have removed not long ago (since it wasn't absolutely > needed) and which could be added back in a more generic way. This > would allow saving any kind of non-content information in the XDOM and > allow the different renderers to decide what to do with them. > Note that we would need to either make modifications to wikimodel's > events (because of A)) or find ways around it. Need to think more > about it. > > C) for the HTML macro, we propose to make the following changes: > - strip NL/WS between elements (elements that don't accept CDATA) > - strip leading/trailing NL/WS for element content before passing them > to the wiki syntax parser > > D) for the Velocity macro we have 2 choices I can think of: > 1) strip all leading spaces for all lines. note that this means that > inside a velocity macro you wouldn't be able to have a line break with > the new line starting with spaces without escaping the leading space > with ~(space). Note also that this means we will not be able to add > extra new lines to format the text nicely (since that would add new > paragraphs) or split a single line into several lines for extra > readability. This is the case today with the old syntax and it's a > pain not to be able to aerate the text with empty lines. > > Ex: > some text > next line #if (...) this goes on the same line #something(...) #end > > This is a new paragraph > > 2) strip all leading spaces for all lines + remove all new lines too. > This means we need to ensure we still have one space remaining between > "words" (same as HTML). The user would use something like $nl and $sp > to explicitely enter new lines and spaces. The advantage is that you > control completely the formatting (no magic anymore) at the cost of a > little extra work (adding the $nl where required). Basically this > means the same pros/cons as when you work with HTML where you need to > explicitly add <br/> when you want new lines. > > Ex: > some text $nl > next line > > #if (...) > this goes on the same line > #something(...) <-- this is also on the same line > #end > > $nl $nl > This a new paragraph > > Note: I've aerated the text by putting extra new lines around the > velocity #if to show that it would work. > > 3) Same as 1) + strip 1 NL (i.e. line breaks) and only allow "forced" > line breaks with "//". The exact algorithm is: if there's 1 NL remove > it, if there's more than 1 leave them. > > Ex: > some text \\ > next line > #if (...) > this goes on the same line > #something(...) <-- this is also on the same line > #end > > This a new paragraph > > E) We could have a special treatment for table cells and allow heading/ > trailing spaces for cells. Note that this is easy to do but requires > B) so that these spaces are kept when doing a round trip. > > F) Re stripping spaces before block elements as noted by Thomas I'd > like to do that too before 1.8 except for paragraphs since otherwise > this will cause problems with the wysiwyg and users won't be able to > enter leading spaces in paragraphs. > > So I'm +1 with thomas's proposal number 3 above and I'm suggesting > that for the moment we do only C) and D). For D) I'm hesitating > between D) 2) and D) 3).
+1 for C) and D)2) and F) now +1 for A), B) +0 for E) > > WDYT? > > Thanks > -Vincent > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
