Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

epub 3 validation error Error while parsing file 'element "span" not allowed here #2987

Closed
hhsprings opened this issue Sep 30, 2016 · 5 comments

Comments

@hhsprings
Copy link
Contributor

In CPython document, there is following .. index:: usage:

.. index:: single: Year 2038

* The functions in this module may not handle dates and times before the epoch or
  far in the future.  The cut-off point in the future is determined by the C
  library; for 32-bit systems, it is typically in 2038.

.. index::
   single: Year 2000
   single: Y2K

.. _time-y2kissues:

* **Year 2000 (Y2K) issues**: Python depends on the platform's C library, which
  generally doesn't have year 2000 issues, since all dates and times are
  represented internally as seconds since the epoch.  Function :func:`strptime`
  can parse 2-digit years when given ``%y`` format code.  When 2-digit years are
  parsed, they are converted according to the POSIX and ISO C standards: values
  69--99 are mapped to 1969--1999, and values 0--68 are mapped to 2000--2068.

Sphinx builder writes (x)html like this:

<ul class="simple" id="time-y2kissues">
<span id="index-2"></span><li><strong>Year 2000 (Y2K) issues</strong>: Python depends on the platform&#8217;s C library, which <!-- error pos (73) -->
generally doesn&#8217;t have year 2000 issues, since all dates and times are
represented internally as seconds since the epoch.  Function <a class="reference internal" href="#time.strptime" title="time.strptime"><code class="xref py py-func docutils literal"><span class="pre">strptime()</span></code></a>
can parse 2-digit years when given <code class="docutils literal"><span class="pre">%y</span></code> format code.  When 2-digit years are
parsed, they are converted according to the POSIX and ISO C standards: values
69&#8211;99 are mapped to 1969&#8211;1999, and values 0&#8211;68 are mapped to 2000&#8211;2068.</li>
</ul>

This is invalid as html5, so EpubCheck 4.0.1 complains it is error:

Error while parsing file 'element "span" not allowed here; expected the element end-tag or element "li"'.

@tk0miya
Copy link
Member

tk0miya commented Sep 30, 2016

Thank you for reporting.
I'll take a look.

memo: following is reproducible example:

.. _hello0:
.. _hello1:

* test

@tk0miya
Copy link
Member

tk0miya commented Sep 30, 2016

Note: This bug comes from docutils:

$ cat qux.rst
.. _hello0:
.. _hello1:

* test

$ rst2html.py qux.rst
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
...
<ul class="simple" id="hello1">
<span id="hello0"></span><li>test</li>
</ul>
</div>
</body>
</html>

The span element is generated by HTMLTranslator.starttag().
We need to output hyperlink target manually before calling starttag.

@tk0miya tk0miya added this to the 1.5 milestone Sep 30, 2016
@tk0miya
Copy link
Member

tk0miya commented Oct 7, 2016

@tk0miya
Copy link
Member

tk0miya commented Oct 7, 2016

Note: I posted a patch to docutils project:
https://sourceforge.net/p/docutils/patches/134/

@tk0miya tk0miya closed this as completed in 6a68430 Oct 7, 2016
@tk0miya
Copy link
Member

tk0miya commented Oct 7, 2016

To support docutils-0.12, I added the same fix to HTML writer of Sphinx as a ad-hoc fix.
I will remove this if fixed docutils package is released.

Thank you for reporting.

shimizukawa added a commit that referenced this issue Jan 15, 2017
refs #2318: this incorrect rendering was introduced at #2318. In this change, we deprecated 'termsep' and made use of the 'classfire' node generated by docutils. However, at this time, because the HTML tag was outputted according to the node structure of docutils, the display was broken.

refs #2987: This change may affect the #2987 fix. In my environment I could not reproduce the problem.
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 3, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants