I feel that bugzilla should output valid html in all it's pages. This shouldn't be too hard to do and would make it easier for nonstandard devices and browsers to access the system. I would be willing to work on this, but I would not be able to do the whole thing (not knowing that much about the system) and would need help from others.

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

possible 2.12

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

As best I can tell, the patch has been applied. Closing out.

Reopening. http://validator.w3.org/check?uri= http%3A%2F%2Fbugzilla.mozilla.org shows that just the front page doesn't use valid html and that isn't even looking at the cgi scripts. This might not be a 2.x bug at all, but a requirement for the output modules of 3.0.

You know what? I was on complete crack. Do *NOT* know what I was thinking here. My apologies. Yeah, I think we'll definitely want to make this a 3.0 thing. If somebody wants to go retrofit all the existing CGI output on 2.x, that would be fine, but it can wait for 2.14.

BTW: What about changing the subject to "Make BugZilla use valid XHTML" ? AFAIK all current HTML 3.x/4.x-compillant browsers won't have problems with XHTML, right ?

Some examples of Invalid HTML - <nobr>, align=left, no doctype in header. I recommend that we fix all these HTML errors by 2.14. What do you think? That includes all the .cgi files. After that, checkins should be scanned for proper html before acceptance. This is just my opinion, and I know you aren't allowed to have opinions in Bugzilla but what they hey ;-).

Oh yeah - there are problems with the header and footer of the pages to that are called with PutHeader() and PutFooter()

2.14 is going to be a security release... being that invalid HTML isn't really a security issue I think the soonest it would be is 2.16. The real quesition is, what version of HTML should it use? 3.2? 4.01? strict or transitional?

