On Sat, Jan 3, 2009 at 3:16 PM, Marius Dumitru Florea <[email protected]> wrote:

Thomas Mortagne wrote:

...

Hi xwikiers,

Currently the syntaxes

** list item

and

* ** list item

are giving exactly the same rendering: <ul><li><ul><li>list item</li></ul></li></ul>

This is expected and we have even a unit test for that but I think it's a wrong behavior.

The "problem" is not really at rendering level but at wikimodel XWiki parser which send the same events for the two syntaxes: beginList beginListItem beginList beginListItem [...] endListItem endList endListItem endList

I propose to change that for

** list item

to render

beginList beginList beginListItem [...] endListItem endList endList

and

<ul><ul><li>list item</li></ul></ul>

and same concept for any other list level (like *** , **** , etc.).

...

Since XDOM and XHTML support it, here is my +1.

What do you mean by "XHTML support it"? XHTML 1.0 strict DTD says:

<!-- Unordered list -->

<!ELEMENT ul (li)+> <!ATTLIST ul %attrs;

...

See http://www.w3.org/TR/xhtml1/dtds.html#dtdentry_xhtml1-strict.dtd_ul

Ok, I just tested it by hand in fact I did not even thought of it as invalid so I did not checked the DTD. Does this means it's impossible to have a second level list in XHTML ?

For me

** list item

is not valid since you can't have a 2nd level list without a 1st level one. And even if you consider it valid, I don't see why you need to generate a different, invalid, XHTML for it.

Even if it's not valid for XHTML it should be a XHTML renderer choice and not XWiki parser. For me, on the wiki syntax side, this is perfectly valid, the same way that you can start heading in a page by a second level header for example. Also, it's valid in OpenOffice or MSWord so this is another limitation when importing.

Thanks, Marius

...

See also http://jira.xwiki.org/jira/browse/XWIKI-3057

Thanks,

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne

On Sat, Jan 3, 2009 at 3:57 PM, Marius Dumitru Florea <[email protected]> wrote:

Thomas Mortagne wrote:

...

On Sat, Jan 3, 2009 at 3:16 PM, Marius Dumitru Florea <[email protected]> wrote:

...

Thomas Mortagne wrote:

[snip]

...

Does this means it's impossible to have a second level list in XHTML ?

Yes, afaik a 2nd level list must be nested within a 1st level list item.

I'm planing to overwrite the default support for lists in the WYSIWYG editor (see http://jira.xwiki.org/jira/browse/XWIKI-3061 ) and I'm for preventing Nth level lists without a N-1th level.

...

...

For me

** list item

is not valid since you can't have a 2nd level list without a 1st level one. And even if you consider it valid, I don't see why you need to generate a different, invalid, XHTML for it.

Even if it's not valid for XHTML it should be a XHTML renderer choice and not XWiki parser.

For me, on the wiki syntax side, this is perfectly valid, the same way that you can start heading in a page by a second level header for example.

I really don't see the need for having 2nd level list without a 1st level list. Why would a use want it?

Why not ;) More seriously, adding the first level automatically when user only written second level list in wiki syntax is a specific support and for me it's useless at XWiki parser level. So it's simply easier and cleaner for the code to "support" second level lists. And for me since the grammar support it I don't see why we should not allow it on parser side. The fact that XHTML renderer does not support it has nothing to do with the XWiki parser, it's up to XHTML parser to protect itself since the XDOM allow it, any macro can generate second level list. For example if you only have second and third level headers, toc macro will generate second and first level list. Tox macro should not have to add the first level list item or convert the second level in first level because both are incorrect.

...

Also, it's valid in OpenOffice or MSWord so this is another limitation when importing.

...

Thanks, Marius

...

See also http://jira.xwiki.org/jira/browse/XWIKI-3057

Thanks,

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne

On Sat, Jan 3, 2009 at 4:49 PM, Marius Dumitru Florea < [email protected]> wrote:

Thomas Mortagne wrote:

...

On Sat, Jan 3, 2009 at 3:57 PM, Marius Dumitru Florea <[email protected]> wrote:

...

Thomas Mortagne wrote:

...

On Sat, Jan 3, 2009 at 3:16 PM, Marius Dumitru Florea <[email protected]> wrote:

