Closed
Bug 466
Opened 27 years ago
Closed 26 years ago
"font stacks" and a parsing algorithm bug
Categories
(Core :: Layout, defect, P1)
Core
Layout
Tracking
()
M6
People
(Reporter: jmomose, Assigned: harishd)
Details
Created by Jared Momose (jmomose@casefinder.com) on Tuesday, June 30, 1998 2:30:24 PM PDT
Additional Details :
There is not a separate section for "logical" bugs, so Ill
present my case in this section.
This bug is deals with text and attribute changing when a
document is displayed on a screen.
From what I have seen, when Netscape loads and displays
documents on the screen, it sets up a "Font Stack" to do its
attribute changing. Say you change the current text in a
document to bold; Netscape pushes the current font onto a
stack and uses that font + bold for the new font. The
problem comes when you have a line like the following.
text <B> text <I> text </B> text </I> text
When the </B> tag appears, the font stack is popped, and a
previous font is retrieved. However, this previous font
does not have bold turned off, but rather has italics turned
off! If you are following me, take it one step further.
Try putting a <FONT COLOR="#mycolor"> in the above html line
and modifying it such that a different attribute is turned
off before the color is.
Another question arises: "who would do such a thing as
overlap font attributes?". Well....me!
I would love to hear some input from mozilla developers,
especially reasons *why* this "Font Stack" was implemented
into the browser. (Am I missing something? Is it faster
than other techniques for formatting and displaying a doc?
Easier?)
Jared Momose.
Geronimo Developement Corp.
Updated•26 years ago
|
Assignee: dp → nisheeth
Comment 1•26 years ago
|
||
Would this be legal HTML: <b> text <i> text </b> more text </i>
Updated•26 years ago
|
Status: NEW → ASSIGNED
Comment 2•26 years ago
|
||
Off the top of my head, I'd say that that is invalid HTML. I'll check
the spec. Accepting bug...
Updated•26 years ago
|
Product: MozillaClassic → Browser
Version: 1998-04-29 → other
Comment 3•26 years ago
|
||
not sure if this is still relevant in new codebase... if not feel free to close
Comment 4•26 years ago
|
||
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
Updated•26 years ago
|
Target Milestone: M7
Comment 5•26 years ago
|
||
I just checked out "<B> bold <I> bold-italic </B> italic </I>" in Gecko. The
"italic" text gets rendered in normal font while IE 5 renders it in italic font.
I remember Rick had ideas on how to deal with this case, so I'm ccing him.
Also, ccing Harish, the in-process-of-becoming parser guru.
Setting milestone to M7 for now...
Assignee: nisheeth → harishd
Status: ASSIGNED → NEW
Target Milestone: M7 → M6
This is a classic case of Residual-Style problem.
In the example, <B> bold <I> bold-italic </B> italic </I>, </B> closes <I> and
<B> leaving the text "italic" to be rendered in a normal font. Rickg and I are
working on this problem.
Reassigning the bug to myself and setting M6 milestone.
Updated•26 years ago
|
Status: RESOLVED → VERIFIED
Comment 9•26 years ago
|
||
Agreed. This is a duplicate of 991.
You need to log in
before you can comment on or make changes to this bug.
Description
•