Closed Bug 206235 Opened 22 years ago Closed 22 years ago

limit allowed number of nested <big>s

Categories

(Core :: CSS Parsing and Computation, enhancement)

Product:
Core
Component:
CSS Parsing and Computation
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: xyerp, Unassigned)

References

(
URL
)

Details

(Keywords: compat)

Attachments

(2 files)

HTML Testcase
805 bytes, text/html
Details
testcase using first child rule (quirks doctype)
1.56 KB, text/html
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 The page is so badly deformed that nothing can be seen other than a huge black square in the middle of an ever more huge white square. The page is correctly displayed is all other browsers, including the Linux version of Mozilla. This is not the only site I have seen this happen on. Unfortunately I cannot remember the other URL, but I believe it was another IBM page... Reproducible: Always Steps to Reproduce: 1. Go to the URL 2. Look at the page 3. Cry Actual Results: I used Microsoft Internet Explorer to view the page Expected Results: Displayed the page so it could be read by a human
Problem on this page are all these <big> tags in the beginning: <div align="Center"><big></big> <h1><big><big><big><big><big><big><big><big><big><big><big><big><big><big> <big><big><big>The</big></big></big></big></big></big></big></big></big> </big></big></big></big></big></big></big></big><big><big><big><img src="sblimlogo-35x143.jpg" border="0"> </big></big></big><big><big><big> Project</big></big></big></h1> <big> </big></div> (Though the pages renders fine in IE and Opera 7.11)
DOM inspector shows a computed style for the text ("The") between all those <big>s is 2767px. scrolling around, you can see the text is actually being drawn correctly at that size! (and the rest of the content is way below, of course). So it is actually well-formed, if rather large. The HTML standards don't specify about what should happen, however, IE and Opera seem to ignore further nested <big>s after the 4th level. Evidently we just carry on getting bigger and bigger... It's certainly crappy coding on the page, but maybe it would be sensible to have a limit like those other browsers (e.g. use big > big > big > big > big {font-size: inherit} ) confirming as an enhancement request.
Assignee: general → font
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout: Fonts and Text
Ever confirmed: true
OS: Windows 2000 → All
QA Contact: general → ian
Hardware: PC → All
Summary: Web page TOTALLY malformed. → set size limit for computed font size.
It amusingly also overflows the text zoom code quite dramatically, although that's another bug altogether. I think the summary is wrong, the better solution is to just limit it to <big>. It may also make sense to make it a quirk.
Component: Layout: Fonts and Text → Style System
Keywords: compat
Summary: set size limit for computed font size. → limit allowed number of nested <big>s
Looks to me like Opera & IE must be copying Netscape 3 (2?, 1?), which apparently caps nested <big>'s at <font size=7>, as does Netscape 4. <small> does the same thing. In Moz, it keeps getting smaller. In Netscape 3, nested <small>'s stop at <font size=1>. We could do either the same, or limit to css xx-large/xx-small. Page designers who need text bigger or smaller than that can do it with css.
Attached file HTML Testcase —
*** Bug 210306 has been marked as a duplicate of this bug. ***
So we're just suggesting adding: big > big > big > big > big { font-size: inherit } to quirk.css? Would that be sufficient for what we want? Or would we want something more like: big big big big big { font-size: inherit } (much slower, unfortunately).
well the big > big > big ... was what I'd thought of, and it would handle the page this was reported on. but now you come to mention it, big big big ... would actually be better, and we would then behave the same as IE (and Opera, and I guess NS4) in other cases too. In what cases would the slower version cause a performance hit? only pages with nested bigs, or all pages with a big tag, or all quirks pages? If it's all quirks pages, I guess probably best to go with the faster solution. If it's only silly pages with nested bigs, then probably better for them to be slower but more likely to be readable.
The slower version would be a perf hit on all quirks pages with a <big> tag. Which may in fact be not that many pages...
The first child rule isn't going to be enough. IE6 won't permit <big>'s to go past <font size=7>, but Mozilla is not so constrained.
Does this really affect enough pages for us to care?
If anyone has a page entitled "how to make Mozilla look incompetent", this should be near the top of the list. If authors need text bigger than size=7 they should use CSS.
Um... how does this make Mozilla look incompetent? It makes IE look incompetent for sure (I ask it to make text "big" and it does not).
besides which (and someone will correct me if I'm wrong), there's no easy way of saying "if the current computed font size is smaller than X, then make this bigger, otherwise keep it the same". A simple fix now is better than aiming for a complex fix that will never happen... I note that the page which was the subject of the report has since been fixed...
Unless we are expecting people to be using Mozilla at 10,000px wide resolution in the foreseeable future, there is simply no good reason for HTML markup to result in 1,000px+ character sizes. Netscape 3 & 4 didn't do it. IE doesn't do it. Mozilla shouldn't do it either. It makes Mozilla look incompetent (comment 2) to display a 2767px character in a viewport at most maybe 1600px wide. No useful message can be conveyed that way. If limiting HTML to a maximum of size=7 like IE & the old browsers do is missing from the HTML standard, that's a fault of the standard. If page designers really want 1,000px text characters, make them use CSS.
I vote we put BZ's first child rule in as a stopgap. It simply is not a fix for this behavior, which could be fixed, since that's the way everyone else behaves.
comment 15 is heavily exaggerated -- there's a big gap between <font size=7> and 1000px.
At 1024x768 using Modern fullscreen with text-only buttons, no personal toolbar, and no tabs, the 11th big makes "1" the height of the 635px tall viewport. NAICT, this means it takes roughly 12 bigs to achieve 1000px in height, which is only 8 more than size=7. By my count, there are 17 continguous bigs in comment 2, the source from the original URL, a live web page. Not counting the opening H1, it only takes 4 of them to reach size=7. When I bump resolution back to 640x480, leaving default at 16px, only the 6th excess big is sufficient to make the text taller than the viewport, and thus incapable of conveying a useful message. I don't believe I was exaggerating at all in comment 15.
One, two, or three bigs larger than <font size="7"> is perfectly legitimate, though.
Why?
The question is "why not". There is nothing in the HTML spec prohibiting it, and I fail to see why the following markup: <font size="7">Text <big>bigger</big> text</font> Should only produce text of one size. I _told_ the friggin' browser to make "bigger" big, so it should do as I told it.
That it isn't in the HTML spec is an HTML spec flaw, probably just minor issue oversight during formulation, not a justification for extending the power of HTML as a presentation where others unanimously haven't, don't and most likely won't; and there exists a better way in CSS. The original URL looked broken to any reasonable Mozilla user, which is the bigger real problem. If you really want it that big, you have CSS, you have zoom, and you can increase your default size. Should <small> <small> <small> <small> <small> <small> <small> also be OK? It's just as useless as 17 bigs, or 12, or maybe even 10. Where should a line be drawn? Or, should there be no line at all? I'm not normally one to favor constraint, but here is an exception.
> That it isn't in the HTML spec is an HTML spec flaw The fact that you think so does not make it so.... The question becomes whether we should be imposing random inconsistent behavior on authors. Right now, our behavior is consistent -- <big> makes text bigger, interacting well with things like CSS styling, text zoom, etc. With your proposal, that will no longer be the case. That's a rather big loss, for minimal gain (none that I can see, really). It's always possible to create HTML markup that looks moronic; we can't stop people from shooting themselves in the foot.
OK. Pretend the spec isn't flawed. Make the authors happy. Help them to be as stupid as possible. Prolong the "it works fine in [name any non-Gecko browser]" mantra that makes the non-techie real human users see only that Gecko fails on yet another page. I thought we wanted designers to abandon HTML presentation and use CSS exclusively. Here's a way to nudge that forward, albeit a teensy one. Mozilla is a user agent, not a designer agent. Users need a little help now and then, and protection from excessive designer stupidity is a plus here.
I don't see how it is a help, actually. It just hides their mistake from them. In any case, the URI given in the original bug report works, now, so if we wanted to add this as a quirk, we'd have to find another page that it affected. -> WONTFIX. The two most active Layout hackers, and the Layout QA guy, seem to agree that there isn't much need to do this.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
I doubt the page "designers" employing a gazillion bigs and omitting CSS, doctypes, and charsets are using Mozilla to do their dirty work. This bug is a non-issue. Wontfixing this simply means performance and technical standards compliance again beat out looking good to people who don't understand where ultimate responsibility for an encountered problem lies. A high level issue has arisen here. Sometimes it is insufficient to be altruistic, to be moral in fact, to do what is in fact best for the greater good. Hixie's track record is a worthy one. Nevertheless, recusal from certain decision making may be appropriate to consider.
> This bug is a non-issue. Wontfixing it is ok then, I assume. > Wontfixing this simply means performance and technical standards compliance > again beat out looking good to people who don't understand where ultimate > responsibility for an encountered problem lies. "Looking good to authors who blame browsers for their mistakes" does not appear to be one of the stated goals for Mozilla, so the fact that performance and standards compliance has beaten it would seem to be in line with expectations. > A high level issue has arisen here. [snip rhetoric] Nevertheless, recusal from > certain decision making may be appropriate to consider. I assume you mean "please re-open this bug". If this bug is indeed a "high level issue", please show us sites affected by this bug. There is absolutely no point us reducing performance on all pages that use <big> just to handle an edge case with very few real life occurances.
Wontfixing is not OK with me, but the minescule impact of this behavior doesn't merit further quibbling. Here I'm not at all interested in how we look to authors, only how we look to users. To the user, Mozilla looks broken (incompetent). I meant my last comment 26 paragraph to be taken literally. It was not about this bug, except for its inclusion in a particular universe.
You've agreed that this bug is a minuscule issue, and I don't think anyone has disagreed, so I don't see any problem with a WONTFIX. Unless there are other examples of the same thing in existance, users won't even see this happening, so the wider issue is irrelevant to this bug. Bugzilla is not the place to discuss wider issues...
Status: RESOLVED → VERIFIED
having said that... bug 210991 is another example of the same thing, and it causes a crash.
*** Bug 220598 has been marked as a duplicate of this bug. ***
Bug 224181 many <big> cause Browser crash : "Bad length" could also fit in here, as the fontsize has been caused by many nested <big> tags, but has been duped to the bug showing the same message: Bug 192397 Font sizes over 300pt crash mozilla built with xft and gtk2 coul
*** Bug 224357 has been marked as a duplicate of this bug. ***
*** Bug 241024 has been marked as a duplicate of this bug. ***
*** Bug 258646 has been marked as a duplicate of this bug. ***
It is incomprehensible to me that this situation has been evident for nearly five years without some solution arising. The fact that some site developers only check their results only with IE (or less likely Opera) can result in the problem. Isn't it possible for FireFox to display something like a warning when it runs into a non-standard which is known to deliver very incompatible results (as compared to IE)? Something like "Inappropriate use of <big> detected, contact page developer." My involvement here is that I told the developer's customer that the page was very faulty (along some others), not knowing who the developer was, and was told, essentially, that it works OK in IE so it must be FireFox's fault. And the customer was my local small-town police department! Sigh.
Workaround for users needing to access pages this affects: add the following to userContent.css in your profile's chrome directory: big {font-size: large !important;} That will effectively disregard normal font size inheritance, instead creating a nesting level limit of 1, basing upon the browser's default size setting.
Am I way off base? Isn't the best work-around to use IE or Opera to view these pages? I still think a visible FireFox alert to the viewer that the fault on the page lies with the developer not with FF is a reasonable solution.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: