Make bugzilla use valid HTML 4.01 Transitional (initial attempt)

VERIFIED FIXED in Bugzilla 2.16

Status

()

P1
normal
VERIFIED FIXED
19 years ago
6 years ago

People

(Reporter: zach, Assigned: xor)

Tracking

({meta})

unspecified
Bugzilla 2.16
Dependency tree / graph

Details

(Whiteboard: DO NOT REOPEN THIS BUG - see comments 108/109)

Attachments

(2 attachments, 9 obsolete attachments)

(Reporter)

Description

19 years ago
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.
(Reporter)

Comment 1

19 years ago
Created attachment 12236 [details] [diff] [review]
Patch to make index.html use valid html
(Reporter)

Comment 2

19 years ago
Created attachment 12237 [details] [diff] [review]
Patch to make booleanchart.html use valid html
(Reporter)

Comment 3

19 years ago
Created attachment 12238 [details] [diff] [review]
Patch to make bug_status.html use valid html
(Reporter)

Comment 4

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

Comment 5

18 years ago
possible 2.12
Assignee: tara → cyeh
Whiteboard: 2.12
(Reporter)

Comment 6

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

Comment 7

18 years ago
As best I can tell, the patch has been applied.  Closing out.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Reporter)

Comment 8

18 years ago
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 9

18 years ago
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.
Status: REOPENED → ASSIGNED
Whiteboard: 2.12

Comment 10

18 years ago
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 ?
Whiteboard: 3.0
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()

Comment 13

18 years ago
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?
Whiteboard: 3.0 → 3.0, maybe 2.16

Comment 14

18 years ago
> 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).

Comment 17

18 years ago
> 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...
Target Milestone: --- → Bugzilla 2.16
Whiteboard: 3.0, maybe 2.16

Comment 22

18 years ago
> 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. :-)
Priority: P3 → P1

Comment 27

18 years ago
Created attachment 44201 [details] [diff] [review]
Make enter_bug.cgi emit XHTML 1.0 Strict markup

Comment 28

18 years ago
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

18 years ago
Created attachment 44205 [details] [diff] [review]
Previous patch + make index.html valid

Comment 30

18 years ago
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.

Comment 32

18 years ago
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...)
Assignee: Chris.Yeh → jwbaker
Status: ASSIGNED → NEW

Comment 33

18 years ago
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

Comment 36

18 years ago
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)?
Keywords: patch, review

Comment 40

17 years ago
Created attachment 46395 [details] [diff] [review]
previous changes + make query.cgi emit valid markup

Comment 41

17 years ago
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.

Updated

17 years ago
Component: Bugzilla → User Interface
Product: Webtools → Bugzilla
Version: other → unspecified
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.
Depends on: 96983

Comment 43

17 years ago
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.

Comment 45

17 years ago
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)

Comment 47

17 years ago
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

17 years ago
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

17 years ago
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!
Depends on: 65164, 103554

Updated

17 years ago
No longer depends on: 65164

Updated

17 years ago
Depends on: 65164
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.
Assignee: jwbaker → justdave
Severity: normal → blocker
Depends on: 98707, 103953
No longer depends on: 96983

Updated

17 years ago
Depends on: 109029
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.
Depends on: 109064

Updated

17 years ago
Blocks: 92997

Comment 54

17 years ago
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.
Summary: Make bugzilla use valid HTML → Make bugzilla use valid HTML 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
Keywords: review
Keywords: patch → meta
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

17 years ago
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?
(Assignee)

Comment 62

17 years ago
*** Bug 129442 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 63

17 years ago
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.
No longer depends on: 109064

Comment 65

17 years ago
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.

Updated

17 years ago
Depends on: 131568

Comment 71

17 years ago
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

17 years ago
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.

Comment 75

17 years ago
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.
Severity: blocker → normal
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
Target Milestone: Bugzilla 2.18 → Bugzilla 2.16
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.
Depends on: 11901
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18

Updated

17 years ago
Depends on: 137669

Comment 80

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

Comment 81

17 years ago
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

17 years ago
Created attachment 79416 [details]
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...
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.

Attachment #12236 - Attachment is obsolete: true
Attachment #12237 - Attachment is obsolete: true
Attachment #12238 - Attachment is obsolete: true
Attachment #44201 - Attachment is obsolete: true
Attachment #44205 - Attachment is obsolete: true
Attachment #46395 - Attachment is obsolete: true
(Assignee)

Comment 84

17 years ago
Created attachment 79577 [details] [diff] [review]
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

17 years ago
> +          [% " 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

17 years ago
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?
Attachment #79577 - Flags: review+

Comment 87

17 years ago
> 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. =)
(Assignee)

Comment 89

17 years ago
Created attachment 81492 [details] [diff] [review]
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?
Attachment #79577 - Attachment is obsolete: true
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=
Attachment #81492 - Flags: review-
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. :-)
(Assignee)

Comment 93

17 years ago
Created attachment 84029 [details] [diff] [review]
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.
Attachment #81492 - Attachment is obsolete: true
(Assignee)

Updated

17 years ago
Attachment #84029 - Flags: review+
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).
Attachment #84029 - Flags: review+
(Assignee)

Comment 95

17 years ago
Created attachment 84393 [details] [diff] [review]
update
Attachment #84029 - Attachment is obsolete: true
(Assignee)

Updated

17 years ago
Attachment #84393 - Flags: review+
Reassigning bug to patch author.
Assignee: justdave → xor
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
Status: NEW → RESOLVED
Last Resolved: 18 years ago17 years ago
Resolution: --- → FIXED
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
Target Milestone: Bugzilla 2.18 → Bugzilla 2.16

Comment 100

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

Comment 101

16 years ago
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

16 years ago
vrfy fixed.
Status: RESOLVED → VERIFIED
Summary: Make bugzilla use valid HTML 4.01 Transitional → Make bugzilla use valid HTML 4.01 Transitional except for WRAP which is covered by some other bug

Comment 103

16 years ago
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

16 years ago
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.
No longer depends on: 11901, 137771

Comment 106

14 years ago
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
Status: VERIFIED → REOPENED
Depends on: 11901, 226229, 252826
Resolution: FIXED → ---

Updated

14 years ago
Summary: Make bugzilla use valid HTML 4.01 Transitional except for WRAP which is covered by some other bug → Make bugzilla use valid HTML 4.01 Transitional

Comment 107

14 years ago
252826 -> 252856

Darn bug 40896 again!  And there was me thinking I'd checked the dependency links!
Depends on: 252856
No longer depends on: 252826

Updated

14 years ago
Depends on: 265011

Updated

14 years ago
Target Milestone: Bugzilla 2.16 → Bugzilla 2.22
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.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago14 years ago
No longer depends on: 11901, 252856
Resolution: --- → FIXED
Target Milestone: Bugzilla 2.22 → Bugzilla 2.16
Bug 273847 has been filed to pick up where this one left off.
Status: RESOLVED → VERIFIED
Summary: Make bugzilla use valid HTML 4.01 Transitional → Make bugzilla use valid HTML 4.01 Transitional (initial attempt)
Whiteboard: DO NOT REOPEN THIS BUG - see comments 108/109
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.