13 years ago
13 years ago


(Reporter: frans.englich, Unassigned)



User-Agent:       Mozilla/5.0 (compatible; Konqueror/3.4; Linux; en_US) KHTML/3.4.89 (like Gecko)
Build Identifier: 

It would be great if all pages served from a Bugzilla setup was valid XHTML. Currently, it seems to be somekind of tag soup.

What I more specifically suggests, is that each served page contains:

* An XML prolog: <?xml encoding="UTF-8" version="1.0"?>
* A DOCTYPE declaration. For example:
<!DOCTYPE html 
     PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
* A correct element document:
<html xmlns="" xml:lang="en" lang="en">

The purpose of doing this is as follows.

* How Bugzilla appears to your users is more clear, since it's well defined how web browsers should render it. Currently, they try to cope the best they can, interpret it the way /they/ think it's supposed to be done.
* It renders faster
* As one of the largest internet citizen, you'll improve the environment by promoting standards instead of breaking them
* Again, a clearer product since encoding and locale is specified(and not only on the HTML level)
* Better style/content separation, and better styling possibilities

This will make a better Bugzilla, especially for things like accessibility software and small devices.

I suggest XHTML in front of HTML, because the former is the future while the latter will fade away over time. XHTML also gives you the possibility to in the future serve compound documents, where meta data in RDF is embedded in the XHTML, for example. XHTML also means one can programatically process the documents with for example XSL-T -- that's how I discovered this bug.

I also think you should make document validity part of your regression testing, since how Bugzilla's appears outwards is of high importance.


Reproducible: Always
*** Bug 336018 has been marked as a duplicate of this bug. ***
1) I'm not ready to break IE6 users yet.  Maybe after IE7 is out of beta for a couple years. (IE6 doesn't support XHTML, and faking the mime-type breaks everything else)

2) None of the browsers I'm aware of do incremental rendering of XHTML yet (they have to download and parse the entire document before they display anything).  This would make the user thing there's nothing at all happening on pages that take a long time to generate (such as buglist.cgi).  The incremental rendering of HTML is a big win here since the page can be sent to the user and actually drawn as it's built.
Closed: 13 years ago
Resolution: --- → WONTFIX
Actually, XHTML will be used in my UI design approach. It will work with IE6 (and IE5.5 and IE4.0 and IE3.0 and IE 2.0 ;)) and it will solve the problem with incremental layout thanks to DHTML/AJAX.

I'm ok with this bug staying as WONTFIX.
You need to log in before you can comment on or make changes to this bug.