blockquote elements are not rendered correctly in XHTML documents dleivered as text/html

VERIFIED DUPLICATE of bug 48351

Status

()

Core
HTML: Parser
P3
normal
VERIFIED DUPLICATE of bug 48351
18 years ago
18 years ago

People

(Reporter: Paul Collins, Assigned: vidur (gone))

Tracking

({testcase, xhtml})

Trunk
x86
Linux
testcase, xhtml
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

18 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-trustee i686; en-US; m18)
Gecko/20000729
BuildID:    2000072908

While converting my homepage to use XHTML 1.0 Transitional, I noticed that my
blockquotes were not rendering correctly.  Specifically, the border styles are
applied and rendered, but the content is not, unless enclosed in <p>...</p> tags
(this may apply to other such tags as div; I have not checked this).  Using
<p>...</p> is not an acceptable workaround, as it adds extra spacing (I am not
willing to hack the stylesheet in order to counter that).

I have three (almost) identical pages at the URL above.  One has an extension of
.html (delivered by the server as text/html), one has an extension of .xhtml
(delivered by the server as text/plain) and one has an extension of .xml
(delivered by the server as text/xml).  The latter two pages (.xhtml and .xml)
render correctly.  The first doesn not.  Interestingly, when the .xhtml page is
loaded from the filesystem, it does not render correctly either.  (A guess: when
loading from the filesystem, Mozilla guesses a .xhtml file's Content-Type as
text/html).

Reproducible: Always
Steps to Reproduce:
1. Go to the URL quoted.
2. Observe that the page at the first link does not render correctly, while the
other two do.

Actual Results:  When I clicked on the link to the .html file, I saw that the
contents of the first blockquote were not rendered, but its styles were applied.
 The .xhtml and .xml files rendered as expected.

Expected Results:  Mozilla should have rendered the contents of the first
blockquote in the .html file as it did for the .xhtml and .xml files.

I added styles to the blockquote elements to show that the element is present in
the content model.  The styles do not affect the result of the testcase if removed.
(Reporter)

Comment 1

18 years ago
Sorry for not checking this sooner.  I tried the .html example with
<blockquote><div>...</div></blockquote>, and it also renders correctly.  Thus,
we have a workaround (for new pages, at least), since div does not affect
presentation.  I suspect therefore that this only happens when the content of
the blockquote is PCDATA (I hope this is the correct SGML term, my memory is
fuzzy on this).

Updated

18 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

18 years ago
This bug is DUPL 29135, as are a slew of others.

Comment 3

18 years ago
It also affects all platforms.
(Reporter)

Comment 4

18 years ago
Bug #29135 is a bookmark-creation bug.  What does that have to do with
blockquotes being mis-rendered in XHTML delivered as text/html?  In addition,
29135 is marked as VERIFIED FIXED, while this bug is still manifest in
2000080712 (M17) in Win32.

I accept that this bug is manifest on all platforms, but since I only had Linux
available at the time I filed the bug, I marked it as Linux.

Comment 5

18 years ago
Sorry, that was a typo.  It should have been 29125.
(Reporter)

Comment 6

18 years ago
I examined bug #29125; it does indeed relate to XHTML rendering, but the
problems described there are not those I am experiencing.  I have not
experienced gross XHTML rendering problems; what I am experiencing is a specific
problem in a specific context, as described above.
(Reporter)

Comment 7

18 years ago
I just tried the testcases with build 2000081821 on Linux; Mozilla now ignores
the .xhtml extension and renders it as the MIME type the server provides
suggests: plain text.  The bug is still there.

Updated

18 years ago
Assignee: rickg → vidur

Comment 8

18 years ago
Reassigning to vidur, per XHTML decision.
The bug was that we were rendering XHTML as strict HTML, even if it had a 
transitional DTD. Since we now going to send XHTML down the XML codepath, 
this bug will disappear. Thus, marking DUP of the 'treat XHTML as XML' bug.

*** This bug has been marked as a duplicate of 48351 ***
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Keywords: testcase, xhtml
Resolution: --- → DUPLICATE

Comment 10

18 years ago
verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.