bug-texinfo
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: EPUB 3.3 spec conformity issues


From: Gavin Smith
Subject: Re: EPUB 3.3 spec conformity issues
Date: Sun, 8 Sep 2024 21:14:15 +0100

On Sun, Sep 08, 2024 at 09:38:13PM +0200, Patrice Dumas wrote:
> On Sun, Sep 08, 2024 at 08:07:41PM +0100, Gavin Smith wrote:
> > On Sun, Sep 08, 2024 at 06:46:39PM +0200, Patrice Dumas wrote:
> > > Hello,
> > > 
> > > I have added the EPUB_STRICT customization variable, it does 2 things
> > > 1) sets dcterms:modified
> > > 2) set an internal customization variable such that td width is not
> > >    set with an attribute but with inline CSS
> > > 
> > > Should I document it?
> > 
> > THanks for doing this.  I don't think it needs to be documented but would
> > needed added as an exception in doc/refcard/txivarcheck.
> 
> It is not set in the default case... If we do not document it, I can't
> see how it would be used (outside of
> maintain/check_epubcheck_texi_t.sh)...

Oh, I thought it would be set in epub3.pm for EPUB output.


> > >   - <a> in <a> for nested @-commands formatted with <a>
> > 
> > This is certainly a bug in texi2any's output but one that may not be
> > easy to fix and only occurs for rare input that the user can change
> > themselves.
> 
> I do not think that it is a bug in texi2any's output.  It is simply that
> Texinfo allow for nested references in some cases, while HTML never
> allows that.  Since the browser render nested <a> as we would expect to
> match Texinfo semantics, I see no point in doing something different in
> texi2any.  We could document that nested Texinfo @-commands output as
> <a> will lead to invalid HTML, to help users change their input, but to
> me that's it.

Ok, it's not a big deal.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]