Closed Bug 105796 Opened 23 years ago Closed 14 years ago

Pref to force overflow: auto for frames and blocks

Categories

(SeaMonkey :: UI Design, enhancement)

Product:
SeaMonkey
Component:
UI Design
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED
Milestone:
Future

People

(Reporter: mpt, Assigned: jag+mozilla)

References

Details

Many Web authors hard-code sizes for elements in frames and other block elements (or, even worse, assume that everyone else will be using the font sizes etc which their own browser uses), then set {overflow: hidden} to prevent scrollbars from appearing. However, if the user has set a text zoom level other than 100%, this will often cause elements to disappear off the bottom of the block, with no obvious way to view them. Therefore, there should be a pref which is the equivalent of * {overlow: auto;} (this CSS might not be exactly right:-), which can then be toggled in the GUI rather than expecting the user to edit userContent.css themselves. This bug is spun off from bug 89557, which would cover the GUI to expose the pref.
Blocks: 89557
Hmm.. we could basically do this the same way we currently do things like link underlining and default colors, right?
The correct CSS syntax is overflow: auto. Changing summary to reflect this. Before: Pref to force scroll:auto for frames and blocks After: Pref to force overflow: auto for frames and blocks
Summary: Pref to force scroll:auto for frames and blocks → Pref to force overflow: auto for frames and blocks
"body { overflow: auto }" makes nothing show up when used in a stylesheet of any kind. "* { overflow: auto}" (or "* { overflow: scroll }") makes the browser crash in what looks like an infinite loop when put in userContent.css. If put in a page's stylesheet it just makes no content show. So there are a few issues to resolve here... :) (perhaps "* { overflow: auto }" is not the rule we want).
Okay, it looks like I don't know CSS as well as I thought. :-) Some points: * <body> isn't a block-level element which is why overflow: auto didn't work for it. * For frames, can't we just ignore the scrolling="no" attribute? * Blocks, then. I was convinced overflow: auto should work there so I made a demo page. The results were really strange leading me to doubt my own understanding of the specs (my own understanding of the basics of Web pages, actually) and Gecko's rendering ability. I'll attach the page.
Okay, I tried to attach the page but I got the following rather funky error: Can't use an undefined value as an ARRAY reference at CGI.pl line 1064, <STDIN> line 45. So you can get the file at http://us.f1.yahoofs.com/users/a9151e7b/bc/Mozilla/overflowauto.html?bcuNxI8AsXwScoS1 instead.
Argh! That doesn't work either! Try getting the file from http://uk.edit.briefcase.yahoo.com/bc/alexbishopuk/lst?.dir=/Mozilla. You'll have to follow the link to it.
from html.css: body { display: block; margin: 8px; } I did some more investigating. looks like the problem actually lies in setting overflow:auto on body and html at the same time. Filed as bug 105923 > For frames, can't we just ignore the scrolling="no" attribute? I think so.... > The results were really strange leading me to doubt my own > understanding of the specs <div style="height: 50; width: 200; overflow: auto"> That really needs units on the lengths in strict mode. :) Do that and all is good. The CSS validator is your friend, you know.
Depends on: 105923
>> The results were really strange leading me to doubt my own >> understanding of the specs > <div style="height: 50; width: 200; overflow: auto"> > That really needs units on the lengths in strict mode. :) Do that and all is > good. > The CSS validator is your friend, you know. Thank you! I'll just reiterate what I said earlier: "Okay, it looks like I don't know CSS as well as I thought. :-)" I've uploaded the corrected file, overflowauto2 to http://uk.edit.briefcase.yahoo.com/bc/alexbishopuk/lst?.dir=/Mozilla.
Target Milestone: --- → Future
This can be done via user css -> wontfix ?
Not until the user CSS actually works as advertised... even then UI for this may make sense.
Depends on: 105928
Since this is all frontend (waiting on backend work), over to XP Apps.
Assignee: attinasi → jaggernaut
Component: Layout → XP Apps
QA Contact: petersen → paw
*** Bug 245458 has been marked as a duplicate of this bug. ***
Product: Core → Mozilla Application Suite
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.