Re: A's content model
Murray Maloney <murray@sco.COM>
Date: Thu, 22 Sep 94 12:44:23 EDT
Message-id: <9409221231.aa01080@dali.scocan.sco.COM>
Reply-To: murray@sco.COM
Originator: html-wg@oclc.org
Sender: html-wg@oclc.org
Precedence: bulk
From: Murray Maloney <murray@sco.COM>
To: Multiple recipients of list <html-wg@oclc.org>
Subject: Re: A's content model
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: HTML Working Group (Private)
>
> | Let me try again. Suppose we have:
> | <ul>
> | <li><a href="#l1>src one</a>
> | <li><a href="#l2>dest two</a>
> | <li><a href="#l3>dest three</a>
> | </ul>
> | <ul>
> | <li><a name="l1">dest one: legal and works</a>
> | <li><a name="l2">dest two: illegal, but works
> | <li><a name="l3"></a>dest three: legal, but doesnt work
> | </ul>
> | You will find:
> | link works with Mosaic parses by current DTD
> | 1 YES YES
> | 2 YES NO
> | 3 NO YES
>
> Yes, this is what I found, and why I brought the issue up (though
> I hadn't caught that 1 will work; I tested 3 instead; this is
> seriously strange).
>
> But it is not acceptable that 2 will not parse, although it works.
I'm not sure why you think it unacceptable. It won't parse because
it is not valid HTML 2.0. It works because the browser anticipated
that it might see this.
> While it's not too neat that 3 will parse but not work, that is
> less important.
Au contraire. That is very important. It doesn't much matter that
the browser will accept stuff that is not strictly legal.
It does matter if it won't accept stuff that is strictly legal.
Either we have to rewrite the law (the DTD) or the application(s).
Neither option seems feasible. So what the heck do we do now?
>
> | I see no reason why link #3 shouldn't work. That it does not, I consider
> | a bug in Mosiac.
I agree.
>
> Apparently more slipshod work by the Mosiac designers. Further
> experiment shows that inserting a blank space or a line break within an
> otherwise empty A makes no difference (although to SGML that counts
> as content).
>
> | I also see no technical reason why link #2 shouldn't parse. But
> | it currently doesn't, and the sentiment is that it shouldn't,
> | on the grounds that allowing folks to omit </A> is confusing.
>
> 2 doesn't parse because it doesn't have an end tag, which is
> currently required (we both know this, just repeating it).
>
> Notice that if the A has only a NAME att, it really doesn't matter
> to the application (as distinct from the parser) what the content is;
> that A is only marking a location and creates no hot spot.
>
> We are describing current practice, which is confusing. I think we
> ought to do it thoroughly, which would mean allowing end-tag
> omission on A and warning users that case 2 won't work, even
> though it parses. However, as this is indeed a bad bug in Mosaic
> and time is short, I won't urge the issue further if no one else cares.
>
> --
> Terry Allen (terry@ora.com) Editor, Digital Media Group
> O'Reilly & Associates, Inc. Sebastopol, Calif., 95472