"Attribute class redefined" bug in SfW 1.9.0.0 Lists

I am using Scrivener for Windows 1.9.0.0, which Scrivener says is the latest when I check now for updates.

Both Kobo and Google Play rejected my EPUB file generated from v1.9.0.0. (I never had rejections from these sites with previous versions of Scrivener for Windows.)

When I checked the EPUB file with validator.idpf.org/ (EPUB Validator), I got “Error while parsing file ‘Attribute “class” was already specified for element “li”.’.” for each chapter that contained a list (bulleted or numbered).

I then changed the .epub file to a .zip file and opened each of the EPUB-Validator-error-throwing .xhtml files within it in Google Chrome.

Chrome complained with errors like the following:

This page contains the following errors:

error on line 15 at column 83: Attribute class redefined

There seems to be a “list” bug in Scrivener for Windows 1.9.0.0.

Please advise!

I’m getting multiple errors, as well using the validator.

I also noticed the DocType appears on two lines versus one. I’m still going through and trying to correct the issues.

Hoping someone has the answers.

Thank you for bringing this to our attention. I’ve filed this bug in our system.

Hello and happy new 2019 year !

Any update on this issue ? I am using Scrivener 1.9.8 for Windows and this still happens.

I compiled as epub and extracted the archive content, the problem line is :

  • some text
  • It is the last

  • item in an
      list imbricated inside another ul list, but I’m not sure this is relevant as this structure is compiled without error before.

      I am currently investigating using Scrivener as a technical documentation authoring tool because :

    1) write once export to every format and 
    2) online tools are sooooo responsive that what you get is 5 lines of information per screen whatever your display type 
    

    and I was hoping to compile as epub after a judicious use of the “page break before” metadata, then unzip the epub archive to generate a base for static web site pages. So this is rather crippling for my evil intentions to use this versatile product in yet another unexpected way…

    Do you have an idea what element of the document structure is causing the class to be defined twice so I can avoid it until this is fixed ?

    Thanks, S.