Re: [xwiki-devs] [Rendering 2.0][Vote] About whitespace management in list item context

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&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. Could you explain what you mean by "support spaces at begining of list item"?