[xwiki-devs] [VOTE] Makes list content first spaces meaningful in XWiki 2.0 syntax (was Re: [Rendering 2.0][Vote] About whitespace management in list item context)
Hi devs, We already decided that in a general way, spaces entered by user are meaningful: when you enter "Some<space><space><space>content" you will get in XHTML "<p>Some content</p>" This not fully the case with list for example where: "**<space><space><space>list<space><space><space>content" will give "<li>list content</li>" I propose, for consistency, to make first spaces of list content meaningful like in any other content: "**<space><space><space>list<space><space><space>content" will give "<li> list content</li>" Here is my +1 On Wed, Dec 17, 2008 at 3:50 PM, Vincent Massol <[email protected]> wrote:
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
-- Thomas Mortagne
+1 Lucien Thomas Mortagne wrote:
Hi devs,
We already decided that in a general way, spaces entered by user are meaningful: when you enter
"Some<space><space><space>content"
you will get in XHTML
"<p>Some content</p>"
This not fully the case with list for example where:
"**<space><space><space>list<space><space><space>content"
will give
"<li>list content</li>"
I propose, for consistency, to make first spaces of list content meaningful like in any other content:
"**<space><space><space>list<space><space><space>content"
will give
"<li> list content</li>"
Here is my +1
On Wed, Dec 17, 2008 at 3:50 PM, Vincent Massol <[email protected]> wrote:
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
On Thu, Dec 18, 2008 at 6:01 PM, Thomas Mortagne <[email protected]> wrote:
Hi devs,
We already decided that in a general way, spaces entered by user are meaningful: when you enter
"Some<space><space><space>content"
you will get in XHTML
"<p>Some content</p>"
This not fully the case with list for example where:
"**<space><space><space>list<space><space><space>content"
will give
"<li>list content</li>"
I propose, for consistency, to make first spaces of list content meaningful like in any other content:
"**<space><space><space>list<space><space><space>content"
will give
"<li> list content</li>"
It's "<li> list content</li>" of course as the first space is part of the list syntax.
Here is my +1
On Wed, Dec 17, 2008 at 3:50 PM, Vincent Massol <[email protected]> wrote:
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
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Dec 18, 2008, at 6:09 PM, Thomas Mortagne wrote:
On Thu, Dec 18, 2008 at 6:01 PM, Thomas Mortagne <[email protected]> wrote:
Hi devs,
We already decided that in a general way, spaces entered by user are meaningful: when you enter
"Some<space><space><space>content"
you will get in XHTML
"<p>Some content</p>"
This not fully the case with list for example where:
"**<space><space><space>list<space><space><space>content"
will give
"<li>list content</li>"
I propose, for consistency, to make first spaces of list content meaningful like in any other content:
"**<space><space><space>list<space><space><space>content"
will give
"<li> list content</li>"
It's "<li> list content</li>" of course as the first space is part of the list syntax.
ok then I'm +1 (I was -1 for the previous post ;)). Thanks -Vincent
Here is my +1
On Wed, Dec 17, 2008 at 3:50 PM, Vincent Massol <[email protected]> wrote:
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
+1 JV. On Thu, Dec 18, 2008 at 6:01 PM, Thomas Mortagne <[email protected]> wrote:
Hi devs,
We already decided that in a general way, spaces entered by user are meaningful: when you enter
"Some<space><space><space>content"
you will get in XHTML
"<p>Some content</p>"
This not fully the case with list for example where:
"**<space><space><space>list<space><space><space>content"
will give
"<li>list content</li>"
I propose, for consistency, to make first spaces of list content meaningful like in any other content:
"**<space><space><space>list<space><space><space>content"
will give
"<li> list content</li>"
Here is my +1
On Wed, Dec 17, 2008 at 3:50 PM, Vincent Massol <[email protected]> wrote:
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
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+1 Thomas Mortagne wrote:
Hi devs,
We already decided that in a general way, spaces entered by user are meaningful: when you enter
"Some<space><space><space>content"
you will get in XHTML
"<p>Some content</p>"
This not fully the case with list for example where:
"**<space><space><space>list<space><space><space>content"
will give
"<li>list content</li>"
I propose, for consistency, to make first spaces of list content meaningful like in any other content:
"**<space><space><space>list<space><space><space>content"
will give
"<li> list content</li>"
Here is my +1
On Wed, Dec 17, 2008 at 3:50 PM, Vincent Massol <[email protected]> wrote:
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
participants (5)
-
Jean-Vincent Drean -
Lucien PEREIRA -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol