72880 - americanexpress.com - Some links don't display as such

Status: VERIFIED FIXED

(Tech Evangelism Graveyard :: English US, defect, P1)

Description

[Whit Blauvelt]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.19pre17 i686; en-US; 0.8.1)
Gecko/20010321
BuildID:    2001032108

The following code shows a horizontal table with 6 http links, however the first
4 do not show or work as links in Mozilla. These links work normally with
Netscape 4.76.

<table cellpadding="0" cellspacing="0" width="609" border="0">
<tr>
<td width="176"><img src="/amex/images/spacer.gif" width="1" height="1"></td>
<td colspan="12" background="/amex/images/gen-gpixel.gif"><img
src="/amex/images/spacer.gif" width="1" height="1"></td>
</tr>
<tr>
<td><img src="/amex/images/spacer.gif" width="1" height="1"></td>
<td background="/amex/images/gen-gpixel.gif" width="1"><img
src="/amex/images/spacer.gif" width="1" height="1"></td>
<td bgcolor="#FFFFCC" align="center" valign="bottom"><a
href="/servlet/secure/online/account-balances.html"
class="topnavText"/>BANK<br>ACCOUNTS</a></td>
<td background="/amex/images/gen-gpixel.gif" width="1"><img
src="/amex/images/spacer.gif" width="1" height="1"></td>
<td bgcolor="#99CCFF" align="center" valign="bottom"><a
href="/servlet/secure/online/pay-bills-wait.html" class="topnavText"/>PAY<br>
BILLS</a></td>
<td background="/amex/images/gen-gpixel.gif" width="1"><img
src="/amex/images/spacer.gif" width="1" height="1"></td>
<td bgcolor="#99CCFF" align="center" valign="bottom"><a
href="/servlet/secure/online/transfers-wait.html"
class="topnavText"/>TRANSFERS</a></td>
<td background="/amex/images/gen-gpixel.gif" width="1"><img
src="/amex/images/spacer.gif" width="1" height="1"></td>
<td bgcolor="#99CCFF" align="center" valign="bottom"><a
href="/servlet/secure/online/customer-service.html"
class="topnavText"/>CUSTOMER<br> SERVICE</a></td>
<td background="/amex/images/gen-gpixel.gif" width="1"><img
src="/amex/images/spacer.gif" width="1" height="1"></td>
<td bgcolor="#99CCFF" align="center" valign="bottom"><a href="#"
onClick="window.open('/servlet/demoProxy/online/help/bankaccounts.html',
'_blank',
'toolbar=yes,location=no,menubar=no,status=no,resizable=yes,width=800,height=600,scrollbars=yes');"
class="topnavText">HELP</a></td>
<td background="/amex/images/gen-gpixel.gif" width="1"><img
src="/amex/images/spacer.gif" width="1" height="1"></td>
<td bgcolor="#99CCFF" align="center" valign="bottom"><a
href="/servlet/secure/InvalidateSession" class="topnavText">LOGOUT</a></td>
<td background="/amex/images/gen-gpixel.gif" width="1"><img
src="/amex/images/spacer.gif" width="1" height="1"></td>
</tr>
<tr>
<td><img src="/amex/images/spacer.gif" width="1" height="1"></td>
<td colspan="12" background="/amex/images/gen-gpixel.gif"><img
src="/amex/images/spacer.gif" width="1" height="1"></td>
</tr>
</table>


Reproducible: Always
Steps to Reproduce:
1.Go to americanexpress.com/banking/ if you have an account ; >
2.
3.

Comment 1

[Boris Zbarsky [:bzbarsky]]

The links look like this:

<a href="foo"/>text</a>

Since the slash tells us the link is an empty element, we render it empty....

Marking invalid -- the markup is wrong.

Comment 2

[Whit Blauvelt]

I'm understand your argument that the markup is technically wrong. But could you
please explain what the logic of an 'empty link' is? I'm aware of the XHTML
convention of for instance using <br/> rather than <br> because of an obsessive
concern with matching all tags or else explicitly indicating the unmatched with
the otherwise functionless trailing slash - but I'm having trouble imagining any
instance in which a page author would put in an <a href> link and not intend it
to, well, be a link. Is there any use at all for it otherwise? The only
reference I find on w3.org to 'empty links' regards the use of <a name=xxx>
links, not <a href=xxx>. Wouldn't it be a safe rule to assume <a href> links are
never intended to be empty?

