47251 - Make bugzilla use valid HTML 4.01 Transitional (initial attempt)

Status: VERIFIED FIXED

(Bugzilla :: User Interface, defect, P1)

Description

[Zach Lipton [:zach]]

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.

Comment 1

[Zach Lipton [:zach]]

Attachment: Patch to make index.html use valid html

Comment 2

[Zach Lipton [:zach]]

Attachment: Patch to make booleanchart.html use valid html

Comment 3

[Zach Lipton [:zach]]

Attachment: Patch to make bug_status.html use valid html

Comment 4

[Zach Lipton [:zach]]

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

Comment 5

[Chris Yeh]

possible 2.12

Comment 6

[Zach Lipton [:zach]]

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

Comment 7

[Tara Hernandez]

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

Comment 8

[Zach Lipton [:zach]]

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.

Comment 9

[Tara Hernandez]

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.

Comment 10

[Roland Mainz]

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 ?

Comment 11

[Brian 'netdragon' Bober]

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 ;-).

Comment 12

[Brian 'netdragon' Bober]

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

Comment 13

[Jacob Steenhagen]

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?

Comment 14

[Roland Mainz]

> 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
?) ?

Comment 15

[Brian 'netdragon' Bober]

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.

Comment 16

[Brian 'netdragon' Bober]

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).

Comment 17

[Michael Nahrath]

> 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.

Comment 18

[Brian 'netdragon' Bober]

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.

Comment 19

[Brian 'netdragon' Bober]

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).

Comment 20

[Brian 'netdragon' Bober]

BTW: I'm probably wrong.

Comment 21

[Dave Miller [:justdave]]

moving to real milestones...

Comment 22

[Michael Nahrath]

> 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?

Comment 23

[Brian 'netdragon' Bober]

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.

Comment 24

[Dave Miller [:justdave]]

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

Comment 25

[Dave Miller [:justdave]]

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

Comment 26

[Dave Miller [:justdave]]

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

Comment 27

[Jeffrey Baker]

Attachment: Make enter_bug.cgi emit XHTML 1.0 Strict markup

Comment 28

[Jeffrey Baker]

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.

Comment 29

[Jeffrey Baker]

Attachment: Previous patch + make index.html valid

Comment 30

[Jeffrey Baker]

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

Comment 31

[Matthew Tuck [:CodeMachine]]

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.

Comment 32

[timeless]

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...)

Comment 33

[Jeffrey Baker]

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.

Comment 34

[Bernhard Rosenkraenzer]

The fixed pages work nicely in Konqueror as well.

Comment 35

[Bernhard Rosenkraenzer]

lynx (2.8.4rel1) as well

Comment 36

[timeless]

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...

Comment 37

[Dave Miller [:justdave]]

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...)

Comment 38

[Matthew Tuck [:CodeMachine]]

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

Comment 39

[Dave Miller [:justdave]]

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

Comment 40

[Jeffrey Baker]

Attachment: previous changes + make query.cgi emit valid markup

Comment 41

[Jeffrey Baker]

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.

Comment 42

[Christopher Aillon (sabbatical, not receiving bugmail)]

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.

Comment 43

[Jeffrey Baker]

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.

Comment 44

[Hixie (not reading bugmail)]

Yes it does.

Comment 45

[Jeffrey Baker]

What about bug 27403?

Comment 46

[Alex Vincent [:WeirdAl]]

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)

Comment 47

[Christian Reis]

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?

Comment 48

[Jeffrey Baker]

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.

Comment 49

[Christian Reis]

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!

Comment 50

[Gervase Markham [:gerv]]

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

Comment 51

[Dave Miller [:justdave]]

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.

Comment 52

[Gervase Markham [:gerv]]

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

Comment 53

[David D. Kilzer (ddk)]

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

Comment 54

[Russell O'Connor]

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>

Comment 55

[Dave Miller [:justdave]]

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?

Comment 56

[Christopher Aillon (sabbatical, not receiving bugmail)]

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.

Comment 57

[Christopher Aillon (sabbatical, not receiving bugmail)]

> Out of curiosity, has the ISO standardized anything based on XHTML yet?

Not that I'm aware of

Comment 58

[Gervase Markham [:gerv]]

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

Comment 59

[Dave Miller [:justdave]]

yes.

Comment 60

[Myk Melez [:myk] [@mykmelez]]

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.

Comment 61

[Ville Skyttä]

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?

Comment 62

[mental]

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

Comment 63

[mental]

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

Comment 64

[Matthew Tuck [:CodeMachine]]

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

Comment 65

[Chema Celorio]

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

Comment 66

[Matthew Tuck [:CodeMachine]]

We are already converting to XHTML is parallel to templatisation.

Comment 67

[Christopher Aillon (sabbatical, not receiving bugmail)]

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?

Comment 68

[Dave Miller [:justdave]]

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

Comment 69

[Dave Miller [:justdave]]

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)

Comment 70

[Hixie (not reading bugmail)]

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.

Comment 71

[Jeffrey Baker]

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.

Comment 72

[timeless]

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.

Comment 73

[Christopher Aillon (sabbatical, not receiving bugmail)]

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.

Comment 74

[Hixie (not reading bugmail)]

> 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.

Comment 75

[Robin Lionheart]

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.

Comment 76

[Hixie (not reading bugmail)]

And what are the advantages?

Comment 77

[Myk Melez [:myk] [@mykmelez]]

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.

Comment 78

[Bradley Baetz (:bbaetz)]

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.

Comment 79

[Dave Miller [:justdave]]

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.

Comment 80

[Jeffrey Baker]

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

Comment 81

[Jeffrey Baker]

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.

Comment 82

[Ville Skyttä]

Attachment: gmuck report from templates

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...

Comment 83

[Dave Miller [:justdave]]

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 & mostly).  The trailing /'s should go, too, as was
discussed at length earlier in this bug.

Comment 84

[mental]

Attachment: gmuck fixes

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

Comment 85

[Ville Skyttä]

> +          [% " 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 86

[Jeffrey Baker]

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?

Comment 87

[Sascha Claus]

> 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'.

Comment 88

[Matthew Tuck [:CodeMachine]]

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. =)

Comment 89

[mental]

Attachment: updated fixes

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 90

[Dave Miller [:justdave]]

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 91

[Myk Melez [:myk] [@mykmelez]]

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: \"

Comment 92

[Myk Melez [:myk] [@mykmelez]]

>>-  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. :-)

Comment 93

[mental]

Attachment: unrotted

> 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 94

[Myk Melez [:myk] [@mykmelez]]

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).

Comment 95

[mental]

Attachment: update

Comment 96

[Myk Melez [:myk] [@mykmelez]]

Reassigning bug to patch author.

Comment 97

[Myk Melez [:myk] [@mykmelez]]

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

Comment 98

[Myk Melez [:myk] [@mykmelez]]

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.

Comment 99

[Myk Melez [:myk] [@mykmelez]]

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

Comment 100

[Jouni Heikniemi]

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

Comment 101

[Jesper Hertel]

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?

Comment 102

[timeless]

vrfy fixed.

Comment 103

[Jesper Hertel]

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.

Comment 104

[Christian Reis]

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.

Comment 105

[Dave Miller [:justdave]]

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.

Comment 106

[Stewart Gordon]

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

Comment 107

[Stewart Gordon]

252826 -> 252856

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

Comment 108

[Dave Miller [:justdave]]

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.

Comment 109

[Dave Miller [:justdave]]

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