Gadget scrolling, content manangement responsibility; stronger spec language.

[Dan Dumont <dd...@us.ibm.com>]

<cross posting to the shindig dev and spec lists>

I've been looking at the UX of gadgets in various containers now and I've 
come across one pretty fundamental issue that is not clarified well enough 
in the spec, and as a result will lead to poor portability across 
containers.  So I'd like to get some feedback here to see if we can 
address it in the spec and add some stuff to shindig to make things a bit 
easier for gadget devs.

The issue is scrolling.  Who owns the task of scrolling content of a large 
gadget?  I would argue that the gadget should.
There are features for gadgets to request height and width changes. But if 
the container doesn't want the gadget to grow or change height, the gadget 
should be able to cope well by being able to detect how large it is and 
scroll if necessary.

I've seen some containers let the iframe grow as big as it needs to 
(default impl in shindig) with dynamic-height.  They set scrolling: auto 
on the site element and the container allows the iframe to be scrolled. 
The problem in this case is the gadget thinks it's actually as big as it 
wants to be instead of its true viewable size.  This could lead to some 
nasty UX issues.

I also think that in some situations, improper scroll management could 
lead to problems with scrollBy and other properties of the gadget window 
not working as expected.

So I propose that we:
State clearly in the gadget spec that content overflow should be managed 
by the gadget.
Leave overflow=no in the iframe construction for the common container
Advise container implementers that they should not hide allow sites to 
overflow in the container, but rather constrain their size to what is 
visible.
Include some simple styles in the gadget rewrite to allow the content of 
gadgets to scroll their overflow by default:

As for 4, we can use either inline styles or an injected css template by 
default in shindig to include the following:
html, body {
                height: 100%;
                width: 100%;
                overflow: auto;
        }

Which, in my testing, has allowed gadgets to scroll when their content 
exceeds the available display area of an iframe having scrolling="no" and 
sized to fit within its container.

Any thoughts/objections?

Re: Gadget scrolling, content manangement responsibility; stronger spec language.

[Ryan J Baxter <rj...@us.ibm.com>]

Dan I think this sounds reasonable.





From:   Dan Dumont/Westford/IBM@Lotus
To:     dev@shindig.apache.org, 
Date:   05/02/2012 04:15 PM
Subject:        Re: Gadget scrolling, content manangement responsibility; 
stronger spec language.



The shindig change I'm proposing is here: 
https://reviews.apache.org/r/4973/ 



From:   Dan Dumont/Westford/IBM@Lotus
To:     dev@shindig.apache.org, 
Date:   05/02/2012 03:37 PM
Subject:        Gadget scrolling, content manangement responsibility; 
stronger spec language.



<cross posting to the shindig dev and spec lists>

I've been looking at the UX of gadgets in various containers now and I've 
come across one pretty fundamental issue that is not clarified well enough 


in the spec, and as a result will lead to poor portability across 
containers.  So I'd like to get some feedback here to see if we can 
address it in the spec and add some stuff to shindig to make things a bit 
easier for gadget devs.

The issue is scrolling.  Who owns the task of scrolling content of a large 


gadget?  I would argue that the gadget should.
There are features for gadgets to request height and width changes. But if 


the container doesn't want the gadget to grow or change height, the gadget 


should be able to cope well by being able to detect how large it is and 
scroll if necessary.

I've seen some containers let the iframe grow as big as it needs to 
(default impl in shindig) with dynamic-height.  They set scrolling: auto 
on the site element and the container allows the iframe to be scrolled. 
The problem in this case is the gadget thinks it's actually as big as it 
wants to be instead of its true viewable size.  This could lead to some 
nasty UX issues.

I also think that in some situations, improper scroll management could 
lead to problems with scrollBy and other properties of the gadget window 
not working as expected.

So I propose that we:
State clearly in the gadget spec that content overflow should be managed 
by the gadget.
Leave overflow=no in the iframe construction for the common container
Advise container implementers that they should not hide allow sites to 
overflow in the container, but rather constrain their size to what is 
visible.
Include some simple styles in the gadget rewrite to allow the content of 
gadgets to scroll their overflow by default:

As for 4, we can use either inline styles or an injected css template by 
default in shindig to include the following:
html, body {
                height: 100%;
                width: 100%;
                overflow: auto;
        }

Which, in my testing, has allowed gadgets to scroll when their content 
exceeds the available display area of an iframe having scrolling="no" and 
sized to fit within its container.

Any thoughts/objections?

Re: Gadget scrolling, content manangement responsibility; stronger spec language.

[Dan Dumont <dd...@us.ibm.com>]

The shindig change I'm proposing is here: 
https://reviews.apache.org/r/4973/ 



From:   Dan Dumont/Westford/IBM@Lotus
To:     dev@shindig.apache.org, 
Date:   05/02/2012 03:37 PM
Subject:        Gadget scrolling, content manangement responsibility; 
stronger spec language.



<cross posting to the shindig dev and spec lists>

I've been looking at the UX of gadgets in various containers now and I've 
come across one pretty fundamental issue that is not clarified well enough 

in the spec, and as a result will lead to poor portability across 
containers.  So I'd like to get some feedback here to see if we can 
address it in the spec and add some stuff to shindig to make things a bit 
easier for gadget devs.

The issue is scrolling.  Who owns the task of scrolling content of a large 

gadget?  I would argue that the gadget should.
There are features for gadgets to request height and width changes. But if 

the container doesn't want the gadget to grow or change height, the gadget 

should be able to cope well by being able to detect how large it is and 
scroll if necessary.

I've seen some containers let the iframe grow as big as it needs to 
(default impl in shindig) with dynamic-height.  They set scrolling: auto 
on the site element and the container allows the iframe to be scrolled. 
The problem in this case is the gadget thinks it's actually as big as it 
wants to be instead of its true viewable size.  This could lead to some 
nasty UX issues.

I also think that in some situations, improper scroll management could 
lead to problems with scrollBy and other properties of the gadget window 
not working as expected.

So I propose that we:
State clearly in the gadget spec that content overflow should be managed 
by the gadget.
Leave overflow=no in the iframe construction for the common container
Advise container implementers that they should not hide allow sites to 
overflow in the container, but rather constrain their size to what is 
visible.
Include some simple styles in the gadget rewrite to allow the content of 
gadgets to scroll their overflow by default:

As for 4, we can use either inline styles or an injected css template by 
default in shindig to include the following:
html, body {
                height: 100%;
                width: 100%;
                overflow: auto;
        }

Which, in my testing, has allowed gadgets to scroll when their content 
exceeds the available display area of an iframe having scrolling="no" and 
sized to fit within its container.

Any thoughts/objections?