167467 - list item with anchor adds unwanted carriage return

Status: VERIFIED INVALID

(Core :: DOM: HTML Parser, defect)

Description

[Rodney Lai]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2a) Gecko/20020908
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2a) Gecko/20020908

list item with anchor adds unwanted carriage return
when there is another anchor outside the list.

Reproducible: Always

Steps to Reproduce:
1. Go To http://www.hyjinxzone.com/test.html

Actual Results:  
hello

    * this should be
all one line 

Expected Results:  
hello

    * this should be all one line

Comment 1

[Boris Zbarsky [:bzbarsky]]

The document tree you get from that (invalid in a number of ways, I must add)
markup once it goes through the parser is:

<a></a>
<ul> 
  <a> <li> text </li> </a>
  <a> more text </a>
</ul>

How would you expect that to lay out?  It's too bad that the W3C validator
actually passes this page... The page is violating Appendic C, section C.3 of
the XHTML 1.0 specification, so even serving it as text/html is invalid...

Comment 2

[Elmar Ludwig]

Well, Appendix C is informative only. But section 4.3 states that:

"All elements other than those declared in the DTD as EMPTY must have an end tag.
Elements that are declared in the DTD as EMPTY can have an end tag or can use
empty element shorthand." (<a> is not declared as EMPTY)

So, while this page is valid XML, it does not seem to be valid XHTML.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Appendix C is normative if you're sending your data as text/html.  You may label
your XHTML as text/html only if it satisfies the guidelines in appendix C.

Comment 4

[Elmar Ludwig]

You are right regarding sending this as text/html (hadn't thought about that),
although it doesn't really matter here why the markup is invalid... ;-)

So, unless the Parser team wants to do something about this, I'd say this bug
is INVALID as well.

Comment 5

[Christopher Hoess (gone)]

INVALID, or dupe of our "XML-constructs-in-XHTML-as-text/html not supported" bug
if someone wants to be fussy.

Comment 6

[:Gavin Sharp [email: [e-mail]]]

*** Bug 241367 has been marked as a duplicate of this bug. ***

Comment 7

[Dave Gross]

This bug is NOT resolved, and it isn't a symptom of poorly-formed xhtml. 
Properly-formed xhtml also exhibits this bug.  See the test cases in Bug 241367
for instance http://www.sniggle.net/Experiment/index.php?entry=19Aug04.

Comment 8

[Boris Zbarsky [:bzbarsky]]

It's resolved _invalid_.  As in, not a bug.

> Properly-formed xhtml also exhibits this bug. 

The document you cite is being served as text/html, but does not comply with
Appendix C of the XHTML specification.  Therefore, it's not valid XHTML.

Please do make sure to read the specifications and understand them before
claiming that a page is valid.

Comment 9

[Dave Gross]

The W3C validator does not complain about the page:

http://validator.w3.org/check?verbose=1&uri=http%3A//www.sniggle.net/Experiment/index.php%3Fentry%3D19Aug04

And yet the page exhibits this bug.

This page from the same site also validates and also shows the bug:
http://validator.w3.org/check?verbose=1&uri=http%3A//www.sniggle.net/Experiment/index.php%3Fentry%3Drtcg

Mozilla 1.4.3
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3) Gecko/20041005

Maybe there's some Appendix C violation that's too subtle for me or the
validator to catch, yet too obvious for you to specify.

Comment 10

[Anne (:annevk)]

The W3C validator thinks this is XHTML, which it is not because the MIME type is
text/html and therefore the file gets treated as if it was HTML per the HTML WG.

Also note that the validator only checks the syntax, it does not check
everything from the specification.

Comment 11

[Boris Zbarsky [:bzbarsky]]

> The W3C validator does not complain about the page:

This is a known bug in the validator.

The Appendix C violation in question is code like:

  <a name="whatever" />

This violates http://www.w3.org/TR/xhtml1/#C_3

Comment 12

[Dave Gross]

Thanks for the clarification.  For future readers of this exchange: I've changed
the source of those test cases under my control (the ones at sniggle.net) so
they no longer use the <a ... /> form, and so while they still validate they no
longer exhibit the bug.