Closed
Bug 47251
Opened 24 years ago
Closed 20 years ago
Make bugzilla use valid HTML 4.01 Transitional (initial attempt)
Categories
(Bugzilla :: User Interface, defect, P1)
Bugzilla
User Interface
Tracking
()
VERIFIED
FIXED
Bugzilla 2.16
People
(Reporter: zach, Assigned: xor)
References
Details
(Keywords: meta, Whiteboard: DO NOT REOPEN THIS BUG - see comments 108/109)
Attachments
(2 files, 9 obsolete files)
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•24 years ago
|
||
Reporter | ||
Comment 2•24 years ago
|
||
Reporter | ||
Comment 3•24 years ago
|
||
Comment 7•24 years ago
|
||
As best I can tell, the patch has been applied. Closing out.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 8•24 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•24 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•24 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 ?
Updated•24 years ago
|
Whiteboard: 3.0
Comment 11•24 years ago
|
||
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•24 years ago
|
||
Oh yeah - there are problems with the header and footer of the pages to that
are called with PutHeader() and PutFooter()
Comment 13•24 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•24 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
?) ?
Comment 15•24 years ago
|
||
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•24 years ago
|
||
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•24 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.
Comment 18•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
BTW: I'm probably wrong.
Updated•24 years ago
|
Whiteboard: 3.0, maybe 2.16
Comment 22•24 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?
Comment 23•24 years ago
|
||
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•24 years ago
|
||
*** Bug 83492 has been marked as a duplicate of this bug. ***
Comment 25•24 years ago
|
||
Attechment 36663 to bug 83492 has some additional suggested changes for this.
Comment 26•24 years ago
|
||
Attachment 36663 [details] [diff], even. I have to spell it right for it to link. :-)
Updated•23 years ago
|
Priority: P3 → P1
Comment 27•23 years ago
|
||
Comment 28•23 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•23 years ago
|
||
Comment 30•23 years ago
|
||
The more recent attachment adds index.html to the list of valid XHTML 1.0 Strict
pages.
Comment 31•23 years ago
|
||
Does this patch have a replacement for NOBR, eg  ? 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   and output that.
Comment 32•23 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•23 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.
Comment 34•23 years ago
|
||
The fixed pages work nicely in Konqueror as well.
Comment 35•23 years ago
|
||
lynx (2.8.4rel1) as well
Comment 36•23 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...
Comment 37•23 years ago
|
||
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•23 years ago
|
||
Well, wouldn't it be better if we did display-time wrapping?
Comment 39•23 years ago
|
||
yeah, but how do you tell the difference between source code (which shouldn't be
wrapped) and actual comments (which should be)?
Updated•23 years ago
|
Comment 40•23 years ago
|
||
Comment 41•23 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•23 years ago
|
Component: Bugzilla → User Interface
Product: Webtools → Bugzilla
Version: other → unspecified
Comment 42•23 years ago
|
||
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•23 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.
Comment 44•23 years ago
|
||
Yes it does.
Comment 45•23 years ago
|
||
What about bug 27403?
Comment 46•23 years ago
|
||
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•23 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•23 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•23 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!
Comment 50•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
Also note character set encoding issues and META tag usage from bug 33856.
Updated•23 years ago
|
Blocks: advocacybugs
Comment 54•23 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>
Comment 55•23 years ago
|
||
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•23 years ago
|
||
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
Comment 57•23 years ago
|
||
> Out of curiosity, has the ISO standardized anything based on XHTML yet?
Not that I'm aware of
Comment 58•23 years ago
|
||
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
Comment 59•23 years ago
|
||
yes.
Updated•23 years ago
|
Comment 60•23 years ago
|
||
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•23 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•23 years ago
|
||
*** Bug 129442 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 63•23 years ago
|
||
That bug came with a patch, attachment 72946 [details] [diff] [review], against the saved source from the
looks of it.
Comment 64•23 years ago
|
||
I believe we should be XHTML. This probably just involves a doctype change.
Comment 65•23 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.
Comment 66•23 years ago
|
||
We are already converting to XHTML is parallel to templatisation.
Comment 67•23 years ago
|
||
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•23 years ago
|
||
in that case, we need to change all the doctypes to say so, and probably change
the summary on this bug.
Comment 69•23 years ago
|
||
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•23 years ago
|
||
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•23 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•23 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.
Comment 73•23 years ago
|
||
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•23 years ago
|
||
> 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•23 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.
Comment 76•23 years ago
|
||
And what are the advantages?
Comment 77•23 years ago
|
||
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
Updated•23 years ago
|
Target Milestone: Bugzilla 2.18 → Bugzilla 2.16
Comment 78•23 years ago
|
||
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•23 years ago
|
||
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/ /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
Comment 80•23 years ago
|
||
I attached patches to bug 137669 to remove the two remaining <nobr> tags.
Comment 81•23 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•23 years ago
|
||
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•23 years ago
|
||
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.
Updated•23 years ago
|
Attachment #12236 -
Attachment is obsolete: true
Updated•23 years ago
|
Attachment #12237 -
Attachment is obsolete: true
Updated•23 years ago
|
Attachment #12238 -
Attachment is obsolete: true
Updated•23 years ago
|
Attachment #44201 -
Attachment is obsolete: true
Updated•23 years ago
|
Attachment #44205 -
Attachment is obsolete: true
Updated•23 years ago
|
Attachment #46395 -
Attachment is obsolete: true
Assignee | ||
Comment 84•23 years ago
|
||
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•23 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•23 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•23 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'.
Comment 88•23 years ago
|
||
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•23 years ago
|
||
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 90•23 years ago
|
||
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 91•23 years ago
|
||
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•23 years ago
|
||
>>- 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•23 years ago
|
||
> 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 ' conversion, so did that too.
Attachment #81492 -
Attachment is obsolete: true
Attachment #84029 -
Flags: review+
Comment 94•23 years ago
|
||
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•23 years ago
|
||
Attachment #84029 -
Attachment is obsolete: true
Attachment #84393 -
Flags: review+
Comment 97•23 years ago
|
||
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
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
Comment 98•23 years ago
|
||
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•23 years ago
|
||
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
Updated•23 years ago
|
Target Milestone: Bugzilla 2.18 → Bugzilla 2.16
Comment 100•22 years ago
|
||
*** Bug 155870 has been marked as a duplicate of this bug. ***
Comment 101•22 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•22 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•22 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•22 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.
Comment 105•22 years ago
|
||
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•20 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
Updated•20 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•20 years ago
|
||
252826 -> 252856
Darn bug 40896 again! And there was me thinking I'd checked the dependency links!
Updated•20 years ago
|
Target Milestone: Bugzilla 2.16 → Bugzilla 2.22
Comment 108•20 years ago
|
||
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•20 years ago
|
||
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
Updated•12 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•