On Dec 17, 2008, at 3:39 PM, Thomas Mortagne wrote:
> 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>) >
ok, I'd agree with this one. It makes sense to me too.
Note for others: it still means that entering:
(space)(space)*(space)item
is transformed into:
*(space)item
for example when going from wysiwyg editor to wiki syntax.
Thanks
-Vincent
>> in place of
>>
>> <#LI: (<SPACE>)* ( ("*")+ (":" | ";")* | ( "1" | "*" )+ "." (":" |
>> ";")* | (":" | ";")+ ) (<SPACE>)+ >
>>
>>> Thanks
>>> -Vincent
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