...

Thomas Mortagne wrote: [snip]

...

Does this means it's impossible to have a second level list in XHTML ? Yes, afaik a 2nd level list must be nested within a 1st level list item.

I'm planing to overwrite the default support for lists in the WYSIWYG editor (see http://jira.xwiki.org/jira/browse/XWIKI-3061 ) and I'm for preventing Nth level lists without a N-1th level.

...

...

For me

** list item

is not valid since you can't have a 2nd level list without a 1st level one. And even if you consider it valid, I don't see why you need to generate a different, invalid, XHTML for it. Even if it's not valid for XHTML it should be a XHTML renderer choice and not XWiki parser.

For me, on the wiki syntax side, this is perfectly valid, the same way that you can start heading in a page by a second level header for example. I really don't see the need for having 2nd level list without a 1st level list. Why would a use want it?

Why not ;)

More seriously, adding the first level automatically when user only written second level list in wiki syntax is a specific support and for me it's useless at XWiki parser level. So it's simply easier and cleaner for the code to "support" second level lists. And for me since the grammar support it I don't see why we should not allow it on parser side.

The fact that XHTML renderer does not support it has nothing to do with the XWiki parser, it's up to XHTML parser to protect itself since the XDOM allow it, any macro can generate second level list. For example if you only have second and third level headers, toc macro will generate second and first level list. Tox macro should not have to add the first level list item or convert the second level in first level because both are incorrect.

Semantically speaking a 2nd level list is a sublist of a 1st level list. Following this logic you can't have a 2nd level list without a 1st level list. I don't see why XDOM supports it.

Regarding the toc macro, I don't see the relation between header level and list level. I guess the toc macro generates:

** h2 **** h4

for

== h2 == ==== h4 ====

while I personally expect

* h2 ** h4

What I expect is that the list level/style is always consitent with the heading level/style: if you have two wiki pages, one with level one headers and the other without level one headers you should not get the same toc IMO.

My fear is that supporting 2nd level list without a 1st level list is going to be a pain for the WYSIWYG.

...

...

...

Also, it's valid in OpenOffice or MSWord so this is another limitation when importing.

...

Thanks, Marius

...

See also http://jira.xwiki.org/jira/browse/XWIKI-3057

Thanks,

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne

Sergiu Dumitriu wrote:

Thomas Mortagne wrote:

...

On Sat, Jan 3, 2009 at 4:49 PM, Marius Dumitru Florea < [email protected]> wrote:

...

Regarding the toc macro, I don't see the relation between header level and list level. I guess the toc macro generates:

** h2 **** h4

for

== h2 == ==== h4 ====

while I personally expect

* h2 ** h4

What I expect is that the list level/style is always consitent with the heading level/style: if you have two wiki pages, one with level one headers and the other without level one headers you should not get the same toc IMO.

How is such a list displayed? I remember trying to do something with nested lists a while back, and the browsers were rendering it differently. Although at the markup level for this scenario ** h2 **** h4 seems better, how will it be rendered?

Here comes the "funny" part: It depends on the generated HTML. Although there's just one way to write valid HTML for nested lists, browsers (FF & IE) can render nested lists in two ways: A) Valid HTML: <ul> <li> <ul> <li>x</li> </ul> </li> </ul> will generate o o x B) Invalid HTML: <ul> <ul> <li>x</li> </ul> </ul> will generate o x as if the list item was indented MS Word-like. I really don't want to handle two kinds of markup for nested lits on the WYSIWYG editor. I'm definitely for valid HTML, thus for A). Otherwise the editor might generate mixed markup like: <ul> <!-- invalid here --> <ul> <li>x</li> <li> <!-- valid here --> <ul> <li>y</li> </ul> </li> </ul> </ul>

o o h2 o o h4

or:

oo h2 oo h4

or:

o h2 o h4

This is browser dependent, and except the last one (which isn't the one that will be rendered) they look somehow wrong to me.

Yet, the ToC macro is not really a problem, because it is macro, and the WYSIWYG should not have to edit it. So, while the renderer could support incorrectly nested lists, I'm still in favor of keeping the WYSIWYG restrictive. This is the web, and this is a wiki, users should not waste time making nicely indented lists, but meaningful correct lists.