Pref to force overflow: auto for frames and blocks

RESOLVED EXPIRED

Status

SeaMonkey
UI Design
--
enhancement
RESOLVED EXPIRED
16 years ago
7 years ago

People

(Reporter: Matthew Paul Thomas, Assigned: jag (Peter Annema))

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
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.
(Reporter)

Updated

16 years ago
Blocks: 89557
Hmm.. we could basically do this the same way we currently do things like link
underlining and default colors, right?

Comment 2

16 years ago
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).

Comment 4

16 years ago
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.

Comment 5

16 years ago
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.

Comment 6

16 years ago
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

Comment 8

16 years ago
>> 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.

Updated

16 years ago
Target Milestone: --- → Future

Comment 9

15 years ago
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

Comment 13

8 years ago
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

Comment 14

8 years ago
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

Comment 15

7 years ago
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
Last Resolved: 7 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.