Closed
Bug 63987
Opened 24 years ago
Closed 22 years ago
Increasing/Decreasing fontsize is behaving weird
Categories
(Core :: CSS Parsing and Computation, defect, P2)
Core
CSS Parsing and Computation
Tracking
()
VERIFIED
FIXED
mozilla1.3alpha
People
(Reporter: hwaara, Assigned: glazou)
Details
(Keywords: topembed+)
Attachments
(2 files, 3 obsolete files)
3.59 KB,
text/html
|
Details | |
3.68 KB,
patch
|
dbaron
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001229 BuildID: 20001229 Let's say 'y' is the number of times one needs to click the increase-textsize control in Editor to increase the text to its maximum size. Then say 'x' is the number times I've been clicking. If x > y then a = x - y End if Now, say I want to decrease the textsize again. Then i need to click 'a' times *first* in order to make the size y-1, y-2 and so on.. got it? Reproducible: Always Steps to Reproduce: 1. Open up Editor 2. Write in some text, select it 3. Click the 'a' with an uparrow (means increase text size) say, 20 times 4. Now, try to decrease the textsize again.. 5. Notice how you have to click 20-maximumfontsize times first, in order to actually decrease the textsize. Actual Results: I had to click a number of times on the decrease-textsize control before I could actually change the size. Expected Results: I click one time on the decrease-textsize control, and the textsize decreases one step. Without having to click the number of extraclicks first, as above. I know this is a messy bugreport but I couldn't figure out a short and clean way to tell it. Sorry. But, you know, english isn't my native language. Thanks.
Comment 1•24 years ago
|
||
confirming on Linux (current build from CVS source) and changing Platform/OS to all/all
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 98 → All
Hardware: PC → All
Reporter | ||
Comment 2•24 years ago
|
||
I know why this happends. Every time one pushes, for example, the "+ font size button" it adds a "<BIG>" tag, and every time one pushes the -, it adds a "<SMALL>". In my opinion, this is a really lame way of handling it. We could just have an integer, which sets a "<FONT size=i>" in the source. Any comments?
Comment 3•24 years ago
|
||
the use of <big> and <small> is being used until we are using css values for format, the <font> element has been deprecated and we do not want to use deprecated elements
Comment 4•24 years ago
|
||
there are a few possible options to helping improve the use of the big/small issue: 1. remove the big/small from the toolbar and incorporate a combobox that uses the same terms as in the menu Format|Size 2. when the user adds additional <big> elements, and then chooses to go smaller, we could remove the outside most <big> element until all <big> elements are removed, and then begin to add <small> if the user chooses to go smaller than the default size. 3. allow only as many big/small elements as the current font allows, and then repeat step 2 when appropriate. assigning to jfrancis for review and cc cmanske
Assignee: beppe → jfrancis
Comment 5•24 years ago
|
||
If I understand the bug report, the issue is not that we aren't removing "bigs" when someone clicks "small". We *are* removing them. The bug is that we aren't aware of whether a big/small tag has any visible effect, so we let the user introduce more of them as desired even if they do nothing. From an html authoring point of view, I don't think this is a bug at all. If the user wants 20 nested bigs, let them have them. Maybe they know the document will later be viewed with an app that will actually render 20 bigs larger than 19 bigs, etc. At one point in it's development, gecko did that too. Now it doesn't. I suspect that fixing this would involve examining resolved style on the selection and disabling big/small as appropriate when maximum/minimum sizes were reached in the style system. Daniel, what do you think?
Status: NEW → ASSIGNED
Priority: -- → P4
Target Milestone: --- → Future
Assignee | ||
Comment 6•24 years ago
|
||
This is a CSS issue, I am Cc:ing pierre and marc. Also try : <span style="font-size : 48pt">FOOXXXXXX<big>XXXX</big></span> or <span style="font-size : 48pt">FOOXXXXXX<span style="font-size : larger">XXXX</span></span> Actually, the behavior described by the reporter is acceptable, in terms of CSS conformance (see CSS2 section 15.2.4). The UA style rule attached to the element BIG is : big { font-size : larger } This 'larger' value increases the real absolute keyword value of font-size. For instance from 'medium' to 'large'. The CSS 2 spec explicitely says that "The user agent may have to extrapolate table values if the numerical value goes beyond the keywords.". Not "should" or "must". BTW, there is a difference between browsers' common practice and the HTML 4.0 specification which says "BIG: Renders text in a "large" font.". Not a largeR font, a large font only. Then nested BIGs should not, normally, increase the font size more than once. The CSS specification, in its appendix A, adds to confusion : BIG { font-size : 1.17em } ... Anyway... Even if our code is conformant to the spec, I understand the reporter's point and think that we should extend our implementation to allow font sizes beyond the limits of xx-small and xx-large.
Assignee | ||
Comment 7•24 years ago
|
||
I have just realized that the editor uses only BIG and SMALL for font size effects... IMHO, this is a bad idea for HTML presentation, and the reporter is right ; SIZE attribute on FONT should probably be used instead of BIG and SMALL, if there is no good reason for the actual choice.
Comment 8•24 years ago
|
||
we chose to use big/small because the font element is deprecated and wanted to avoid using deprecated elements. when we support css values, then we should include font size, until then we are limited in what can be used.
Comment 9•24 years ago
|
||
reassigning to Daniel. Daniel, is it possible for you to get a css solution in to resolve the font size issue?
Assignee: jfrancis → glazman
Status: ASSIGNED → NEW
Comment 10•22 years ago
|
||
removing myself from the cc list
Assignee | ||
Comment 11•22 years ago
|
||
patch pending, raising priority.
Status: NEW → ASSIGNED
Priority: P4 → P2
Target Milestone: Future → mozilla1.3alpha
Assignee | ||
Comment 12•22 years ago
|
||
This patch makes our implementation of BIG and SMALL conformant to the HTML 4.01 spec because the spec does not imply any higher or lower limit for the font size when increased/decreased by BIG or SMALL.
Comment 13•22 years ago
|
||
Comment on attachment 106346 [details] [diff] [review] patch #1 r=, but comment what the index == 6/0 mean more specifically
Attachment #106346 -
Flags: review+
Comment on attachment 106346 [details] [diff] [review] patch #1 Why do you add '-moz-smaller' and '-moz-larger'? Shouldn't the existing 'larger' and 'smaller' work this way? See http://www.w3.org/TR/REC-CSS2/fonts.html#value-def-relative-size
Comment 15•22 years ago
|
||
RogerMW--you may want to consider taking this patch for your branch (when it's super-reviewed and landed on the trunk)
Assignee | ||
Comment 16•22 years ago
|
||
Assignee | ||
Updated•22 years ago
|
Attachment #106346 -
Attachment is obsolete: true
Assignee | ||
Comment 17•22 years ago
|
||
Comment on attachment 106364 [details] [diff] [review] patch #2, in answer to dbaron Forgot to deal with a few cases in this patch ; new patch will be available on monday.
Attachment #106364 -
Attachment is obsolete: true
Comment on attachment 106364 [details] [diff] [review] patch #2, in answer to dbaron 1.5 and 0.9 don't seem symmetric, but I'd expect them to be. Also, what does this patch do when you have 'smaller' on a font size that's off of the *top* of the scale? Perhaps a better algorithm would be to scale by the ratio of the nearest pair of sizes in the table? Is that easy to implement?
Assignee | ||
Comment 20•22 years ago
|
||
> 1.5 and 0.9 don't seem symmetric, but I'd expect them to be. Right, and that's why I obsoleted the last patch > Perhaps a better algorithm would be to scale by the ratio of the nearest pair > of sizes in the table? Is that easy to implement? I checked that the ratio is always close to 150% between x-large and xx-large and always close to 90% between x-small and xx-small. So I wonder if it's worth doing the query..
Assignee | ||
Comment 21•22 years ago
|
||
Attachment #106570 -
Attachment is obsolete: true
Assignee | ||
Comment 23•22 years ago
|
||
Comment 24•22 years ago
|
||
Marking Topembed+ as part of topembed triage
Comment on attachment 106642 [details] [diff] [review] patch #3 r=dbaron if you: * fix the spelling of "parameter" * wrap the comments at less than 80 characters It might be good at some time in the future to move this stuff (perhaps even the CalcFontPointSize) into FindNext{Smaller,Larger}FontSize. After all, this is the only caller...
Attachment #106642 -
Flags: review+
Comment 26•22 years ago
|
||
Comment on attachment 106642 [details] [diff] [review] patch #3 sr=bzbarsky, but dbaron is right. I don't like this knowledge of magic constants like 0, 6, etc... they should either have names or all this logic should be encapsulated in a function that just gives the nscoord size of the next larger or smaller size (if this function needs to take aParentFont->mSize, so be it).
Attachment #106642 -
Flags: superreview+
Assignee | ||
Comment 27•22 years ago
|
||
checked in (trunk)
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•