On Wed, Dec 17, 2008 at 3:38 PM, Thomas Mortagne
<[email protected]> wrote:
> On Wed, Dec 17, 2008 at 3:12 PM, Vincent Massol <[email protected]> wrote:
>>
>> On Dec 17, 2008, at 3:07 PM, Thomas Mortagne wrote:
>>
>>> On Wed, Dec 17, 2008 at 3:02 PM, Vincent Massol <[email protected]>
>>> wrote:
>>>>
>>>> On Dec 17, 2008, at 2:38 PM, Thomas Mortagne wrote:
>>>>
>>>>> On Wed, Dec 17, 2008 at 1:15 PM, Vincent Massol <[email protected]>
>>>>> 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 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.
>>
>> This is still not clear.
>>
>> If we don't remove leading spaces is it still a list item?
>>
>> And if it's still a list item how do we implement this since lists are
>> block elements?
>>
>> And what about spaces after the first space after the list item
>> delimiters?
>>
>
> +1 for :
>
> <#LI: (<SPACE>)* ( ("*")+ (":" | ";")* | ( "1" | "*" )+ "." (":" |
> ";")* | (":" | ";")+ ) (<SPACE>)* >
I mean
<#LI: (<SPACE>)* ( ("*")+ (":" | ";")* | ( "1" | "*" )+ "." (":" |
";")* | (":" | ";")+ ) (<SPACE>) >
>
> in place of
>
> <#LI: (<SPACE>)* ( ("*")+ (":" | ";")* | ( "1" | "*" )+ "." (":" |
> ";")* | (":" | ";")+ ) (<SPACE>)+ >
>
>> Thanks
>> -Vincent
>> _______________________________________________
>> devs mailing list
>> [email protected]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
>
> --
> Thomas Mortagne
>
--
Thomas Mortagne
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
