Closed Bug 3875 (basefont) Opened 25 years ago Closed 22 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
233 bytes, text/html
Details
additional testcase demonstrating basefont
793 bytes, 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

    
    

    
  
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: 24 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: 24 years ago → 22 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: 22 years ago → 22 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: