64029 - [RFE] scrollbar suppression and styling

Status: RESOLVED INVALID

(Core :: XUL, enhancement)

Description

[rvj]

There now does not seem to be a way of

1. suppressing the in-built scrollbars of the widgets.
2. styling the in-built scrolbar

Prior to M18 it was possible to use the selector mechanism to hide the in built 
scrollbar(s)

treechildren > scrollbars
{visibility:collapse}

a)This is now no longer supported 
b) nor does the attribute overflow:hidden appear to work 

I have had some conversations via the XPFE newsgroup but it is unclear how this 
is to be resolved. Am I correct in thinking that overflow:hidden should work?

a) tree widget    e.g. <tree style="overflow:hidden" src="file"/>   
b) iframe element e.g. <iframe style="overflow:hidden" src="file"/>

It would be useful to be able to selectively suppress  one or both of the 
scrollbars but in this case a new attribute would be required with options such 
as none, horizontal, vertical, both, auto.

a) tree widget    e.g. <tree id="tree" scrolling="horizontal" src="file"/>   
b) iframe element e.g. <iframe class="iframe" scrolling="both" src="file"/>

This still leaves the question of how to style the inbuilt scrollbars

Is some kind of id or class based style for scrollbars planned.?

Comment 1

[rvj]

Please note that having suppressed one or both scrollbar(s), there still is the 
need to provide support the scrolling of widgets  programmatically.

With the tree widget, methods such as  scrolltoindex are available.

I presume that scrolling the contents of an iframe  programmatically is 
possible by  creating a click event on the appropriate hidden scrollbar 
(horizontal/vertical)?

Is this true?

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

You shouldn't be able to style scrollbars from the document's style sheet with
selectors matching elements that aren't in the document.  That that once worked
was a bug.

Comment 3

[Hixie (not reading bugmail)]

When we switch to XBL form controls, you'll be able to swap the binding and do
whatever you like to the form controls. If that makes no sense then ask about it
in netscape.public.mozilla.xbl. ;-)

In the meantime, I know of no standard compliant way of doing what you want, so
should this be marked INVALID?

Comment 4

[rvj]

Of particular concern is the iframe widget

IE has always had the SCROLLING="NO" attribute for the HTML iframe element and 
I was suprised to find no equivalent in XUL.


1. While I can wait for an XBL solution just to hide the in-built scrollbars of 
both the tree and iframe widget, can someone tell me if I will be able to 
select and issue click events against a particular hidden scrollbar so that I 
can scroll the contents of an iframe up/down and left/right programatically. 
(an example?)

2. If not, can this please can this remain as an RFE? 

Comment 5

[Peter Trudelle]

->evaughan/future/rfe

Comment 6

[Keyser Sose]

Marking NEW to get it off our unconfirmed radar.

Comment 7

[rvj]

PS The Mozilla DOM newsgroups have raised this problem on several occations.

Can anyone clarify if the attribute overflow:none will be implimented for 
iframe and tree widgets in particular ?

This would be a much simpler solution than XBL !!!!!!

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

'overflow' is a property, not an attribute, and it does not take a 'none'
value.  You probably mean 'hidden'.

Comment 9

[rvj]

apologies  - although the same basic questions remain

a) Should/will this method of hiding scrollbars work with all widgets and what 
milestone will it available?

b) Will it be possible to programatically control the scrolling of such widgets 
by using the  createEvent method to enter keyboard up/down/left/right/page 
up/page down keys (or is there an even simpler  method)


Thanks

Comment 10

[rvj]

A related issue is a need to distinguish between XUL widgets and HTML widgets.

As an alternative approach, I tried to suppress all XUL scrollbars by 
defining ' scrollbar visibility:collapse} ' in XUL.CSS

Unfortunately cascading  applies this to the scrollbars within any subordinate 
html documents.

Surely some scoping should be possible or a separate mechanism for applying 
styling to just XUL widgets.

One idea that was suggested by D. Hyatt was a XUL class attribute(s) for each 
widget so that it would be possible to define XUL CSS selectors. For example

.iframescrollbar {visibility:collapse} 
.treescrollbar {visibility:visible;width:30px;background-color:red}


A typical requirement is the need to supress the scrollbars on a web cam image 
(iframe+image). The XUL application will provide the panning controls 
up/down/left/right to control what appears in the iframe.

Comment 11

[rvj]

Ok I think this pre-XBL request is no longer valid. Most of my concerns are 
handled by xbl. Marking invalid.

Comment 12

[Daniel Wang]

*** Bug 107495 has been marked as a duplicate of this bug. ***