[xwiki-devs] [Rendering 2.0][Vote] About whitespace management in list item context
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. 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. WDYT ? Lucien
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? Thanks -Vincent
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 begining of list item.
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
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 begining of list item.
Could you explain what you mean by "support spaces at begining of list item"? Thanks -Vincent
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.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
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? Thanks -Vincent
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>)* > in place of <#LI: (<SPACE>)* ( ("*")+ (":" | ";")* | ( "1" | "*" )+ "." (":" | ";")* | (":" | ";")+ ) (<SPACE>)+ >
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
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
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
participants (3)
-
Lucien PEREIRA -
Thomas Mortagne -
Vincent Massol