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>&nbsp;&nbsp;bar&nbsp;&nbsp;&nbsp;</li> so I could not determine the real offset of selection in xwiki document source.

This can be solved by not ignoring spaces so render become : < li > &nbsp ;&nbsp ;&nbsp;&nbsp;&nbsp;foo<space>&nbsp;&nbsp;bar&nbsp;&nbsp;&nbsp;</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.

On Wed, Dec 17, 2008 at 1:15 PM, Vincent Massol &lt;vincent(a)massol.net&gt; 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>&nbsp;&nbsp;bar&nbsp;&nbsp;&nbsp;</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 >>> >> &nbsp >> ;&nbsp >> ;&nbsp;&nbsp;&nbsp;foo<space>&nbsp;&nbsp;bar&nbsp;&nbsp;&nbsp;</ >> 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 beginning of list item.

On Wed, Dec 17, 2008 at 3:02 PM, Vincent Massol &lt;vincent(a)massol.net&gt; wrote: > > On Dec 17, 2008, at 2:38 PM, Thomas Mortagne wrote: > >> On Wed, Dec 17, 2008 at 1:15 PM, Vincent Massol &lt;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>&nbsp;&nbsp;bar&nbsp;&nbsp;&nbsp;</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 >>>>> >>>> &nbsp >>>> ;&nbsp >>>> ;&nbsp >>>> ;&nbsp;&nbsp;foo<space>&nbsp;&nbsp;bar&nbsp;&nbsp;&nbsp;</ >>>> 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 beginning of list item. > > Could you explain what you mean by "support spaces at begining of > list > item"? Yes it's not very clear: +1 for not removing first spaces of list item content. In other words +1 for changing the current behavior.