What Marjolein says is true about the errors with the code but I
think something has been missed in the situational application of the
example. Specifically, since an anchor can *not* contain a block
level element, then the second anchor tag *should* fail as well. Why
you ask - because a closing tag for a block level element cuts off
what follows just as surely as an opening tag for a block level
element.
I believe Russ Thomas' tree is a correct metaphor for this situation
but with an incorrect outcome. Just as surely as the branch begun by
the <table> element gives an "end of stream" for the first anchor
tag, the explicit *ending* of a branch should yield an "end of
stream" for the second anchor tag.
IMHO, *neither* tag should work according to the rules and *any*
attempts to *interpret* an intended outcome will yield an erroneous
result.
Additionally, long gone should be the days when parsers (web
browsers) should be granting leniency to incorrect HTML vis a vis
*predicting* the intention of the author. This sort of flexibility
was originally allowed because this code was being written by hand by
scientists whose simple intention was to provide a visual tweak to
their data as it was shared by the then nacent WWW.
IM(second)HO, current browsers should strictly parse the HTML and
display it on the page. This would at the very least allow for the
determination of *bug* or *not bug* when we see issues such as this.
Now with leniency allowed on this level, we end up in dicussions of
*best method* for interpreting an *error* - intentional in nature or
not. The only *design decision* a browser writer should have is what
standards level to parse unmarked HTML to (i.e., HTMLv2, HTMLv3,
etc.).
And before anyone goes *there*, the excuse that this imperils
attempts to hand-write HTML (which is how I do all mine, btw) because
of the possibility of over-looked tags, copying errors in long
documents, etc. - welcome to writing code. And also to mitigate this
possible handicap, there are a slew of free and very low cost strict
code parsing error checking products on the market.
With all of the current concerns about security, I don't understand
how it can be acceptable behavior to allow a program with as wide a
data-catching net as a web browser to *guess* with information that
is inbound to our networks. This makes everyone who accepts this
*feature* complicit in the security problems on their own networks.
Respectfully,
Martin Maher
gentoo@penguindreams.us
At 22:19 2004-10-29, you wrote:
In isolation, the google href may appear to be the most well-formed, but
since HTML shouldn't be treated as isolated data islands, but instead as a
sequence from beginning to end, the fact that XP SP2 renders
www.google.com as the link is just wrong (even if it does mean the
spoofing attempt fails.)
Excuse me, but I beg to differ.
The HTML standards have some rules and guidelines for how to render valid
code - they do NOT have guidelines for how to render invalid code. And the
example code given clearly is invalid. But there is no "right" or "wrong"
with what a browser does with that.
When a browser (any user agent) encounters invalid code, it can do anything
it "thinks" is appropriate with it (one reason why so many browsers are so
bloated: they do a lot of guesswork). There are no rules.
There are, in fact two errors with the code:
- an anchor cannot contain a block (and a table is a block)
- anchors cannot be nested
What "should" a browser do with these?
- If one takes the first rule, then it seems "natural" for a browser that
does even a little bit of validation in its attempts to guess to discard
the first opening a tag upon encountering the opening table tag going on a
general rule of thumb that an opening block-level tag ends whatever connot
contain a block. (This is why a new opening p tag starts a new paragraph
even if it isn't preceded by a closing p tag.)
- If one takes the second rule - what to do? what to do? Since anchors
cannot be nested, discarding the first opening anchor tag OR ignoring the
second opening tag would seem equally sensible.
--
NTBugtraq Editor's Note:
Want to reply to the person who sent this message? This list is configured such
that just hitting reply is going to result in the message coming to the list,
not to the individual who sent the message. This was done to help reduce the
number of Out of Office messages posters received. So if you want to send a
reply just to the poster, you'll have to copy their email address out of the
message and place it in your TO: field.
--
