2.0.0-beta.0: Both ordered and unordered lists rendered in <ol>

[oal]

In 1.3.x we use the following list formats in our toolbar, which works as expected:

[{ list: 'ordered' }, { list: 'bullet' }]

After upgrading to 2.0.0-beta.0, most things work fine, but both ordered and unordered lists are rendered inside an <ol>.

Example using 1.3.6: https://codepen.io/lindekleiv/pen/jOJByMx (working as expected)

Example using 2.0.0-beta.0: https://codepen.io/lindekleiv/pen/ZEPeLBV (not working as expected)

Do the following in both examples to reproduce the issue:

• Create a bullet list and a few list items.
• Right click, and inspect one of the bullet points. In developer tools, you can see that both kinds of lists are rendered as <ol> in v2, but bullet lists are rendered as <ul> in 1.3.x.

[luin]

Hey @oal 👋

It's an intentional change. Going with all <ol> simplifies the code a lot and also avoiding mass DOM updates when changing list types. We have to undertake a tradeoff that somewhat compromises semantics. In fact, we've never been completely semantic - for example, we indent lists with class names in 1.3.6, instead of using markup hierarchy.

[oal]

Thanks for your reply, @luin!

This seems like a very strange decision. <ul> and <ol> have different semantic meanings, and exists as separate elements for a reason. Ordered lists imply, well, that the elements appear in order, whether that's steps of a recipe, an order of events or similar. Unordered lists do not.

Using ordered lists for all lists does not meet success criterion 1.3.1 (info and relationships) of WCAG.

Even if accessibility of the old version were lacking in places, this seems like a step in the wrong direction. We should strive to create more accessible software, not less. More and more countries have (or will) introduce laws requiring businesses to follow WCAG.

Users of screen readers, and other accessibility tools, should be able to understand structure and intent on the web, without having to rely on visual cues (bullet points vs number prefixes, for example).

Sorry if this sounded harsh - the work you and other contributors put into Quill is greatly appreciated. I just wish you would might reconsider prioritizing accessibility over code size.

[tim-soft]

when saving quill to html -> display html in page
it seems like risky business keeping everything in <ol> but I'm willing to be proven wrong of course

[danielrona]

I find this change weird, especially if intentional, most people probably save the generated HTML directly to the database,
simply because you can then submit this HTML to other webservices as HTML.

Best example is to just check the source for the following two lists, no CSS applied, still rendered correctly.

Simple unordered List

• A
• B
• C

Simple ordered List

1. 1
2. 2
3. 3

[luin]

When saving HTML to database, it's recommended to save the results of quill.getSemanticHTML(), instead of the innerHTML, as latter may contain edit-only elements (e.g. toolbars).

Playground

[danielrona]

@luin I must have missed that, thank you.

[benbro]

Related #979

[luin]

I've locked this ticket because the expected behavior has already been well described and there's no more information needed to address the behavior change. Please open a new ticket if you encountered any bugs with a reproducible example.