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: Daniel Cerqueira
Subject: Re: EPUB 3.3 spec conformity issues
Date: Wed, 21 Aug 2024 21:57:28 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

Patrice Dumas <pertusus@free.fr> writes:

> On Tue, Aug 20, 2024 at 11:13:59PM +0100, Daniel Cerqueira wrote:
>> Thinking more deeply, I have changed the HTML.pm patch.
>> 
>> The border property of the table element, if set to "1" (instead of ""),
>> probably is best for HTML generation, and still produces a valid EPUB
>> 3.3.
>
> If we change the border to be 1 for printindex tables, it should be
> because the output is better also in web browsers.  I am not sure that
> it is the case.
>
> Regarding the change of "0" to "", it looks wrong to me, no border
> attribute has been specified with a "0" for a long time and correctly
> rendered.  The border attribute is not in HTML5 anymore, but it is not a
> reason to remove 0 as a possible value -- nor is it a reason to stop
> generating it.
>
> That being said, currently the border of tables output when formatting
> @multitable, @printindex or @cartouche cannot be customized in HTML
> texi2any output except by overriding the conversion functions.


You have not once talked about what border="0" causes on EPUB. And
EPUB is the topic of this thread. 

border="0" on the index table causes the EPUB file to not be in
conformity with the EPUB standard.

And my patches (you may choose any of the two related to the border)
solve this issue for EPUB.

The fact that it slightly changes HTML index tables should be
considerate of minor importance, because it makes EPUB compliant.

Do you want an EPUB not compliant at the cost of minor estetics of
HTML index table? You are choosing poorly.

> I think that it would be better to define classes and use CSS for
> the tables borders.

If this makes EPUB compliant, go for it. But in the meanwhile, while
you don't use CSS inside EPUB (don't know if it is possible and
compliant), you should better consider my patch.

Gavin Smith <gavinsmith0123@gmail.com> writes:

> On Tue, Aug 20, 2024 at 11:13:59PM +0100, Daniel Cerqueira wrote:
>> Thinking more deeply, I have changed the HTML.pm patch.
>> 
>> The border property of the table element, if set to "1" (instead of
>> ""),
>> probably is best for HTML generation, and still produces a valid
>> EPUB
>> 3.3.
>> 
>
> This can't go in as it is as it adds visible borders to the indices
> in all HTML output, not just EPUB3. There is no good reason to add
> such borders.

No, there is a good reason. Making EPUB compliant is a good reason.

Are you guys even using epubcheck on your generated EPUB files?

> This can't go in as it is as it adds visible borders to the indices in
> all
> HTML output, not just EPUB3. There is no good reason to add such
> borders.
>
> I have checked the rendering with border="" and visibile borders are
> also displayed with such an attribute value. Only with border="0" is
> the table rendered with no borders.
>
> According to
>
> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/table#border
>
> the 'border' attribute is deprecated, but we would have to decide
> whether
> we wanted to use CSS instead for this style.

If you have not yet decided if you want to use CSS instead (and it has
to work for EPUB files too, since this is the thread topic), why are
you then discarding my patch?

And if you decide you don't want CSS for EPUB, will this patch remain
in the trash? Probably.

> The EPUB output mode and texi2any itself only exist because of the
> work on unpaid volunteers.

I am an unpaid volunteer, and I am trying to make texinfo better. You
are talking like you are the only ones who are volunteering. With your
leadership, it is hard to help other texinfo users.

Texinfo is producing non-compliant EPUB files!

(This should bother you enough to make something about it).



reply via email to

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