Closed Bug 3875 (basefont) Opened 26 years ago Closed 23 years ago

deprecated <basefont> element not supported

Categories

(Core :: Layout, enhancement)

Product:
Core
Component:
Layout
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: phillip, Unassigned)

References

(
URL
)

Details

(4 keywords)

Attachments

(2 files)

test case from reporter
(deleted), text/html
Details
additional testcase demonstrating basefont
(deleted), text/html
Details
PROBLEM: on all platforms, the element BASEFONT is ignored. i'm not sure if this is Layout, Parser, or Style... PLATFORMS: MacOS 8.51, WinNT 4, RedHat 5.2 TESTCASE: <html> <body bgcolor=white> <basefont size=7 color="red" face="verdana, arial, helvetica, sans-serif"> should be red sans-serif, size 7 <br> <font size=3>should be red sans-serif, size 3</font> </body> </html> EXPECTED OUTPUT: view the testcase in IE4.x to see the correct output. the text on each line should describe it's own style. ACTUAL OUTPUT: all text is the default font face, black, and default sized too. MOTIVATION: this is required by the HTML 4.0 Transitional DTD from the W3C.
adding url for the above testcase.
QA Contact: 4144 → 4130
Looks like you own the BASEFONT code
Assignee: troy → kipp
Assignee: kipp → peterl
Since you and rick talked up a storm about how to do basefont I'm assinging it to you...Feel free to involve vidur if you need content objects created...
*** Bug 4159 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
This will never be implemented in a Nav compatible way (Nav allowed them anywhere and their effect was document-linear, not structural). But we can at least add some standards compliant support. Another test URL from mcaplin@miami.edu (bug 4159) http://umsis.miami.edu/~mcaplin/default/default2.html
Target Milestone: M7
Target Milestone: M10 → M11
Pushing off non-beta 1 issues
Reassigning peterl's bugs to myself.
Accepting peterl's bugs that have a Target Milestone
Attached file test case from reporter (deleted) —
Pushing my M15 bugs to M16
Not critical: M19.
Target Milestone: M16 → M19
Marking html4, nom. nsbeta3, recc. nsbeta3+ [somedate-]. Reasoning, it's an HTML 4 compliance issue, so we'd like to fix it if at all possible, but we could simply release note and FUTURE this if we run out of time.
Keywords: html4, nsbeta3
This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug, or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.
Target Milestone: M19 → Future
Pierre, isn't work on supporting BASEFONT (necessary for backward compatibility and correct display of existing content on the web) a higher priority than work on implementing user style sheets (a feature that we could add post-FCS and that, though desirable, would not if omitted in FCS cause incorrect display of existing content on the web)? Please let me know your thoughts on the matter. Marking 4xp. (although 100% compatibility with 4x's behavior is not the goal, we want to be compatible with HTML that uses this once in the HEAD)
Keywords: 4xp
Eric: As noted by Peter on 1999-03-27 19:12, this will never be implemented as Nav4 did. This feature is of negligible importance -- the only difference will be fonts, and they can never be guarenteed anyway. There is a better way to do it (<style type="text/css"> body { font-family: .....; } </style>) which is not deprecated -- unlike BASEFONT, which is considered to be legacy stuff which we should not be doing using CSS instead. On the other hand, alternate stylesheets are a valuable new feature -- just see how much the WaSP like it ;-) -- which increase accessibility, are what the W3C are pushing at the moment, and which we already have 80% implemented. In conclusion: I recommend we Future or WONTFIX our BASEFONT support, relnote it, and focus on more important issues. Pages which *rely* on BASEFONT won't look any better if we implement it per the spec, since we would only take the first BASEFONT into account, not all of them per Nav4. Anyway... That's my take on this... I will now defer to the higher beings... ;-)
It's Friday night. We'll be better off taking this matter offline :-)
OK, you two have convinced me, subject to the assumption that there are not a lot of major top100 sites specifying default font for the entire document in the HEAD via a BASEFONT. If we find that we're causing major sites to look wrong, we may need to reconsider this. For now, withdrawing nsbeta3 nomination. Anyone reading this/concerned by this bug: what you have to do to get reconsideration is provide as many examples as possible of major sites that are affected by this bug.
Keywords: nsbeta3
BTW, HTML 3.2 and HTML 4.0 define <basefont> as an inline element; it's not allowed in the <head>
Huh. So it is. How utterly peculiar! In that case, there is even less chance of us ever getting that to work. It is completely contrary to the idea of CSS and the DOM. It is thus also completely contrary to the way our engine is designed (since our engine is designed for CSS and DOM). Note. I searched over 6000 sites (the top100 and any pages mentioned on the top100) and found the following data: * Less than 1% of pages included the <basefont> element. * Of those that did, around 75% are from Microsoft-owned sites. * Of the pages I looked at carefully (around 1 per site) none mentioned the <basefont> element more than once. * Of the pages I looked at very carefully (the high profile ones) none had any <basefont> related font rendering differences when viewed in IE5.5 and Seamonkey. I would recommend simply WONTFIXing this.
Thanks for the research. Adopted: WONTFIX.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
Since it's *technically* required for HTML 4, even if it's not a Good Idea (TM), relnote-ing.
Keywords: relnote
*** Bug 47228 has been marked as a duplicate of this bug. ***
Verify this?
Verifying WONTFIX.
Status: RESOLVED → VERIFIED
Well, lack of BASEFONT support makes it a PITA (Pain In The A..) to use write VISCII documents that work with Mozilla. See Bug#86427. I must re-specify the font on EVERY text element. Grrrr! Ok, so fonts that cheat with encoding are an evil quirk from the past, whereas proper unicode support is still in the future? Looks like, as always, Vietnam has a past and a future, but no present :-( Now, we vietnamese people are of course the first to blame: just go forward and code. Sigh.
"WONTFIX" is a Bad Decision. It means that Netscape 6 will render lots of pages incorrectly which render correctly in IE. In the conversation about this bug, the most important comment is this one: "Of the pages I looked at carefully (around 1 per site) none mentioned the <basefont> element more than once." That means that, for practical purposes, the concern about inability to implement in a Nav-4 complient way is of no concern. ("Nav allowed them anywhere and their effect was document-linear, not structural.") It means that Hixie was just plain wrong when he wrote, "Pages which *rely* on BASEFONT won't look any better if we implement it per the spec, since we would only take the first BASEFONT into account, not all of them per Nav4," because the first basefone *IS* "all of them" in real world web pages. This sort of thing is why Netscape is losing the browser war.
*** Bug 141146 has been marked as a duplicate of this bug. ***
We really suck if we ignore elements of HTML standards because we do not like them. I believed we are better than Microsoft :-( BASEFONT is valid HTML at least from version 3.2 to 4.01 Transitional. Therefore it should even work in Mozilla standards mode (see attachments to bug 141146)
To reiterate: * Of the pages I looked at very carefully (the high profile ones) none had any <basefont> related font rendering differences when viewed in IE5.5 and Seamonkey. We have lots of bugs that are costing us market share, but this is definitely not one of them. On the other hand, if you were to come up with a clean, low-risk fix for this bug then it is quite possible that it would be accepted.
Reopening per comment #29. If a "clean, low-risk fix" is welcome, this is certainly not a WONTFIX situation. Therefore, I believe this should be a "helpwanted" bug assigned to nobody@mozilla.org.
Status: VERIFIED → REOPENED
Keywords: helpwanted
Resolution: WONTFIX → ---
Reassigning to nobody@mozilla.org. Ian: We do not close bugs on a open source project basing on lack of resources. This is completely against the spirit of Mozilla.
Assignee: pierre → nobody
Status: REOPENED → NEW
Reseting priority and target milestone (nobody has no priorities).
Priority: P3 → --
Target Milestone: Future → ---
And this is how this project ends up with thousands of unowned pointless bugs that no-one will ever fix. Yay us. We won't fix this. Live with it or submit a patch, but please don't artificially inflate our bug count by leaving bugs open that no-one has any intention of ever working on. If anyone _did_ suggest they might want to spend their time fixing this bug, I could give them hundreds of much, much more important bugs that are just as challenging but would benefit the world a whole lot more.
Status: NEW → RESOLVED
Closed: 25 years ago → 23 years ago
QA Contact: claudius → ian
Resolution: --- → WONTFIX
Ian: You're letting your balance sheet get the better of your judgement. This isn't a numbers game. Nobody "wins" when the open bug count drops to some arbitary figure. Bugs are for tracking problems with the product. This is a legitimate problem, even if it isn't as significant as many others. If this is a sufficiently legitimate report for you to solicit a patch to address it, it should remain open. As I've seen it used, WONTFIX is for problems for which a patch would run contrary to a design goal of Mozilla. WONTFIX is not for shitcanning bugs that *you think* are so insignificant as not to warrant the increment to Mozilla's open bug count. It doesn't matter one whit if this project has thousands of unopened bugs that no one will ever fix. Because in fact, particularly due to the open nature of this project, we can't say with any certainty what bugs will never get fixed. But by labeling a bug WONTFIX, you stand to reduce any chance it has of getting attention. On the other hand, there is *zero cost* associated with leaving the bug open.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
"WONTFIX: The problem described is a bug which will never be fixed." Therefore I am really surprised how Ian can solicit for patches for a bug he wants never fixed... I'll repeat: in an open source project anyone can produce a patch unless this is harmfull for the product (this is what WONTFIX is for). Therefore "I will not work on this" can never imply "I will not let anyone fix this".
> in an open source project anyone can produce a > patch unless this is harmfull for the product Bloat is harmful. Deprecating things is making them ready to fall into obsolescence and unimplementedness. <basefont> is a misfeature that has been successfully dropped. I think reviving it just for completeness doesn't make sense.
Alright then. I retract my statements about a patch being accepted. Supporting <basefont> is not in the interest of the web. IMHO we *should not* fix this bug. WONTFIX. This will never be fixed. > It doesn't matter one whit if this project has thousands of unopened bugs that > no one will ever fix. I disagree, but that is off-topic for this bug.
Severity: normal → enhancement
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Keywords: compat
Resolution: --- → WONTFIX
Summary: BASEFONT ignored by seamonkey → deprecated <basefont> element not supported
I am the owner of one of the Mozilla Tech Evangelism components (Europe: Central). Our task is to send letters to webmasters of standard breaking websites. In the letters we assure them that Mozilla (and browsers derived from Mozilla code) are standard compliant and we expect the same from the authors of the offending page. Can I feel honest if errors like this are WONTFIXed? I think not. One more thing: I am deeply disappointed by Ian's attitude. Writing "if you were to come up with a clean, low-risk fix for this bug then it is quite possible that it would be accepted" while having no intention of accepting the patch is intelectually dishonest. And this is in fact an understatement. Sorry for the spam.
So where are the criteria for which HTML 4.01 DTD's Mozilla will support, and which ones it will not? BASEFONT is a legitimate element in the HTML 4.01 loose.dtd. http://www.w3.org/TR/html401/sgml/loosedtd.html#basefont. I am not arguing one way or another, just curious where an HTML coder can go to determine which elements of HTML 4.01 the Mozilla project has no intention of supporting. I'm just hoping it's not arbitrary.
http://developer.netscape.com/docs/technote/gecko/n6release.html says: "BASEFONT is deprecated and will not be supported in Netscape 6". However Mozilla is (or at least was supposed to be) something more than Netscape6. I still see no reason for not *wanting* to be standard compliant.
> In the letters we assure them that Mozilla (and browsers derived from Mozilla > code) are standard compliant and we expect the same from the authors of the > offending page. Er, Mozilla is not "standards compliant". We have a very good implementation of modern standards, but it is by no means complete, and you should not be claiming that. In addition, not supporting a feature (e.g. <basefont>) is a lot better than incompletely or incorrectly supporting it (as people have suggested we do with <basefont>). There are some important points about <basefont> that make this a non-issue: 1. <basefont> is deprecated. The W3C explicitly ask people not to use this feature of HTML. 2. <basefont> would be *extremely* hard to implement correctly. 3. An incomplete implementation is IMHO worse than no implementation. (Think bug vs enhancement.) 4. Virtually no sites rely on <basefont>. (Take any site that uses <basefont> and compare Mozilla's rendering to IE's.) 5. <basefont> is presentational and everything it can do can be done better using CSS. > Writing "if you were to come up with a clean, low-risk fix for this bug then > it is quite possible that it would be accepted" while having no intention of > accepting the patch is intelectually dishonest. Yes, my apologies. Henri convinced me and changed my mind. I did not mean to appear to be dishonest -- my opinion changed. Note that I did not say that the patch would not be accepted; I am not the module owner so I cannot say whether it would or not. If someone did consider working on this, I would urge them to look at our much more important bugs that actually affect web pages, rather than this bug which is a holdover from the 4.x days; if someone actually fixed this, I would urge the module owner not to accept the patch as it would not be helping the web to move on instead of clinging to presetnational markup. Anyway, in practice, it's almost certain that no-one will ever implement this. Leaving this bug open is, frankly, deluding ourselves. Which do you think is more dishonest: leaving this bug open even though nobody will ever look at it and claim that we "support HTML or will one day", or closing this bug as WONTFIX, admitting that we have no intention of ever fixing this bug, and moving on?
Ian: If it's the module owner's call as to whether a patch for this bug would be accepted, and not accepting a patch for this bug is your justification for marking it WONTFIX, why are *you* marking it WONTFIX with no input apparent from the module owner? Rather than pick a path that is the least dishonest, why not settle for honesty? If a bug is legitimate, leave it open. If no one is tending to it, assign it to nobody. I really don't understand why this is so complicated. To reiterate: it doesn't matter one whit if this project has thousands of unowned bugs that no one will ever fix, as long as they document issues for which a proper fix would be accepted if it were offered. You disagree, Ian, and you claim this isn't the place to discuss it. But this is looking more and more like *exactly* the place to discuss it, as it has become clear that culling the open bug list of unlikely-to-be-fixed bugs is your real motivation for WONTFIXing this. If you still don't want to discuss it here, fine. But please indicate where you'd like to see such discussion, because it needs to happen.
Reading though the arguments in this thread it surprizes me that noone has yet offered an alternative solution that would satisfy "both sides". If we agree on that it is a valid bug, however bordering on insignifacant, but a proper solution would be accepted, why not just choose status --- LATER The problem described is a bug which will not be fixed in this version of the product. --- Seems like a easy enough solution to me. In regard to the Mozilla aiming for standards compability and the loose 4.01 DTD, when making a 4.01 webpage you are supposed to do a 4.01 STRICT page to begin with and then add old deprecated (3.2) markup to mainly support old (v3.x and before) browsers, turning it into 4.01 Transitional. Thus for a webcoder that knows what he is doing and is aiming for v4.x+ browser compability, Mozilla supporting basefont or not is a non issue (the effects desired should be created via 4.01 STRICT in Mozilla, not via "hacking" the effect in 4.01 Transitional, that is not why transitional exsists).
> If it's the module owner's call as to whether a patch for this bug would be > accepted, and not accepting a patch for this bug is your justification for > marking it WONTFIX, why are *you* marking it WONTFIX with no input apparent > from the module owner? Not accepting a patch is not my only justification -- the feature is deprecated, the feature would be unnecessary bloat, the feature isn't relied upon by any site on the web, and we already support alternatives to the feature that are significantly better for both the user and content authors. > Rather than pick a path that is the least dishonest, why not settle for > honesty? Honesty is that <basefont> sucks and there is no reason to support it. Honesty is also that no-one in their right mind would spend the time to implement it because doing so would add zero tangible benefit to Mozilla's codebase while adding significant risk to an already fragile engine. > If a bug is legitimate, leave it open. If no one is tending to it, assign it > to nobody. I really don't understand why this is so complicated. That's all very well if there is agreement that eventually the RFE will be considered important enough to be fixed. This bug is not. In fact, the longer we wait, the less important it becomes. How long do you want to wait before we give up trying to support deprecated HTML4 elements? XHTML2? XHTML3? XHTML4? > why not just choose status LATER ... That status is deprecated and will be removed in the coming months.
> Not accepting a patch is not my only justification -- the feature is > deprecated, the feature would be unnecessary bloat, the feature isn't relied > upon by any site on the web, and we already support alternatives to the > feature that are significantly better for both the user and content authors. Those are reasons to reject a patch. If it is decided that a patch to this bug would necessarily be rejected, then WONTFIX is appropriate. But AFAICT from the previous discussion, we still don't have a verdict on that. > > Rather than pick a path that is the least dishonest, why not settle for > > honesty? > > Honesty is that <basefont> sucks and there is no reason to support it. Honesty > is also that no-one in their right mind would spend the time to implement it > because doing so would add zero tangible benefit to Mozilla's codebase while > adding significant risk to an already fragile engine. > > > If a bug is legitimate, leave it open. If no one is tending to it, assign it > > to nobody. I really don't understand why this is so complicated. > > That's all very well if there is agreement that eventually the RFE will be > considered important enough to be fixed. This bug is not. In fact, the longer > we wait, the less important it becomes. How long do you want to wait before we > give up trying to support deprecated HTML4 elements? XHTML2? XHTML3? XHTML4? These are all good arguments for rejecting a patch. You apparently want to skip definitive resolution on that issue and jump to WONTFIX. Why is resolution on that issue so hard to get? Is it really worth all the grief this is causing?
The comments that suggest that BASEFONT should be in the HEAD are incorrect. In Netscape 4.x, BASEFONT does have structural behavior, assuming its close-tag is not omitted. I'll attach a testcase to demonstrate that. BASEFONT could be implemented rather simply at a very slight performance hit with no additional memory hit other than code size, assuming that the parser does the "right" thing with it already. If the parser doesn't do the right thing as far as real pages are concerned, then there's little point, since any parser changes would have the risk of causing pages with basefont to be big memory hogs.
end tag? "<!ELEMENT BASEFONT - O EMPTY -- base font size --> ..." BASEFONT is "special", like A, BR, and so forth. There's also the matter of Hx elements being exempt from the changes it induces.
> BASEFONT is "special", like A, BR, and so forth. Huh? The end tag for A is required. And VERIFIED WONTFIX based on a) the reasons stated by Hixie and b) the fact that <basefont> is evil. And don't even for a second think that that is merely my *opinion*; it is a *fact*. Water is wet, the sky is blue, apples placed in the air above Sir Isaac Newton's head will fall, <basefont> is evil.
Status: RESOLVED → VERIFIED
<p><A name=hi></p> or data:text/html,<a href="about:logo">test it may be the case that the trailing tag is required but it certainly has been omitted frequently in practice.
<!ELEMENT A - - (%inline;)* -(A) -- anchor --> Start tag: required, End tag: required > <p><A name=hi></p> Might work, but is invalid. > data:text/html,<a href="about:logo">test Might work, but is invalid.
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
When I said "special", I was referring to the category in the DTD, not empty tags.
Keywords: compat → testcase
*** Bug 172278 has been marked as a duplicate of this bug. ***
Alias: basefont
*** Bug 181578 has been marked as a duplicate of this bug. ***
*** Bug 217678 has been marked as a duplicate of this bug. ***
re: http://forums.mozillazine.org/viewtopic.php?t=45057 - maybe this could be reopened as an RFE? It seems to be perceived as an error/omission. As for the evilness debate, frames and marquees are evil too... If the demand is great enough, it seems it may as well be supported, for quirks mode, if only to prevent "Mozilla doesn't support basefont and thus smells!" comments.
Moreover basefont is standard compliant and therefore cannot be evil ;-)
well, let's see, 1. may i assign the bug to you: mozilla@mooquackwooftweetmeow.tk? before you start writing a 'fix' would you please 2. write a spec for how this is supposed to behave in a DOM world? 3. when can I expect results?
So RFE's now have to include a fix and a spec beforehand do they?
They do once the people who would have to implement this have stated they have no intention of ever implementing this, yes. Please reade the comments in this bug, which point out that fixing it would be nigh-on-impossible, before reopening it.
When the status of a bug is WONTFIX, that goes further than stating that those assigned to this bug won't fix it. It implies that no patches will be accepted either. If that is the case with this bug, a better explanation for such a position is needed than "because it's evil" or "because I can't see how". Further, taunting commenters by suggesting they submit a proposed spec when there is no intention of accepting a patch if one were ever made is childish.
Hixie does contradict himself on this bug for a log time In comment #29 he wrote: "On the other hand, if you were to come up with a clean, low-risk fix for this bug then it is quite possible that it would be accepted." I re-opened the bug treating it as an invitation. Hixie WONTFIXed it again saying (comment #33): "We won't fix this" I still do believe the proper procedure with this bug is to re-open it and leave it with nobody@mozilla.org as the owner until someone proposes a patch (even if it never happens, which is highly probable). Sorry for the repetition but I felt it was needed. Please do not increase the spam volume writing not to spam this (dead) bug :-)
Read the rest of comment 33 for context. I didn't actually contradict myself. Anyway, who on earth cares. <basefont> is a completely ridiculous, deprecated, useless, DOM-incompatible feature from the dawn of the Web. Welcome to the 21st century. There has been a better solution (CSS) for like 8 years. That's more than half the age of the Web!
As has been stated many times in many bugs: if you don't like the standards, get the standards changed - don't try to break the standards you don't like in Mozilla.
basefont as defined in HTML4 is extremely difficult for us to implement, and also wrong as far as compatibility goes. So we'd be ignoring the standards either way.
To Hixie: My opinion is this bug has almost nil chance of being ever fixed. Agreed. However, you still contradict yourself. According to the rules that govern bugzilla (as well as plain logic), the bug is either: - WONTFIX and then no patch will be accepted or - it is not a WONTFIX case, and therefore it should be left open waiting for a possible patch. You seem deeply confused about this simple choice.
We're not talking about making decisions with absolute certainty here. If there's a 0.001% chance that we'd take a fix, should we not mark it WONTFIX? What about 1%? 10%? I think this bug is well within the criteria for being marked WONTFIX. And if you disagree, it's not worth discussing.
> And if you disagree, it's not worth discussing. C'mon! Do you really imply that it is worth discussing only if I agree? What is there to discuss if we agree? Either my logic or yours is deeply flawed. OK. Let's finish now as we both (three including Hixie) agree that the bug will not bee fixed any time soon.
I meant it's not important enough to care about, so shut up and stop wasting our time.
Plese try to keep some degree of professionalism while commenting here. Thank you.
*** Bug 238121 has been marked as a duplicate of this bug. ***
*** Bug 272714 has been marked as a duplicate of this bug. ***
*** Bug 274222 has been marked as a duplicate of this bug. ***
I work as an IT apprentice in a school as part of my last year of Computer Science in high school. I was given the task of making a website for them. As font, they liked to have something that presented better to students, Comic Sans MS. So I look for a way to tell my browser to get the entire document in that font. I discover the BASEFONT tag at W3schools, which does exactly what I want. Marvelous. Then I discover it works in IE, but not in Mozilla. The school uses IE, and I'm trying to get them to switch to Mozilla. This failure at rendering a correctly coded page that works properly in IE made Mozilla look a little bad. I was forced to throw Mozilla from the PC and work just with IE. And all this because of biasedness that "BASEFONT is teh evil", "We won't fix it.". All opinions. No judgement is needed, just one fact: IT'S STANDARDS-COMPLIANT. So it should be supported by Mozilla, no matter what personal judgements anyone may have. If you don't want to work on the bug, fine, go do something else. But don't pretend to read the mind of the entire world, saying that it won't be fixed, that it is evil, etc. This is sad.
It's not standards compliant, it's deprecated. We are not required to implement deprecated features if we have a good reason not to -- which we do, see the comments in this bug for detailed notes on why implementing <basefont> would be very hard for us. Authors should not use deprecated elements, certainly not in new documents. Use CSS instead.
(In reply to comment #77) > I work as an IT apprentice in a school as part of my last year of Computer > Science in high school. I was given the task of making a website for them. As > font, they liked to have something that presented better to students, Comic Sans > MS. So I look for a way to tell my browser to get the entire document in that > font. I discover the BASEFONT tag at W3schools, which does exactly what I want. > Marvelous. > > Then I discover it works in IE, but not in Mozilla. > > The school uses IE, and I'm trying to get them to switch to Mozilla. This > failure at rendering a correctly coded page that works properly in IE made > Mozilla look a little bad. I was forced to throw Mozilla from the PC and work > just with IE. > > And all this because of biasedness that "BASEFONT is teh evil", "We won't fix > it.". All opinions. No judgement is needed, just one fact: > > IT'S STANDARDS-COMPLIANT. > > So it should be supported by Mozilla, no matter what personal judgements anyone > may have. If you don't want to work on the bug, fine, go do something else. But > don't pretend to read the mind of the entire world, saying that it won't be > fixed, that it is evil, etc. > > This is sad. Wait, you're going to ditch Mozilla since it doesn't support a tag yet supports a superior alternative that works in all modern browsers? Just use CSS for crying out loud. The only argument that could be used to support basefont is for *support of legacy webpages* but you're creating a *new* webpage!
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: