On Wed, Dec 17, 2008 at 1:15 PM, Vincent Massol
<vincent(a)massol.net>
wrote:
On Dec 17, 2008, at 12:57 PM, Lucien PEREIRA wrote:
Hi,
Working on annotation feature, I need to retrieve
xwiki document source code from a selection on XHTML.
This requires to have a correspondence between content
typed by user and content that appears in html.
I noticed in xwiki 2.0 synthax that white spaces typed
in a list item context are ignored :
*<
space
<
space
> <
> space
>
><space><space>foo<space><space><space>bar<space><space><space
renders in XHTML
<li>foo<space> bar </li
so I could not determine the real offset of selection in xwiki
document source.
There's another problem: leading spaces before list items and
headers.
We need to allow them (for several reasons, one of them is for
supporting indenting velocity code when we have velocity mixed with
wiki syntax). So in term of rendering they should be considered as a
ListItemBlock and the spaces should not be rendered.
One problem is when we go through the wysiwyg these spaces will be
removed. Removing them for content not in macros is not such a big
deal IMO (except for Lucien's use case but there are other ways of
doing it for him). Removing them would be a problem when inside
macros. Fortunately we don't touch at macro content for the moment.
This can be solved by not ignoring spaces so
render become :
<
li
 
; 
; foo<space> bar </li
This policy of rendering already exists in underline or italic
context so it's strange to have a different behaviour in list
item context.
Moreover I think we should not suppose what content is
relevant for user or not, so source shouldn't be altered.
We have to alter source in the case of badly formed content, as in
"**bold". We also later for unisignificant escapes (as with
"~hello"'
is transformed into "hello") + some other use cases probably.
Right now I don't have any idea of what to do differently. Only
idea I
could think of would be to have a parameter for list items and
headers, passing to them the number of leading spaces, tabs, etc
but I
don't like this too much.
I think the idea of leaving the content intact is not correct and we
shouldn't expect that behavior for a wiki syntax. A wiki syntax needs
to be as simple as possible for users to use. Allowing leading spaces
go in that direction. OTOH I agree with Lucien that we've decided to
make spaces in paragraph significant so it's not fully consistent.
What do others think?
I agree that it's not alway possible to respect the original source
especially with useless escapes (~toto which become toto).
Now in the case of list item content I think we should support it
because it's exactly the same context that space in a paragraph and
such so it have to behave the same way for consistency.
So +1 to support spaces at begining of list item.