[hypermail] XHTML hypermail... getting there!

From: Jose Kahan <jose.kahan_at_w3.org_at_hypermail-project.org>
Date: Tue, 8 Apr 2003 18:26:22 +0200
Message-ID: <20030408162622.GC10367_at_inrialpes.fr>

Hi!

I'm almost done. I've doing lots of checks to avoid breaking stuff. I've two remaining bugs:

1. XHTML and inline html.

Concerning the problem I'd described earlier on about inlined HTML, the best solution is to use the <object> tag, like we discussed here before and give a CDATA to that object for the alternate content. Something in the lines of

	<object data="path/to/the/file/in/the/att/directory" type="text/hml">
	   HTML attachment: <a href="path/to/the/file/in/the/att/directory">
	     alternate text
	   </a>
	</object>

In order to obtain this, I think that we should change parse.c so that if an attachment or alternative (and we're going to display it) is of type text/html, and it has content-disposition: inline, we should process it in the same way that happens when the inlinehtml option is turned off. And, in addtion, add some kind of flag so that we can generate something similar to the above markup in these cases.

Note that in this respect, hypermail has been always generating invalid documents, independently of the move to XHTML. Using <object> will solve this problem when using the inlinehtml option.

Do many people use this option?

I propose to let this error be for me moment. I'd like to get moving on with the WAI changes and do my first commit for XHTML.

For the moment, we can just disable this option by default and add a message saying "if you activate this option, you'll be generating invalid documents." until there is more time to fix it.

Anyway, letting this error there won't change the behavior of your browser when reading a broken message, unless you explicitly use the XHTML MIME type and that is not advisable today, due to the state of support of this type by existing browsers.

Is this OK with you?

2) the <A HREF= weird convertion

Does anyone knows why there is an exception in print.c:ConvURLsString for handling text that begins with <A HREF= ?

---

    if ((c = strcasestr(line, "<A HREF=\"")) != NULL

         && !strcasestr(c + 9, "mailto")) {
	 parsed = ConvURLsWithHrefs(line, mailid, mailsubject, c);

---

and a further comment saying:

/*

• ConvURLsWithHrefs handles lines with URLs that are already written as
• href's, to avoid having ConvURLsString add a second href to those
• URLs. */

ConvURLsWithHrefs doesn't work correctly for a number of reasons:

1. It assumes we have a URL if it finds the strings <A HREF=" on one end and </A> in the other one.
2. It assumes that whatever is between the <A HREF=" and </A> is a valid HTML and doesn't convert it.
3. It does unexpected things when the message wants to literally quote the markup of <A HREF" </A>. See this example taken from my mbox:

      > (i.e. <A HREF="http://www.t-shirtking.com>">Example of bad > HTML</A>)

      (i.e. <A HREF="http://www.t-shirtking.com>">Example of bad HTML</A>)

4. It won't work unless the <A HREf=" and </A> are in the same line.

5. It assumes the user is writing a URL.

6. And finally (what made me notice it), for XHTML, it should convert

    the <A HREF= </A> markup to lowercase.

I was going to do 6. but as the function seems to have broken heuristics, I think that it's better to supress its call.

What do you think about this?

Thanks for your feedback,

-jose Received on Tue 08 Apr 2003 06:32:56 PM GMT