> The real quesition is, what version of HTML should it use? 3.2? 4.01? > strict or transitional? What about: HTML 4.01 in a layout that Lynx users can still work with BugZilla... Or: Choosing output format based on "User-Agent" header and users preferences ? And: What about adding some "HEAD" META tags like GENERATOR (=BugZilla version), KEYWORDS (... which one ? Dumping the "KEYWORDS" field from BugZilla's database ?) ?

I was thinking more on the lines of 4.01 transitional. Anyone that doesn't have a 4.01 transitional browser should be spanked. Possibly, even 3.2 could be used unless 3.2 would stop us from using some of the html in it currently.

Actually, make that 4.01 transitional, since thats what I did on queryhelp.cgi. BTW: I currently experienced firsthand the living hell that is involved in retrofitting a page to be compatible (my queryhelp.cgi), but I also know it is something that can be done in probably 8 hours for query.cgi and much less on most of the other pages (probably even shorter if you are not talking in irc like I was).

> The real quesition is, what version of HTML should it use? > 3.2? 4.01? strict or transitional? Are you joking? There is absolutely no point in using HTML 3.2 any more. Compatibility with older Browsers may be even better by using HTML 4. Read http://mirror.subotnik.net/jkorpela/html/32-40-incompat.html for more information about that topic! XHTML 1.0 is W3C's current recommendation. Its mset of elements and attributes is mostly identical to HTML 4.01 with some slightly stricter syntax for closing elements, to make it valid XML. That is why XHTML is easier to maintain and validate in automatic page generation. Incompatibilities to older Browsers - none! So why not use it? The question 'strict or transitional' may be answered as usual: Use structural MarkUp, the rest is easy! Use transitional attributes only if enhancement presentation in legacy-browsers is really neccesary! Never use deprecated elements! They are unneccesary in any case and harmfull in most.

XHTML -> 3.0 is definately a possibility because I believe 3.0 will have multiple output forms (at least thats what i gathered before i gave up trying to decipher phrases like transports and form modules from Hixie and Matty). As for XHTML in Bugzilla 2.x, I highly doubt it since that would require a major rewriting and wouldn't be necessary. I reiterate that HTML 4.1 transitional would be the best bet.

HTML 4.01 strict is a possibility though (although would be a lot harder and for what?) What you need to realize is that Bugzilla is hard enough to hack in its current form without having to worry about writing strict html. The markup is mish- mashed within the code. It is far from modularized. Bugzilla 3.0 will be modularized and I see that as a good reason to use highly structural markup. The only real positive aspect I can see of using strict would be the ability to place css within the document (although you might be able to do that with 4.01 transitional - I'm not sure). What's wrong with deprecated elements? If you are doing HTML 4.01 transitional then deprecated elements are allowed. Sometimes deprecated elements are much better than their non-deprecated alternatives. If you disagree with me then I'm right, and if you agree with me, I'm still right, but I would like to hear your opinion if you think I'm wrong so I can prove I'm right. ;-) (Sorry, I'm a little low on patience - going on my 28th hour being awake).

BTW: I'm probably wrong.

moving to real milestones...

> What's wrong with deprecated elements? If you are doing HTML 4.01 transitional > then deprecated elements are allowed. Sorry, I am not a native speaker, but in my understanding calling something "deprecated" means: "Alternatives are not well enough supported yet to forbid this completely at the moment, but if you use this there may be usability issues with current UAs or there will be compatibility issues with future standards. Rather don't use them" Read the specs, use your brain and find out _why_ some elements and attributes are deprecated. If there are further questiones rather ask them at news:comp.infosystems.www.authoring.html ! As far as I understand things, bugzilla is not the adequate place to teach you the basics of modern, standard compliant webdesign. > Sometimes deprecated elements are much better than their non-deprecated > alternatives. LOL! If I try to translate this sentence to my native tounge it becomes something like: "Sometimes bad things are much better than good things". Is that what you mean?

Deprecated elements for 4.01 aren't necessary deprecated for 4.01 transitional or 3.2, which is EXACTLY WHAT I SAID! Please don't reply to my comments if you didn't read them correctly.

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

Attechment 36663 to bug 83492 has some additional suggested changes for this.

Attachment 36663 [details] [diff], even. I have to spell it right for it to link. :-)

I have attached Attachment 44201 [details] [diff] , which contains all the changes neccessary to make enter_bug.cgi output valid XHTML 1.0 Strict markup. I have made a few semantic changes, mostly to stylize some things which previously used <FONT>. I have also of course removed all tags which no longer exist, like <NOBR>. The meat of the changes is in CGI.pl, enter_bug.cgi, defparams.pl, and globals.pl. Also, many of the other files were victims of a global replacement of <TR>, <TD>, <TABLE>, and <OPTION> with their lowercase equivalents. Please to comment.

The more recent attachment adds index.html to the list of valid XHTML 1.0 Strict pages.

Does this patch have a replacement for NOBR, eg &nbsp? The stored queries on the footer should be using non-breaking spaces still I think. Maybe create a function that converts all the spaces in a string into &nbsp and output that.

personally i'm not exactly a fan of xhtml + print "<table border=\"1\"><td><H2>Bug $id has been confirmed by votes.</H2>\n"; shouldn't h2 be lowercase? can you use ' instead of \". and would nayone consider only outputing /> _if_ the browser says it likes xml? my understanding of xhtml is that all tags are lowercase so you missed a bunch of others... +<td ALIGN=right><B><A HREF="describekeywords.cgi">Keywords:</A></B> +<td COLSPAN=7><INPUT NAME="keywords" VALUE="$value" SIZE=60></td> personally... i'd like to know which versions of what browsers currently work w/ bugzilla and then set up a regression testing station to see how many mass changes like this break. (nav1.1n crashes @ home.netscape.com and nav2.02 infinitely reloads there, that's not good...)

The correct replacement for NOBR is white-space: nowrap, but many of the NOBR sections were just wrapping one or two words, which is pretty dumb. Timeless, many of the tags are still upper case because I *only* fixed what is needed to make enter_bug.cgi and index.html valid. When I make enough changes for each page to become valid, then I will post the incremental patches. In the meantime, only those two pages are valid. Regarding quoting, I use the escaped double quote because some of the attribute values may contain apostrophes, and those are currently not escaped out. So, using the single quote will cause problems. Is support for navigator 1.1 a serious requirement? I think we should practice what we preach and output valid code. Both of the pages I have updated to XHTML still work nominally in navigator 4.77. IE 5.5 behaves well and IE 6.0 does almost as well as Mozilla.

The fixed pages work nicely in Konqueror as well.

lynx (2.8.4rel1) as well

serious requirement? *shrug*. i don't like making changes just to support a standard if they're going to break compatibility w/ other programs. again we'd need a testsuite to know what the current status is first...

keep in mind, too, that if you remove the WRAP=HARD from the <textarea> on the enter_bug page that we need to get server-side line-wrapping fixed up first (there's another bug for that somewhere...)

Well, wouldn't it be better if we did display-time wrapping?

yeah, but how do you tell the difference between source code (which shouldn't be wrapped) and actual comments (which should be)?

they said it couldn't be done, but there it is :) Latest patch adds valid markup to query.cgi. I'll appreciate any review offered.

The javascript in query.cgi is included within <!-- --> comment blocks to hide the js from non-script capable browsers. However, it uses --- in some places because that is a milestone setting. Adding dependency on bug 96983 which will move the JS into it's own file.

Actually I believe I moved the javascript to inside a CDATA block, but that doesn't help much either since Mozilla doesn't grok javascript inside CDATA in XHTML.

Yes it does.

What about bug 27403?

I can comment on bug 27403. Currently the only XHTML-compliant mode Mozilla 100% correctly supports is outsourcing the scripts into a library file. <script type="text/javascript" language="JavaScript" src="buglibrary.js" /> is perfectly compliant with XHTML 1.0 Transitional. If you drop the language attribute, it complies with XHTML 1.0 Strict. 27403 is a bug which irritates me a great deal... (If I knew C++, I'd fix it)

Hmmm. How about we split these major, life-changing patches into smaller ones that beginners can tackle easily? This is the case where we could use tracking bugs to better accomodate development (and break less the tree). The problem with this sort of patch here is that bitrot happens quickly on each file so if a quick review/checking isn't done, it's wasted work. Agreed? Should I file a tracking bug and make this one just for query.cgi, or do the reverse?

The problem is that patches to any one page (query.cgi by example) require massive, sweeping changes to CGI.pl, defaults.pl, and all the other generic bits. Is this patch really rotting that much? It wouldn't rot if someone checked it in..... ....Or we shoudl freeze bugzilla development. Any new checking is required to upgrade the involved page to W3C standards.

I agree. These fixes need to go in _SOON_. But they can be split up so we don't have to freeze bugzilla to a halt. So I'm setting some dependencies and I would like to point out that bug 103554 has an up-to-date patch for CGI.pl that solves all known problems with HTML4 compliance on two very important functions there. The problem with sweeping changes is nobody reviews them - i argue that it's best to keep them as small as possible or review will take a lot of time. So please roll up the sleeves and get reviewing so I can perfect it and check it in!

As we templatise, fixing the HTML will get a great deal easier. I suggest the people concerned with this bug concentrate on making sure the pages that are already templates validate. As more pages become templates, they can be checked also. Sound good? Gerv

upgrading severity to blocker, as this is now on our "we will hold the release for this" list for Bugzilla 2.16. I'm gonna take a personal vendetta on this one. A bunch of this stuff is no longer valid because several of the files have had their HTML output moved to template files, but I'll sift through what's here and see what we can use. I'm going to file new bugs and set dependencies for specific files which aren't compliant yet. We'll enforce HTML 4.01 Transitional for Bugzilla 2.16, and the move to XHTML from there should be pretty straightfoward.

index.html is being templatised. So is query.cgi and enter_bug.cgi. So, if I read the attachment names right, booleanchart.html and bug_status.html are all that's left. bug_status.html: changes look fine; but there seem to be missing </td> elements? boolean_chart.html: changes look fine. Assuming that makes it validate :-) zach - is my analysis correct? Gerv

Also note character set encoding issues and META tag usage from bug 33856.

The W3C merely makes recommendations. The International Organization for Standardization actually makes standards. Clearly Bugzilla should use ISO-HTML (ISO/IEC 15445) <http://purl.org/NET/ISO+IEC.15445/15445.html>

According to the preface to that document, it's equivalent to HTML 4.01 Strict, with clarifications. That's too big of a jump for us to make right now, so we're most definitely not going to do that for 2.16. Our stated goal for 2.16 was HTML 4.01 Transitional. Out of curiosity, has the ISO standardized anything based on XHTML yet?

ISO-HTML is too strict for Bugzilla purposes at this time. We are using the HTML 4.01 Transitional document type, which ISO-HTML does not provide an equivalent for. As for your claim as the W3C not creating standards, that is untrue. My employer makes me abide by rules that are called "Employee Guidelines" not "Employee Policy" -- a name alone does not a policy make. The same is said about standards. And besides, this bug clamors for valid HTML. It says nothing about what version of HTML ;-) As long as we conform to a DTD, which for our purposes is the W3C HTML 4.01 Transitional DTD, we can resolve this bug. Though I will go ahead and change the summary to reflect we want it to use 4.01 Transitional.

> Out of curiosity, has the ISO standardized anything based on XHTML yet? Not that I'm aware of

Removing review keyword - this patch isn't suitable for review due to all the templatisation stuff which is going on. This is a 2.16 release requirement, but we'll have to assess where we are when the templatisation smoke clears. I assume, also, that we are aiming for this in all user-facing pages, like the templatisation? Is that right? Gerv

yes.

Yikes. What Gerv and Dave say, plus this should be a tracking bug for smaller logical sets of changes (f.e. individual templates or the set of templates for a given script), so file new bugs and make them block this one when redoing this work post-templatization.

The new nice developer guide, section "Web Technologies" at http://www.mozilla.org/projects/bugzilla/developerguide.html says HTML should be both HTML 4.01 Transitional and XHTML 1.0. In practice, this seems to be pretty impossible, see the thread at http://lists.w3.org/Archives/Public/www-validator/2002Feb/0149.html for more. So IMHO the developer guide needs to be more exact, unless there is a way to be valid HTML 4.01 and XHTML 1.0. What's it going to be?

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

That bug came with a patch, attachment 72946 [details] [diff] [review], against the saved source from the looks of it.

I believe we should be XHTML. This probably just involves a doctype change.

If you guys decide to go with XHTML we would still have to change the HTML in the cgi's to make it XHTM.

We are already converting to XHTML is parallel to templatisation.

Just a friendly reminder -- switching to any XHTML doctype will turn on standards compliant parsing/layout by Mozilla. Is our code ready for that yet?

in that case, we need to change all the doctypes to say so, and probably change the summary on this bug.

OK, after a big discussion in IRC and a quick review of the XHTML 1.0 spec on w3c, the decision is that we DO NOT want XHTML yet because it's going to be too much work to convert our existing code to validate, and will break too many of the older browsers (and some newer ones, like Mozilla), even if we follow the backward compatibility guidelines. As pointed out by others, declaring an XHTML1 doctype will tell Mozilla to render in standards-compliant mode. This will likely break most of our existing pages in Mozilla, let alone encouraging people to use XHTML-specific stuff, which older browsers won't support. So we want everything to be HTML 4.01 Transitional for now. (And we might switch to Strict at some point, but we probably won't do XHTML for a long time yet)

Changing to XHTML is *not* just a DOCTYPE change. XHTML and valid HTML are syntactically incompatible. XHTML 1.1, _if_ you follow the backwards-compatability guidelines, is somewhat compatible with HTML *tag soup*. However, there is no advantage to using XHTML in this case, and there are plenty of disadvantages: 1. It's unclear that it's correct to send XHTML and text/html 2. It's not clear how to validate it (as HTML or XHTML) 3. You have to add namespaces 4. Documents that are handled "correctly" as tag soup by older browsers will be handled correctly as XHTML in modern browsers (when sent as text/xml), which may include reporting errors (for example, if you have an invalid XHTML document, it'll render "fine" in most browsers but not when treated as XHTML) 5. People are encouraged to start adding XHTML-only features to the documents, e.g. MathML, but since they are being sent as text/html they are being treated as tag soup (HTML) and thus those new features will not have any effect 6. CSS rules are different when applied to XHTML rather than HTML, so you get rendering differences in different browsers (specifically, backgrounds do not back-propagate from the <body> element to the <html> element in XHTML) In conclusion, there is no reason for Bugzilla to use XHTML. Don't jump on the bandwagon simply because it looks pretty.

I remind everyone that several months ago a patch was posted that convereted the bulk of Bugzilla to valid XHTML 1.0 Strict. It wasn't all that much work. In the intervening time, I've observed that an effort is underway to convert Bugzilla to an entirely new template system. This seems to be a great effort and is taking a lot of time. If so much work can be put toward templates, I don't see why the smaller effort of moving to XHTML 1.0 Strict can't be done too. Browsers that choke on it can go to hell. The standard exists for a reason.

bugzilla is supposed to be a usable bug tracking system. it's purpose in life is not to serve w3. If you make bugzilla into an ideal serving application that doesn't work in any available browser (or that doesn't work in most browsers [as measured by distinct user agents]) then you are making it undeployable.

And the benefit of us spending so much more time on the templating system is that each Bugzilla install's admin can choose which doctype they want. You are free to re-write your templates as XHTML compliant, if you so wish. However, the default templates should be usable by the majority of the population where the software would be deployed. Since HTML is much more widely supported, it is a better idea to use HTML than XHTML.

> I don't see why the smaller effort of moving to XHTML 1.0 Strict can't be done > too. See my last comment. There is no point. HTML 4.01 is no less standard than is any variant of XHTML. > Browsers that choke on it can go to hell. The standard exists for a reason. That would be over 99% of the browser market by most estimates. That's a lot of lost customers for zero gain.

99% of browsers do not choke on XHTML written to the standard's HTML Compatibility Guidelines (http://www.w3.org/TR/xhtml1/#guidelines). The only significant problem I foresee is a few obsolete browsers rejecting checked="checked" and selected="selected" attributes, which would makes editing queries troublesome. The <?xml version="1.0"?> PI isn't a significant problem. HotJava and Netscape 4.01 and below display it as text, but since the header is optional, we needn't include it in our templates. The objections in item #70 seem pretty weak to me. 1. The XHTML 1.0 standard explicitly says "XHTML Documents which follow the guidelines set forth in Appendix C, 'HTML Compatibility Guidelines' may be labeled with the Internet Media Type 'text/html', as they are compatible with most HTML browsers." -- http://www.w3.org/TR/xhtml1/#media 2. XHTML is best validated as XHTML, of course. Validation as tag soup is harmless, though. 3. We have to add xmlns="http://www.w3.org/1999/xhtml" to the <html> tag. Big deal. 4. Modern browsers pointing out errors in Bugzilla markup is an advantage, not a disadvantage. We want our templates to be error-free. 5. Yeah, a thoughtless person might use MathML if Bugzilla serves XHTML. And the same person might use <marquee> if Bugzilla serves tag soup. Neither would validate, and they would soon learn the error of using unsupported markup. 6. If background images are important to someone, they can use redundant CSS html: descriptors and <body> attributes for background images to avoid a little border around the page. That minor issue doesn't even affect this site, since we don't use background images.

And what are the advantages?

The fix for this bug would be nice to have, but its impact is minimal. It certainly doesn't deserve to block 2.16. Leaving in the milestone because bbaetz says it should fall out of templatization, but reducing severity in accordance with the actual impact of the bug.

I said that the goal was that it came out of templatisation. Just before we RC, we should run a few pages against the w3c validator, and then decide if the remaining problems are small enough to want to fix.

OK.... there are two remaining issues that I can find. One is the use of <nobr> in several places. These ought to be nuked in favor of s/\s/&nbsp;/g on anything printed between them for backward compatibility. (If we didn't care about backward compatibility, it can be accomplished with css, too). The other is the use of the WRAP attribute on <textarea> blocks. Removing this is blocked on bug 11901, so adding the appropriate dependency. Bug 11901 is not going to happen before 2.16 releases, which unfortunately means we will not acheive complete HTML 4.01 Transitional compliance for Bugzilla 2.16, however, we have come pretty damn close. If someone can file a new bug, set it to block this one, and post a patch for the <nobr> issue (in several files) we can try to get that in, but I won't hold the release for it.

I attached patches to bug 137669 to remove the two remaining <nobr> tags.

What about nuking the remaining instances of deprecated type modifications: font, u, and strike? We could use style for these. Old browsers would ignore the style and not lose functionality. In real life the font-size, color, and font-decoration directives are widely supported.

Here's what gmuck, http://gmuck.sourceforge.net/ found when ran against the files in the templates dir in HTML mode. There are pretty many messages also when running against *.cgi...

most of the "deprecated" or "minimized" stuff I'm not too worried about... that's the reason we're using "Transitional" instead of "Strict". On the other hand, all those unterminated entities we definitely need to fix. (&'s that should be &amp; mostly). The trailing /'s should go, too, as was discussed at length earlier in this bug.

Okay, hope I didn't miss anything. I ignored most deprecations, and guessed about other changes: - Added a name attribute to two input tags, made up the names - Changed the minimized attributes to use foo="foo" style - Changed an instance of application/x-javascript to text/javascript despite deprecation - Tried escaping double quotes; don't know if that's legal in TT - Ignored XUL changes

> + [% " checked=\"checked\"" IF g.checked %] />[% g.description %]<br> Here's one more /> that gmuck didn't catch, so " />" should be ">". The deprecation warnings can be turned off in gmuck with --nodeprecated (which as Dave mentioned, should have been set since Bugzilla is 4.01 Transitional).

Comment on attachment 79577 [details] [diff] [review] gmuck fixes r=jwb. All changes look sane to me. Are we certain that all target browsers correctly handle foo="foo" attributes with this DOCTYPE?

> Are we certain that all target browsers > correctly handle foo="foo" attributes with this DOCTYPE? Either they handle them or they ignore them. I don't think that 'older' browsers care about doctypes. But some testing with older browsers wouldn't be bad, of course. NN4.7 handles <dl compact="compact"> 'correct'. NN3.03 handles <dl compact="compact"> 'correct'.

The deprecation stuff will likely be removed in any CSS-ization of the templates. But that's really a new feature, not a bug, and certainly not this bug. =)

Templates moved around and broke my patch. Pretty much the same as above patch. Again, probably missed a few, but can we get this in, and then re-evaluate with gmuck?

Comment on attachment 81492 [details] [diff] [review] updated fixes r=justdave except it needs a patch refresh. there's conflicts in the following files when I apply this currently: list/edit-multiple.html.tmpl search/search.html.tmpl bug/dependency-graph.html.tmpl get those three files to apply cleanly and you can inherit the r=

Comment on attachment 81492 [details] [diff] [review] updated fixes >Index: attachment/edit.html.tmpl >- theContent = theContent.replace( /^<html><head\/><body><pre>/i , "" ); >+ theContent = theContent.replace( /^<html><head><\/head><body><pre>/i , "" ); This shouldn't change since it represents the exact text the XMLSerializer in Mozilla generates. It is not text generated by Bugzilla itself. >Index: list/edit-multiple.html.tmpl >- document.write(' <input type="button" value="Uncheck All" onclick="SetCheckboxes(false);">'); >- document.write(' <input type="button" value="Check All" onclick="SetCheckboxes(true);">'); >+ document.write(' <input name="uncheck_all" type="button" value="Uncheck All" onclick="SetCheckboxes(false);">'); >+ document.write(' <input name="check_all" type="button" value="Check All" onclick="SetCheckboxes(true);">'); Nit: most form fields in Bugzilla put the type attribute before the name attribute. Out of curiosity, why are these necessary? >Index: search/search.html.tmpl >- extra = " onLoad=\"selectProduct(document.forms['queryform']);\"" >+ extra = " onload=\"selectProduct(document.forms['queryform']);\"" Hunh? >Index: bug/votes/list-for-bug.html.tmpl >- h2 = "Bug <a href='show_bug.cgi?id=$bug_id'>$bug_id</a>" >+ h2 = "Bug <a href="show_bug.cgi?id=$bug_id">$bug_id</a>" These need escaping: \"

>>- extra = " onLoad=\"selectProduct(document.forms['queryform']);\"" >>+ extra = " onload=\"selectProduct(document.forms['queryform']);\"" > >Hunh? Ok, I see it now (after Dave pointed it out to me on IRC). Never mind. :-)

> Out of curiosity, why are these necessary? Here's the original gmuck report, suggesting they are required: ./default/buglist/change-form.tmpl:30:20: [E] <input> missing required attribute: "name" ./default/buglist/change-form.tmpl:31:20: [E] <input> missing required attribute: "name" - Applies cleanly - The suggested changes have been done. - The change to search/search.html.tmpl looks like it already got done, so that file's dropping out of this patch. - Found another &apos; conversion, so did that too.

Comment on attachment 84029 [details] [diff] [review] unrotted Everything looks good except line 366 of the patch, where "</A>" stays that way instead of being converted to "</a>" (as the previous patch did). r=myk with that fix (and please post an updated patch in this bug).

Reassigning bug to patch author.

Checking in index.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/index.html.tmpl,v <-- index.html.tmpl new revision: 1.5; previous revision: 1.4 done Checking in account/exists.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/account/exists.html.tmpl,v <-- exists.html.tmpl new revision: 1.5; previous revision: 1.4 done Checking in account/email/confirm.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/account/email/confirm.html.tmpl,v <-- confirm.html.tmpl new revision: 1.5; previous revision: 1.4 done Checking in account/password/set-forgotten-password.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/account/password/set-forgotten-password.html.tmpl,v <-- set-forgotten-password.html.tmpl new revision: 1.4; previous revision: 1.3 done Checking in account/prefs/account.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/account/prefs/account.html.tmpl,v <-- account.html.tmpl new revision: 1.2; previous revision: 1.1 done Checking in account/prefs/email.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/account/prefs/email.html.tmpl,v <-- email.html.tmpl new revision: 1.2; previous revision: 1.1 done Checking in account/prefs/footer.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/account/prefs/footer.html.tmpl,v <-- footer.html.tmpl new revision: 1.2; previous revision: 1.1 done Checking in account/prefs/permissions.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/account/prefs/permissions.html.tmpl,v <-- permissions.html.tmpl new revision: 1.2; previous revision: 1.1 done Checking in account/prefs/prefs.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/account/prefs/prefs.html.tmpl,v <-- prefs.html.tmpl new revision: 1.5; previous revision: 1.4 done Checking in attachment/create.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/attachment/create.html.tmpl,v <-- create.html.tmpl new revision: 1.6; previous revision: 1.5 done Checking in attachment/created.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/attachment/created.html.tmpl,v <-- created.html.tmpl new revision: 1.5; previous revision: 1.4 done Checking in attachment/edit.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/attachment/edit.html.tmpl,v <-- edit.html.tmpl new revision: 1.5; previous revision: 1.4 done Checking in attachment/show-multiple.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/attachment/show-multiple.html.tmpl,v <-- show-multiple.html.tmpl new revision: 1.4; previous revision: 1.3 done Checking in attachment/updated.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/attachment/updated.html.tmpl,v <-- updated.html.tmpl new revision: 1.5; previous revision: 1.4 done Checking in bug/choose-xml.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/choose-xml.html.tmpl,v <-- choose-xml.html.tmpl new revision: 1.5; previous revision: 1.4 done Checking in bug/dependency-graph.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/dependency-graph.html.tmpl,v <-- dependency-graph.html.tmpl new revision: 1.6; previous revision: 1.5 done Checking in bug/edit.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/edit.html.tmpl,v <-- edit.html.tmpl new revision: 1.8; previous revision: 1.7 done Checking in bug/show-multiple.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/show-multiple.html.tmpl,v <-- show-multiple.html.tmpl new revision: 1.4; previous revision: 1.3 done Checking in bug/activity/show.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/activity/show.html.tmpl,v <-- show.html.tmpl new revision: 1.4; previous revision: 1.3 done Checking in bug/create/create.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/create/create.html.tmpl,v <-- create.html.tmpl new revision: 1.7; previous revision: 1.6 done Checking in bug/process/verify-new-product.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/process/verify-new-product.html.tmpl,v <-- verify-new-product.html.tmpl new revision: 1.4; previous revision: 1.3 done Checking in bug/votes/list-for-bug.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/votes/list-for-bug.html.tmpl,v <-- list-for-bug.html.tmpl new revision: 1.5; previous revision: 1.4 done Checking in bug/votes/list-for-user.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/votes/list-for-user.html.tmpl,v <-- list-for-user.html.tmpl new revision: 1.7; previous revision: 1.6 done Checking in global/header.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/header.html.tmpl,v <-- header.html.tmpl new revision: 1.6; previous revision: 1.5 done Checking in list/edit-multiple.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/list/edit-multiple.html.tmpl,v <-- edit-multiple.html.tmpl new revision: 1.5; previous revision: 1.4 done Checking in list/list-simple.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/list/list-simple.html.tmpl,v <-- list-simple.html.tmpl new revision: 1.5; previous revision: 1.4 done Checking in list/list.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/list/list.html.tmpl,v <-- list.html.tmpl new revision: 1.4; previous revision: 1.3 done Checking in list/quips.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/list/quips.html.tmpl,v <-- quips.html.tmpl new revision: 1.5; previous revision: 1.4 done Checking in reports/components.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/reports/components.html.tmpl,v <-- components.html.tmpl new revision: 1.5; previous revision: 1.4 done Checking in reports/duplicates-table.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/reports/duplicates-table.html.tmpl,v <-- duplicates-table.html.tmpl new revision: 1.2; previous revision: 1.1 done Checking in reports/duplicates.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/reports/duplicates.html.tmpl,v <-- duplicates.html.tmpl new revision: 1.5; previous revision: 1.4 done Checking in search/form.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/search/form.html.tmpl,v <-- form.html.tmpl new revision: 1.3; previous revision: 1.2 done Checking in search/knob.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/search/knob.html.tmpl,v <-- knob.html.tmpl new revision: 1.3; previous revision: 1.2 done

Oops, I just realized I didn't check this one in on the branch. I'll get to that tomorrow if no one beats me to it.

Checking in index.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/index.html.tmpl,v <-- index.html.tmpl new revision: 1.4.2.1; previous revision: 1.4 done Checking in account/exists.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/account/exists.html.tmpl,v <-- exists.html.tmpl new revision: 1.4.2.1; previous revision: 1.4 done Checking in account/email/confirm.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/account/email/confirm.html.tmpl,v <-- confirm.html.tmpl new revision: 1.4.2.1; previous revision: 1.4 done Checking in account/password/set-forgotten-password.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/account/password/set-forgotten-password.html.tmpl,v <-- set-forgotten-password.html.tmpl new revision: 1.3.2.1; previous revision: 1.3 done Checking in account/prefs/account.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/account/prefs/account.html.tmpl,v <-- account.html.tmpl new revision: 1.1.2.1; previous revision: 1.1 done Checking in account/prefs/email.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/account/prefs/email.html.tmpl,v <-- email.html.tmpl new revision: 1.1.2.1; previous revision: 1.1 done Checking in account/prefs/footer.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/account/prefs/footer.html.tmpl,v <-- footer.html.tmpl new revision: 1.1.2.1; previous revision: 1.1 done Checking in account/prefs/permissions.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/account/prefs/permissions.html.tmpl,v <-- permissions.html.tmpl new revision: 1.1.2.1; previous revision: 1.1 done Checking in account/prefs/prefs.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/account/prefs/prefs.html.tmpl,v <-- prefs.html.tmpl new revision: 1.4.2.1; previous revision: 1.4 done Checking in attachment/create.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/attachment/create.html.tmpl,v <-- create.html.tmpl new revision: 1.5.2.1; previous revision: 1.5 done Checking in attachment/created.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/attachment/created.html.tmpl,v <-- created.html.tmpl new revision: 1.4.2.1; previous revision: 1.4 done Checking in attachment/edit.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/attachment/edit.html.tmpl,v <-- edit.html.tmpl new revision: 1.4.2.1; previous revision: 1.4 done Checking in attachment/show-multiple.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/attachment/show-multiple.html.tmpl,v <-- show-multiple.html.tmpl new revision: 1.3.2.1; previous revision: 1.3 done Checking in attachment/updated.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/attachment/updated.html.tmpl,v <-- updated.html.tmpl new revision: 1.4.2.1; previous revision: 1.4 done Checking in bug/choose-xml.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/choose-xml.html.tmpl,v <-- choose-xml.html.tmpl new revision: 1.4.2.1; previous revision: 1.4 done Checking in bug/dependency-graph.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/dependency-graph.html.tmpl,v <-- dependency-graph.html.tmpl new revision: 1.5.2.1; previous revision: 1.5 done Checking in bug/edit.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/edit.html.tmpl,v <-- edit.html.tmpl new revision: 1.7.2.1; previous revision: 1.7 done Checking in bug/show-multiple.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/show-multiple.html.tmpl,v <-- show-multiple.html.tmpl new revision: 1.3.2.1; previous revision: 1.3 done Checking in bug/activity/show.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/activity/show.html.tmpl,v <-- show.html.tmpl new revision: 1.3.2.1; previous revision: 1.3 done Checking in bug/create/create.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/create/create.html.tmpl,v <-- create.html.tmpl new revision: 1.6.2.1; previous revision: 1.6 done Checking in bug/process/verify-new-product.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/process/verify-new-product.html.tmpl,v <-- verify-new-product.html.tmpl new revision: 1.3.2.1; previous revision: 1.3 done Checking in bug/votes/list-for-bug.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/votes/list-for-bug.html.tmpl,v <-- list-for-bug.html.tmpl new revision: 1.4.2.1; previous revision: 1.4 done Checking in bug/votes/list-for-user.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/votes/list-for-user.html.tmpl,v <-- list-for-user.html.tmpl new revision: 1.6.2.1; previous revision: 1.6 done Checking in global/header.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/header.html.tmpl,v <-- header.html.tmpl new revision: 1.5.2.1; previous revision: 1.5 done Checking in list/edit-multiple.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/list/edit-multiple.html.tmpl,v <-- edit-multiple.html.tmpl new revision: 1.4.2.1; previous revision: 1.4 done Checking in list/list-simple.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/list/list-simple.html.tmpl,v <-- list-simple.html.tmpl new revision: 1.4.2.1; previous revision: 1.4 done Checking in list/list.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/list/list.html.tmpl,v <-- list.html.tmpl new revision: 1.3.2.1; previous revision: 1.3 done Checking in list/quips.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/list/quips.html.tmpl,v <-- quips.html.tmpl new revision: 1.4.2.1; previous revision: 1.4 done Checking in reports/components.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/reports/components.html.tmpl,v <-- components.html.tmpl new revision: 1.4.2.1; previous revision: 1.4 done Checking in reports/duplicates-table.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/reports/duplicates-table.html.tmpl,v <-- duplicates-table.html.tmpl new revision: 1.1.2.1; previous revision: 1.1 done Checking in reports/duplicates.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/reports/duplicates.html.tmpl,v <-- duplicates.html.tmpl new revision: 1.4.2.1; previous revision: 1.4 done Checking in search/form.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/search/form.html.tmpl,v <-- form.html.tmpl new revision: 1.2.2.1; previous revision: 1.2 done Checking in search/knob.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/search/knob.html.tmpl,v <-- knob.html.tmpl new revision: 1.2.2.1; previous revision: 1.2 done

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

I'm sorry, but this bug does not seem to be fixed in Bugzilla 2.17. Here is the output from http://validator.w3.org/check?uri=http%3A%2F%2Fbugzilla.mozilla.org% 2Fshow_bug.cgi%3Fid%3D47251&charset=%28detect+automatically%29&doctype=Inline: "URI: http://bugzilla.mozilla.org/show_bug.cgi?id=47251 Server: Apache/1.3.26 (Unix) mod_throttle/3.1.2 Detected Character Encoding: unknown Select Character Encoding: [...] Current Doctype: HTML 4.01 Transitional [...] Options: [none] Warnings Warning: No Character Encoding detected! To assure correct validation, processing, and display, it is important that the character encoding is properly labeled. Further explanations. Below are the results of attempting to parse this document with an SGML parser. Line 878, column 17: <textarea wrap="hard" name="comment" rows="10" cols="80" ^ Error: there is no attribute "WRAP" for this element (in this HTML version) " The WRAP bug (mentioned in comment 37) is a real problem. Bugzilla depends deeply on it for wrapping comments, and some browsers doesn't support it. This is discussed in Bug 11901. I suggest reopening this bug due to this WRAP problem. I'm not allowed to do that - anyone who is? Commenting on comment 39, it is true that program listings shouldn't be word wrapped. But 1) aren't they best placed in attachments?, and 2) how can you submit these anyway in a comment when your browser hard wraps at 80 chars like most browsers do now due to the wrap=hard attribute?

vrfy fixed.

Okay, that's also a way to keep the bug solved - redefining the bug! :o) (For later readers: At comment 102, timeless just changed the summary from "Make bugzilla use valid HTML 4.01 Transitional" to "Make bugzilla use valid HTML 4.01 Transitional except for WRAP which is covered by some other bug".) Is there a reason not to keep the bug at "Make bugzilla use valid HTML 4.01 Transitional" and reopening it? I don't get it.

timeless was only adorably trying to say that this bug still depends on bug 11901. A bug with dependents should only close when it's dependents are closed. Now, it does bear saying that this bug has already had code checked in to it, so it's a wierd kind of meta-bug with code. I don't know what the policy is, but there are four solutions here: 1. Reopen this bug, since it's not true, and replace the summary. 2. Leave it closed, and open another meta-bug and move all dependents to it. 3. Leave it closed, and don't have a meta-bug for HTML compliance. 4. While we argue about it, fix bug 11901 and make everything a non-issue. I think reopening is the most realistic option, but another reviewer should chip in and confirm this.

breaking dependency on bug 137771 because it has nothing to do with HTML 4.01 Transitional complaince, that one is just a coding style preference. Getting 11901 fixed would be nice... it's LONG overdue. Breaking dependency on it since Timeless modified the summary to exclude it anyway.

New validation errors have cropped up since this was 'resolved': Bug 226229 - Query.cgi HTML Transitional 4.01 validation fails for query.cgi Bug 252856 - HTML charts don't validate And it makes no sense to me to exclude the WRAP attribute from the scope of this tracker, even if it is only because there are things that need to be fixed first. That's exactly what dependencies are for. Bug 11901 - Change Bugzilla comments line-wrapping policy

252826 -> 252856 Darn bug 40896 again! And there was me thinking I'd checked the dependency links!

This bug has checked in code on it that was not backed out. Please open new bugs for new issues. Restoring previously verified/fixed state.

Bug 273847 has been filed to pick up where this one left off.