Computers should express human intentions as transparently as possible, rather
than force humans into their own mold. If there is no real situation where an
'empty <a href> link' would be used, but there are situations where a page may
be badly coded like this, the best browser logic would be to show the intended
links rather than punish the users of a site for the errors of its designers by
not enabling the links they're wanting to use. Plus, users will gravitate to the
more tolerant - and from their perspective capable - browsers.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Over to parser to look at and make a call.

I could make all the arguments you make in favor of compilers tolerating
"obvious" programming errors and "fixing" them....

Comment 4

[clayton]

Whit: if you have an empty link (or any element in fact) you can use CSS rules
to add "visual content". For example, you could say:

a:before {content: "Click me!";}

Which would show the words Click me! as a clickable link even though the element
itself was empty.

In short, there is value in interpreting empty links as empty. However, this is
a pretty major website so maybe this should be fixed.

Harish, any ideas if this would be a simple fix?

Nominating nsbeta1 not necessarily for a fix, but for investigation.

Comment 5

[harishd]

It's seemingly easy to fix but not actually. It would take a good amount of 
thinking to patch this up. The reason why IE & Nav4.x get this case correct is  
because they simply don't support empty tags ( <element/> ).

I would suggest evangelism.

Comment 6

[harishd]

Evang. --> Arun :)

Comment 7

[Arun Ranganathan]

Questions and Comments:
1.  WHY is there a slash after the quotes?  If the tag isn't intended to be
empty, why does a slash appear, e.g. <a href="locationInQuotes"/>?  IF the slash
intends to show directory structure, it ought to be inside the quotes.  If not,
putting it outside means an empty tag according to the spec., which we adhere to.
2. Here is my take on the "forcing humans to code to the spec. vs. understanding
what they mean despite their errors" issue:  As you know, rigorous adherence to
standards is at the core of powerful ideas like XML, where "tolerant" parsers in
fact violate the standard and specification!  This particular markup is wrong,
but more "tolerant" browsers put up with it.  This was, in fact, the problem
with the older paradigm.  XHTML's notion of strictness envisions a day when user
agents don't just mean browser software running on a PC with enough RAM to
figure things out, but also includes devices which would benefit from tighter
markup and coding.  It is probably easier to evangelize this site to make a
small change which will work equally well on ALL browsers rather than change our
code to accomodate something which is in principle wrong.
3. This bug ought to have been assigned to aruner and not arunr.  Changing...
4. Any tips on who to contact at American Express would go over very well.
-- AKR

Comment 8

[harishd]

Assigning to Arun Ranganathan for real 

Comment 9

[Arun Ranganathan]

cc'ing bclary -- our evang. letter doesn't cover this scenario :-)

Comment 10

[Arun Ranganathan]

reporter! can you verify this again using the latest build?  I have a feeling
they play nicely with us now.  Can you double check?

Comment 11

[Bob Clary [:bc] (inactive)]

results of running this url through validator.w3.org...

    *  Line 1, column 1:

<html>
^

      Error: Missing DOCTYPE declaration at start of document (explanation...)
    * Line 2, column 67:

<head><meta http-equiv="REFRESH" content="0; url=/index.jsp"></head>
^

      Error: missing a required sub-element of "HEAD" (explanation...)

The refresh url is missing a beginning quote and the document has no DOCTYPE but
it is good HTML otherwise.

Comment 12

[Bob Clary [:bc] (inactive)]

We are definitely seeing more and more EMPTY tag problems. The others I have
seen are <option/>.  Should we track them with [SYNTAX-HTML]?

Comment 13

[Bob Clary [:bc] (inactive)]

Arun, stealing this one from you! ;)

Comment 14

[Bob Clary [:bc] (inactive)]

This now redirects you to http://www42.americanexpress.com/index.jsp or another
in their server farm. They no longer appear to use the incorrect empty element
syntax in the a elements, marking fixed.

Comment 15

[Bob Clary [:bc] (inactive)]

All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for
details.

Comment 16

[Brant Gurganus]

Verified
2002022703/WinXP