[Top][All Lists]

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

texi2html output validity

From: Ivan Shmakov
Subject: texi2html output validity
Date: Tue, 23 Dec 2014 10:37:11 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

>>>>> David Kastrup <address@hidden> writes:
>>>>> Yuri Khan <address@hidden> writes:
>>>>> On Sun, Dec 21, 2014 at 11:57 PM, David Kastrup <address@hidden> wrote:

 >>> Well, the HTML looks like

 >>> <a 
 >>> href="79/lily-83620d4b.ly"><p>&lsquo;<tt>accidental-ancient.ly</tt>&rsquo;
 >>> </a>    <p>
 >>>  <a href="79/lily-83620d4b.ly">
 >>>   <img align="middle"
 >>>        border="0"
 >>>        src="79/lily-83620d4b.png"
 >>>        alt="[image of music]">
 >>>  </a>
 >>> </p></p>

 >> What?  That isn’t even valid HTML.

 >> In this snippet, I count 2 instances of improper tag nesting,

        I count just a single one, but yes, that second </p> surely
        invalidates the fragment.

 >> 1 use of obsolete element, 2 uses of obsolete attributes and 1
 >> unhelpful alt text.

 > Well, apart from the unhelpful alt text (which is not easy to make
 > more helpful, actually, given the way this is generated), that would
 > be the responsibility of texi2html.  Probably worth reporting to the
 > Texinfo list

        (Hopefully they allow posts from unsubscribed addresses.)

 > and/or proposing a fix.

        I hereby suggest that:

        • the <code /> element is /always/ used instead of <tt />;

        • <img align="ALIGN" border="0" … /> is replaced with
          <img style="text-align: ALIGN; border: 0;" … />;

        • unless there’s a really good reason to nest <p /> inside an
          <a />, – do it in reverse: <p ><a …></a>; for one thing, this
          makes it possible to simply omit any </p>s on output.

        FWIW, the fixed variant (MIMEd) of the example Texinfo-generated
        HTML code (above) fits my reading of the HTML5 TR, and appears
        to satisfy the W3C markup validation service [1] just fine.

 > Now <p> does not need to nest in HTML, and I can't vouch definitely
 > that the second </p> might not belong to some starting <p> I have not
 > cut&pasted.

        As <p /> elements do not nest in HTML, there should /never/ be
        such a “second” </p>.

 > But it's not really pretty and could probably be fixed by just
 > removing the generation of any </p>.

        The TR does /not/ allow one to omit the closing tag when the
        <p /> element is nested /inside/ an <a />.  Either we do it the
        other way around (as suggested above), or we still need to close
        <p /> explicitly, – in that very case, at the least.

[1] http://validator.w3.org/

FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A


[image of music]

reply via email to

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