9 Mar
2009
9 Mar
'09
11:34 a.m.
On Mon, Mar 9, 2009 at 10:02, Vincent Massol <vincent(a)massol.net> wrote:
On Mar 6, 2009, at 3:17 PM, Thomas Mortagne wrote:
[snip]
+1 for C) and D)2) and F) now
+1 for A), B)
+0 for E)
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).
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne