Closed Bug 101653 Opened 23 years ago Closed 23 years ago

style not rendered for XML docs

Categories

(Tech Evangelism Graveyard :: English US, defect)

x86
Windows 98
defect
Not set
minor

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 88614

People

(Reporter: powers.jason, Assigned: bc)

References

()

Details

this w3.org xml page doesn't render styles in the browser. It displays as plain
text. Is their document wrong, or the browser?
Probably dup of bug 88614 or bug 92706.
We are doing the right thing: the XML served does not contain any stylesheets.
This could be one more instance of bug 88614, i.e. the W3C server is confused
because we send text/xml in the accept headers.

However, this could be intended as well in this case. Jason, where did you find
this link? The link specifically points to an XML document, so I would expect to
receive XML (unlike in bug 88614 where the URL points to an official spec
without the XML suffix).
Ok, I got an email from Jason. If you go to http://www.w3.org/TR/REC-xml which
is the XML spec, and click to see any of the previous versions of the spec you
get the raw XML. Over to Evangelism.
Assignee: heikki → bclary
Status: UNCONFIRMED → NEW
Component: XML → English: US
Ever confirmed: true
Product: Browser → Tech Evangelism
QA Contact: petersen → zach
Version: other → unspecified
http://www.w3.org/TR/REC-xml

has the current xml spec, and a link to the old one.

BOTH the old one and the "XML" link after "Current version:" come up as plain text.

If it's their server, then there's no problem with Mozilla. But if it isn't...

Maybe there's a good torture test somewhere for xml with stylesheets? I was
trying to figure out what Mozilla will support - I need to know when this
browser's ready for my company to install, and I think they're pushing towards
going with the w3c specs.
Mozilla/Netscape 6 have excellent XML+CSS support, and just about usable XSLT
support if you know what to avoid. But this klind of discussion belongs to the
newsgroups, I'll post a reply to the newsgroup netscape.public.mozilla.xml, the
best news server for that feed would be news.mozilla.org.
perl head http://www.w3.org/TR/2000/WD-xml-2e-20000814

200 OK
Cache-Control: max-age=31536000
Connection: close
Date: Wed, 26 Sep 2001 18:42:16 GMT
Accept-Ranges: bytes
Server: Apache/1.3.6 (Unix) PHP/3.0.11
Vary: negotiate, accept, accept-charset
Content-Length: 201959
Content-Location: WD-xml-2e-20000814.html
Content-Type: text/html; charset=iso-8859-1
ETag: "13c99a-314e7-399873c2;3b2e051b"
Expires: Thu, 26 Sep 2002 18:42:16 GMT
Last-Modified: Mon, 14 Aug 2000 22:33:38 GMT
Client-Date: Wed, 26 Sep 2001 18:41:40 GMT
Client-Peer: 18.7.14.127:80
P3P: policyref="http://www.w3.org/2001/05/P3P/p3p.xml"
TCN: choice

Looks like to me that their invariant URI scheme defaults to text/html and they
do not properly report XML documents without an .xml extension as XML.

Will someone who knows who to contact, please take this an all W3 evangelism bugs?
Bob, this site does agent sniffing and send different pages
depending on which user-agent is accessing.

Try this clever URL sniffer with different browser:

http://webtools.mozilla.org/web-sniffer/

With the latest Netscape branch build (0.9.4), I get the following
headers back:

HTTP/1.1 200 OK
Date: Wed, 26 Sep 2001 19:00:44 GMT
Server: Apache/1.3.6 (Unix) PHP/3.0.11
Content-Location: WD-xml-2e-20000814.xml
Vary: negotiate, accept, accept-charset
TCN: choice
P3P: policyref="http://www.w3.org/2001/05/P3P/p3p.xml"
Cache-Control: max-age=31536000
Expires: Thu, 26 Sep 2002 19:00:44 GMT
Last-Modified: Mon, 14 Aug 2000 22:17:39 GMT
ETag: "640398-3032d-39987003;3b2e051b"
Accept-Ranges: bytes
Content-Length: 197421
Connection: close
Content-Type: text/xml; qs=0.9

But if access this page with Comm 4.x, I get the kind of headers
you quote above.
Kat. Thanks. Nifty tool indeed. 

Looking at the source, I don't see anything related to specifying CSS or XSLT
anywhere or I am missing the point here too?

It is interesting to note that IE5.5SP2/Win2k croaks on
http://www.w3.org/TR/1998/REC-xml-19980210.xml.
OK I sent all this (including the problem pages and a link to this page with
your responses) to the WC3's Webpage Technical Issue contact. You-all have been
very helpful, and I figured if I sent it in to w3c for you, you could close this
bug and get back to business.

I'll watch that newsgroup for torture tests, and if nothing interesting comes
up, I'll just build one myself. As of .94, Mozilla is stable enough for my users
to upgrade from Netscape 4, and we need it (and xml-css) if we're gonna exploit
some of the new things we're looking at doing with our database. If I can
successfully update the users at my .org (http://ecog.dfci.harvard.edu) to
Mozilla (or we may wait until Netscape 6.2 or .3), the Dana Farber Cancer
Institute won't be far behind. 

I've been testing this browser since .6, and it's great to watch it grow. I like
the Multizilla plugin, maybe it should be incorporated?
Thanks, Jason. I think Heikki was right in his analysis. W3C
sends text/xml documents in this case to Mozilla/NS6.x but 
forgets to include a stylesheet or some other styling
info.  Comm 4.x and IE5, etc. are served HTML pages with a 
proper stylesheet URL included.
Additional Info.

As I commented in Bug 88614, this is due to Mozilla side bug.
We are sending an accept header in which text/html is ranked
lower than text/xml. This is why we are served XML pages.
If we want HTML pages, then we need to fix Bug 88614. A workaround
was posted to Bug 88614.
No, no, no!

Mozilla is correct. W3C is wrong.

Our accept header is correct: we prefer XML over HTML. The W3C server has at
least two problems: 1) It serves us XML without stylesheet, which makes no sense
and 2) according to W3C the HTML version of the spec is the normative version
and therefore they should ALWAYS serve the HTML version of a spec.

*** This bug has been marked as a duplicate of 88614 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
yes
Status: RESOLVED → VERIFIED
I am re-opening this bug because the pages mentioned in this
bug are still broken and Bug 88614 has turned into a related  
but different issue at the moment. 
I think we need to continue evangelizing work on the pages reported here.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
No, this is the same issue: the server is reacting wrongly to our Accept-header.
There does not need to be an open bug for every W3C page out there that reacts
wrongly...

*** This bug has been marked as a duplicate of 88614 ***
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → DUPLICATE
verif
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.