Closed Bug 160822 Opened 22 years ago Closed 22 years ago

sun.com - After <b> all text is underlined on mouseover

Categories

(Tech Evangelism Graveyard :: English US, defect)

Product:
Tech Evangelism Graveyard
Component:
English US
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: p.boven, Assigned: doronr)

References

(
URL
)

Details

(Whiteboard: [syntax-html]) 

See URL. When moving the mouse across this page, all the paragraphs below (and
including) "Broad Commercial Applications) are underlined on mouseover, as if
they are hyperlinks. This behaviour stops at the next real hyperlink &lt;A href
&gt; but starts again after the next bold part.
Other pages with bold text do not have this problem, and I suspect it's a CSS issue.
Build date 2002072522, platform Solaris 9 (sparc) though I suspect this is also
on other platforms.
(changed &lt;B&gt; in summary to <B>. Can't fix the description, I'm afraid.)
OS: SunOS → Solaris
Summary: After &lt;b&gt; all text is underlined on mouseover → After <b> all text is underlined on mouseover
From what it looks like to me.. this is a tech evang. bug.

Reason?

In the HTML code, there are 'beginning' Anchor tags before bold topics.  There
is NO 'closing' anchor tag.. 

Note the following snippet from the code:
-------------------------------------------------------
<a name="" /><b>The Highest Certification of Any OS</b>
<p>Any operating system [...] </p>
<a name="" /><b>Security from the OS to the Window Environment</b>
<p>Traditionally, system security is [...]
-------------------------------------------------------

As you can see, the anchor tag never really ends.. so the entire section (topic
and paragraph) is included in the anchor.. up to the next defined anchor tag.
(which is why the underlining 'stops' after a hyperlink is reached)

The stylesheet defines:
a:hover (text-decoration:underline)

(The entire stylesheet used can be found here: http://wwws.sun.com/css/default.css )

Mozilla is displaying correctly, as far as I can tell.

--> All
--> Tech. Evang
Component: Browser-General → The Americas
OS: Solaris → All
Product: Browser → Tech Evangelism
Hardware: Sun → All
Version: other → unspecified
Err.. wrong component..
Component --> US General
Component: The Americas → US General
This is an evang bug, but there is nothing wrong with the html.  The source you
quoted actually reads:

<a name=""><b>The Highest Certification of Any OS</b>
</a><p><a name="">Any operating system can be [...] </a></p>

As you can see, the whole paragraph is enclosed in an <a name=""> tag.  As you
mentioned, the stylesheet rule will lead to these paragraphs being underlined on
hover.  For some reason, only certain paragraphs are marked up like this.

I agree - Mozilla is rendering this correctly.
Yup, Mozilla is rendering correctly.. can't believe I missed that missing </A>.
Should we keep this open as Tech Evangelism or close as Invalid?
Malcolm Rowe, I'm not sure exactly where you're seeing the </A> tags...  or do
you mean to say they are implied close tags?  In either case, this bug should
remain open.

The reason only _some_ paragraphs are being underlined, is because of the blue
hyperlinks located within the paragraphs.  The hyperlinks DO contain a </A> tag,
so underline will stop after the link... until a new (bold) topic starts the
underline again.  Once a hyperlink is reached in the paragraph, the _rest_ of
the paragraph (after the link) will have no underline.
Ryan Pertusio:always reassign to the default owner of a component if you change it
Assignee: Matti → doron
QA Contact: asa → zach
Well, now I'm confused.  I got my copy of the source via Mozilla's View Source, 
which shows me the source as I quoted it.  I just tried View Source through 
MSIE5.5, and I get the version you quoted (<a name="" />, which is an XHTML? 
tag with no close required).

Is the server handing out different source to different clients, or is Mozilla 
or MSIE munging it?
Mozilla is definitely munging pages (see bug 57724).

When I save the HTML file to disk... I get the version you (Rowe) found.  If I
dont save the file, but view it 'fresh' from the server, it shows my version. 
In IE, it shows my version, and using the W3C XHTML Validator, I find my
version, again.  Mozilla was munging the page source for ya, Malcolm ;)

Adding a </a> before the paragraph starts does "solve" this problem. XHTML
requires all empty elements to 'close', by using the format <br /> instead of a
closing </br> tag.  The Anchor tag should NOT be an empty tag.. or can it for
'name' anchors? (That is beyond my realm of knowledge).  However, using the W3C
validator, I would assume that the <a> (anchor) tags are never allowed to be empty.

The W3C XHTML Validator ( http://validator.w3.org/ ) shows the following related
errors: 

---------------------------
* Line 118, column 4:

  </td><td valign="top">
      ^

Error: end tag for "A" omitted; possible causes include a missing end tag,
improper nesting of elements, or use of an element where it is not allowed
# Line 90, column 0:

  <a name="" /><b>Excellent Hardware and Software Features and Support</ ...
  ^

Error: start tag was here

---------------------------

  -and-

---------------------------
  <a name="" /><b>Excellent Hardware and Software Features and Support</ ...
             ^

Error: element "A" not allowed here; check which elements this element may be
contained within
---------------------------
Oh, I get it.  It's not View Source, it's the Save Page As... filter that munges
the page (which it needs to do anyway).  I must have looked at the source
through an external program the first time - my mistake!

I just checked the returned document directly (via telnet), and the problems
described are definitely caused because the page is an XHTML document, but it's
served up as text/html.  The server's returned Content-Type is text/html, the
DOCTYPE is HTML 4.01 Transitional, and it has a META HTTP-EQUIV Content-Type of
text/html, but the tag format is XHTML (check out the META tags, too).

The <A name="fred" /> tag in XHTML is perfectly legal, it's directly equivalent
to HTML's <A name="fred"></A>, which marks a document position.  Giving a blank
name is illegal, but beside the point.  Using the XHTML tags in an HTML document
just won't work properly.

Actually, the document isn't even valid XHTML - I just ran it through the w3c
validator, overriding the DOCTYPE to XHTML, and there's a whole load of other
problems, too.

So, in summary: The document is invalid - it's partially XHTML and partially
HTML, it's served as text/html, and Mozilla can't possibly make sense of it
either way.
*** Bug 182903 has been marked as a duplicate of this bug. ***
Joshua, can you help on this by contacting the Webmaster internally ?
Otherwise, sorry for the spam and remove yourself from the CC list. :)

Generic contact is located here:
http://wwws.sun.com/contact/feedback.jsp?referer=http://wwws.sun.com/software/sunone/cover/2002-0507/index.html
Whiteboard: [syntax-html]
Sent feedback e-mail.
Summary: After <b> all text is underlined on mouseover → sun.com - After <b> all text is underlined on mouseover
Sun's Webmaster fixed the code. Now wfm using Mozilla 2002120908 on Linux.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
-> verified
Status: RESOLVED → VERIFIED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.