My second question of the day - I have a div that i want to be hidden untill an onclick event makes it appear (Grow). using body onload Shrink works but then i see the shrink effect when the pageloads. if i put display:none on the div in the stylesheet then the Grow effect does not work. what''s the best way to make a div hidden by default? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~----------~----~----~----~------~----~------~--~---
The one and only way to pre-hide stuff with Prototype and therefore script.aculo.us is a small sin: use inline style="display: none" on your element''s HTML. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~----------~----~----~----~------~----~------~--~---
thanks, that worked great i guess its impossible to avoid inline styles? doing this with an event handler would require us to wait for the page to finish loading? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~----------~----~----~----~------~----~------~--~---
with the DOMReady extension (
http://agileweb.org/articles/2006/07/28/onload-final-update) its quite fast
do stuff like that:
Event.observe(window, ''load'', function(){
$(''element_xyz'').hide();
});
hth
On 9/1/06, stef <stefankendrew-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:>
>
> thanks, that worked great
>
> i guess its impossible to avoid inline styles? doing this with an event
> handler would require us to wait for the page to finish loading?
>
>
> >
>
--
Siegfried Puchbauer
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs
-~----------~----~----~----~------~----~------~--~---
This is the only case I know of that requires inline styles. All other Prototype/s.a.u.-related style manipulations do not need a predefined inline-originating value. On the event handler side, you''re correct in an unobstrusive JS context (the only one worth using!). This is due to the combination of the following issues: 1. Unobstrusive JS mandates code being in another file. 2. The link to this file should be done using script tags *in the head*; putting some in the body is technically allowed, but frowned upon. 3. This other file will parse & execute at load time, which is when the script tag is found, which is before the rest of the document (and the body) is parsed; therefore, the DOM is mostly empty at this point. Hence, you would have to resort to page load completion. Which is a bother for pre-hiding. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~----------~----~----~----~------~----~------~--~---
I didn''t know of this ext, that''s cool. But I would prefer to see it in the Prototype SVN for later releases, than as a separate hack. Also, the code it uses relies on quite a few browser-based dependencies, therefore it speeds things up, but *not always*, which might be an issue. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~----------~----~----~----~------~----~------~--~---
The one and only way to pre-hide stuff with Prototype and therefore
script.aculo.us is a small sin: use inline style="display: none" on
your element''s HTML.
--------------------------------------
I discovered this by trial-and-error myself, but I never took it so far as to
understand *why* hiding a div with a class doesn''t
work with Effect.Grow.
Anyone know?
Sam
.hide {display:none}
<div class=".hide">... Whatever</div>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs
-~----------~----~----~----~------~----~------~--~---
Chris, Why don''t you read the original article here: http://dean.edwards.name/weblog/2006/06/again/ It''s been tested to death & it actually works. It''s now even part of the Dojo library (core). Thanks, Mandy. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~----------~----~----~----~------~----~------~--~---
I doubt about an integration in the svn ... The browser based thing: I think there is an implementation for all common browers. So it should speed up things in most cases. On 9/1/06, Christophe Porteneuve <tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org> wrote:> > > I didn''t know of this ext, that''s cool. > > But I would prefer to see it in the Prototype SVN for later releases, > than as a separate hack. > > Also, the code it uses relies on quite a few browser-based > dependencies, therefore it speeds things up, but *not always*, which > might be an issue. > > > > >-- Siegfried Puchbauer --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~----------~----~----~----~------~----~------~--~---
On Sep 1, 2006, at 7:51 AM, Sam wrote:> > The one and only way to pre-hide stuff with Prototype and therefore > script.aculo.us is a small sin: use inline style="display: none" on > your element''s HTML. > -------------------------------------- > I discovered this by trial-and-error myself, but I never took it so > far as to understand *why* hiding a div with a class doesn''t > work with Effect.Grow. > > Anyone know? > > Sam > > .hide {display:none} > > <div class=".hide">... Whatever</div> >Here''s my understanding of how this works: Element.show() (which Effect.Grow uses) works by dynamically setting the "display" property to '''' (the empty string). It does this because it has no way of knowing whether your original element was block, inline, inline-block, list-item, or whatever. With an inline style, this will overwrite your "display: none" and show the element. However, if there is a rule in an attached stylesheet that provides a definition for "display" that is more specific than '''', it will be used. Keep in mind that this has nothing to do with CSS inheritance or specificity: the JS-applied style has higher specificity than the CSS rule from the external file anyway. It has to do with the fact that '''' is not a valid value for the display attribute, but is kind of interpreted as "default". Therefore, Element.hide() (which sets display to "none") should have no such restrictions. JS and CSS gurus, feel free to correct my semi-technical explanation here :-) --be
Sorry, I have nothing to add to this thread... just curious, Brad, about the smime.p7s attachment in your reply. What is that? On 9/1/06, Brad Ediger <brad-sod+mMc99o6+XT7JhA+gdA@public.gmane.org> wrote:> > On Sep 1, 2006, at 7:51 AM, Sam wrote: > > > > > The one and only way to pre-hide stuff with Prototype and therefore > > script.aculo.us is a small sin: use inline style="display: none" on > > your element''s HTML. > > -------------------------------------- > > I discovered this by trial-and-error myself, but I never took it so > > far as to understand *why* hiding a div with a class doesn''t > > work with Effect.Grow. > > > > Anyone know? > > > > Sam > > > > .hide {display:none} > > > > <div class=".hide">... Whatever</div> > > > > Here''s my understanding of how this works: > > Element.show() (which Effect.Grow uses) works by dynamically setting > the "display" property to '''' (the empty string). It does this because > it has no way of knowing whether your original element was block, > inline, inline-block, list-item, or whatever. > > With an inline style, this will overwrite your "display: none" and > show the element. However, if there is a rule in an attached > stylesheet that provides a definition for "display" that is more > specific than '''', it will be used. > > Keep in mind that this has nothing to do with CSS inheritance or > specificity: the JS-applied style has higher specificity than the CSS > rule from the external file anyway. It has to do with the fact that > '''' is not a valid value for the display attribute, but is kind of > interpreted as "default". > > Therefore, Element.hide() (which sets display to "none") should have > no such restrictions. > > JS and CSS gurus, feel free to correct my semi-technical explanation > here :-) > > --be > >-- Ryan Gahl Application Development Consultant Athena Group, Inc. Inquire: 1-888-919-8700 x2903 Blog: http://www.someElement.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~----------~----~----~----~------~----~------~--~---
From my experience, .show directly changes the display style to be empty for the element and it then inherits the style from the style sheet. So what I''ve done and would suggest is setting the style on the individual element to display=''none'' that way when show is called it changes the display of that element to empty and can then inherit the style from the style sheet which can be set to empty or block. -Steven On 9/1/06, stef <stefankendrew-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > My second question of the day - I have a div that i want to be hidden > untill an onclick event makes it appear (Grow). using body onload > Shrink works but then i see the shrink effect when the pageloads. if i > put display:none on the div in the stylesheet then the Grow effect does > not work. > > what''s the best way to make a div hidden by default? > > > > >-- Steven Osborn osborn.steven-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~----------~----~----~----~------~----~------~--~---
Just a friendly old digital signature. On Sep 1, 2006, at 9:05 AM, Ryan Gahl wrote:> Sorry, I have nothing to add to this thread... just curious, Brad, > about the smime.p7s attachment in your reply. What is that? > > On 9/1/06, Brad Ediger < brad-sod+mMc99o6+XT7JhA+gdA@public.gmane.org> wrote: > On Sep 1, 2006, at 7:51 AM, Sam wrote: > > > > > The one and only way to pre-hide stuff with Prototype and therefore > > script.aculo.us is a small sin: use inline style="display: none" on > > your element''s HTML. > > -------------------------------------- > > I discovered this by trial-and-error myself, but I never took it so > > far as to understand *why* hiding a div with a class doesn''t > > work with Effect.Grow . > > > > Anyone know? > > > > Sam > > > > .hide {display:none} > > > > <div class=".hide">... Whatever</div> > > > > Here''s my understanding of how this works: > > Element.show() (which Effect.Grow uses) works by dynamically setting > the "display" property to '''' (the empty string). It does this because > it has no way of knowing whether your original element was block, > inline, inline-block, list-item, or whatever. > > With an inline style, this will overwrite your "display: none" and > show the element. However, if there is a rule in an attached > stylesheet that provides a definition for "display" that is more > specific than '''', it will be used. > > Keep in mind that this has nothing to do with CSS inheritance or > specificity: the JS-applied style has higher specificity than the CSS > rule from the external file anyway. It has to do with the fact that > '''' is not a valid value for the display attribute, but is kind of > interpreted as "default". > > Therefore, Element.hide() (which sets display to "none") should have > no such restrictions. > > JS and CSS gurus, feel free to correct my semi-technical explanation > here :-) > > --be > > > > > -- > Ryan Gahl > Application Development Consultant > Athena Group, Inc. > Inquire: 1-888-919-8700 x2903 > Blog: http://www.someElement.com > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google > Groups "Ruby on Rails: Spinoffs" group. > To post to this group, send email to rubyonrails- > spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org > To unsubscribe from this group, send email to rubyonrails-spinoffs- > unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org > For more options, visit this group at http://groups.google.com/ > group/rubyonrails-spinoffs > -~----------~----~----~----~------~----~------~--~--- >
Thanks, Brad :-) After my post I *gasp* googled (oops, Googled) it on my own (novel concept huh?)... heh. (again, sorry I semi-hijacked the thread for a minute... I''m done now) On 9/1/06, Brad Ediger <brad-sod+mMc99o6+XT7JhA+gdA@public.gmane.org> wrote:> > Just a friendly old digital signature. > > On Sep 1, 2006, at 9:05 AM, Ryan Gahl wrote: > > Sorry, I have nothing to add to this thread... just curious, Brad, about > the smime.p7s attachment in your reply. What is that? > > On 9/1/06, Brad Ediger < brad-sod+mMc99o6+XT7JhA+gdA@public.gmane.org> wrote: > > > > On Sep 1, 2006, at 7:51 AM, Sam wrote: > > > > > > > > The one and only way to pre-hide stuff with Prototype and therefore > > > script.aculo.us is a small sin: use inline style="display: none" on > > > your element''s HTML. > > > -------------------------------------- > > > I discovered this by trial-and-error myself, but I never took it so > > > far as to understand *why* hiding a div with a class doesn''t > > > work with Effect.Grow . > > > > > > Anyone know? > > > > > > Sam > > > > > > .hide {display:none} > > > > > > <div class=".hide">... Whatever</div> > > > > > > > Here''s my understanding of how this works: > > > > Element.show() (which Effect.Grow uses) works by dynamically setting > > the "display" property to '''' (the empty string). It does this because > > it has no way of knowing whether your original element was block, > > inline, inline-block, list-item, or whatever. > > > > With an inline style, this will overwrite your "display: none" and > > show the element. However, if there is a rule in an attached > > stylesheet that provides a definition for "display" that is more > > specific than '''', it will be used. > > > > Keep in mind that this has nothing to do with CSS inheritance or > > specificity: the JS-applied style has higher specificity than the CSS > > rule from the external file anyway. It has to do with the fact that > > '''' is not a valid value for the display attribute, but is kind of > > interpreted as "default". > > > > Therefore, Element.hide() (which sets display to "none") should have > > no such restrictions. > > > > JS and CSS gurus, feel free to correct my semi-technical explanation > > here :-) > > > > --be > > > > > > > -- > Ryan Gahl > Application Development Consultant > Athena Group, Inc. > Inquire: 1-888-919-8700 x2903 > Blog: http://www.someElement.com > > > > >-- Ryan Gahl Application Development Consultant Athena Group, Inc. Inquire: 1-888-919-8700 x2903 Blog: http://www.someElement.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~----------~----~----~----~------~----~------~--~---
Sam, Steven, Ryan: Your understanding is correct. A few precisions though: - Using element.style in JS is strictly equivalent to working on the inline HTML element, which DOES have something to do with selector specificity, as defined by the CSS spec. In short, the inline style, and therefore the script-exposed style object, have the ultimate specificity. They override anything. - Resetting any property of the style object to the empty string makes it irrelevant, which is the normative behavior as per DOM Level 2 Style (CSSStyleDeclaration interface). - Prototype''s approach to display is to not back its value for later restoration (opposite to what it does with a couple other properties, such as overflow or position). It just overrides it with ''none'' to hide, and stops overriding it to show. Any effect relying on Element.show, Element.hide and Element.toggle "inherits" this behavior. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~----------~----~----~----~------~----~------~--~---
Thanks for the link. I wonder why Sam won''t add those hooks in Prototype''s Event.observe. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~----------~----~----~----~------~----~------~--~---
Great, thank you for the clarification. On Sep 1, 2006, at 9:41 AM, Christophe Porteneuve wrote:> > Sam, Steven, Ryan: > > Your understanding is correct. A few precisions though: > > - Using element.style in JS is strictly equivalent to working on the > inline HTML element, which DOES have something to do with selector > specificity, as defined by the CSS spec. In short, the inline style, > and therefore the script-exposed style object, have the ultimate > specificity. They override anything. > > - Resetting any property of the style object to the empty string makes > it irrelevant, which is the normative behavior as per DOM Level 2 > Style > (CSSStyleDeclaration interface). > > - Prototype''s approach to display is to not back its value for later > restoration (opposite to what it does with a couple other properties, > such as overflow or position). It just overrides it with ''none'' to > hide, and stops overriding it to show. Any effect relying on > Element.show, Element.hide and Element.toggle "inherits" this > behavior. > > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google > Groups "Ruby on Rails: Spinoffs" group. > To post to this group, send email to rubyonrails- > spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org > To unsubscribe from this group, send email to rubyonrails-spinoffs- > unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org > For more options, visit this group at http://groups.google.com/ > group/rubyonrails-spinoffs > -~----------~----~----~----~------~----~------~--~--- >
As I understand it: get and set style are not symmetrical because of CSS
cascaded inheritance:
"get" will return the cascaded style which starts with the HTML
element property, may be overridden by the CSS directive, which may
be overridden by coding style="whatever" in the HTML. getStyle will
return whichever property cascaded down to dominate. It would
be difficult to determine in JavaScript where the style declaration came from,
but if it were known, it might solve the upcoming
problem.
OK, we''ve got the style but we don''t know from whence it came.
Now after overwriting the element "style" doing an effect, we would
like to "set" things back. There''s the problem...
Without the ability to undo the setStyle, using setStyle( {display:
''''} ) is a partial solution.
Each of these 3 divs will end up with different results when an effect
"restores" the display style state using setStyle( {display:
''''} )
<div style="display:none">abc</div>
<div style="display:block">abc</div>
<div style="display:inline">abc</div>
Wouldn''t it be possible to save the original style in a stack so the
element style could be restored to it''s original state?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs
-~----------~----~----~----~------~----~------~--~---
On Sep 1, 2006, at 1:40 PM, Sam wrote:> > > As I understand it: get and set style are not symmetrical because > of CSS cascaded inheritance: > > "get" will return the cascaded style which starts with the HTML > element property, may be overridden by the CSS directive, which may > be overridden by coding style="whatever" in the HTML. getStyle > will return whichever property cascaded down to dominate. It would > be difficult to determine in JavaScript where the style declaration > came from, but if it were known, it might solve the upcoming > problem. > > OK, we''ve got the style but we don''t know from whence it came. Now > after overwriting the element "style" doing an effect, we would > like to "set" things back. There''s the problem... > > Without the ability to undo the setStyle, using setStyle( {display: > ''''} ) is a partial solution. > > Each of these 3 divs will end up with different results when an > effect "restores" the display style state using setStyle( {display: > ''''} ) > > <div style="display:none">abc</div> > <div style="display:block">abc</div> > <div style="display:inline">abc</div> > > > Wouldn''t it be possible to save the original style in a stack so > the element style could be restored to it''s original state? >Not sure about this but I imagine you would run into inheritance / specificity problems again if the original styles came from anywhere other than inline. Your example wouldn''t have this problem, but here''s one that would. Consider an external stylesheet with a single class selector applying the display property you want (it would have a specificity of 0010). Even if Prototype stored the original state in a stack, when it set it back it would take precedence over most other styles (since JS- applied styles are equivalent to inline styles with a specificity of 1000). So you wouldn''t be back to normal -- instead of having a CSS- file rule with a specificity of 0010, you have an inline rule saying the same thing with a specificity of 1000. This would take precedence over, say, an external CSS rule with an ID selector, which would have a specificity of 0100. Bottom line: you could probably end up having different behavior before and after the restore. My guess is that that would be too leaky of an abstraction for Prototype. --be
I know this maybe got done to death already, but I didnt see a
definitive answer. I''m not sure if this is one either, but its more
food
for thought.
IIRC Prototype''s hide() sets style.display to none, and show() sets it
to ''''. The empty string then allows any display property in a
class to
apply. So if your stylesheet specifies .someElement { display: none; },
$(''elm'').show() wont actually work.
The reason show() sets display to the empty string instead of
''block''
for example, is that block isn''t the right value for lots of elements
(inline elements, table rows etc). So a "better" approach might be to
check the currentStyle/calculatedStyle objects where the *actual*
display property is available (once all the various inheritance has been
resolved at rendertime), and remember before setting to
''none'', and
restore that value later, when you call show();
This would likely be slower, and the added complexity would surely trip
someone up somewhere. On the other hand, that''s why we have libraries -
to solve these kinds of problems for us - so it might be worth
exploration. I ran into this about this time last year though, so surely
its been explored more since then?
(yet another) Sam
Sam wrote:
>The one and only way to pre-hide stuff with Prototype and therefore
>script.aculo.us is a small sin: use inline style="display: none"
on
>your element''s HTML.
>--------------------------------------
>I discovered this by trial-and-error myself, but I never took it so far as
to understand *why* hiding a div with a class doesn''t
>work with Effect.Grow.
>
>Anyone know?
>
>Sam
>
>.hide {display:none}
>
><div class=".hide">... Whatever</div>
>
>
>
>
>>
>
>
>
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs
-~----------~----~----~----~------~----~------~--~---
This doesn''t help if you do display:none in external CSS. This overrides the default setting of the element, and you''ve no clue afterwards if it should be "block", "inline", etc. CSS should provide a general "render or render not" switch, but doesn''t. :( -Thomas Am 06.09.2006 um 15:42 schrieb Sam Foster:> > I know this maybe got done to death already, but I didnt see a > definitive answer. I''m not sure if this is one either, but its more > food > for thought. > IIRC Prototype''s hide() sets style.display to none, and show() sets it > to ''''. The empty string then allows any display property in a > class to > apply. So if your stylesheet specifies .someElement { display: > none; }, > $(''elm'').show() wont actually work. > The reason show() sets display to the empty string instead of ''block'' > for example, is that block isn''t the right value for lots of elements > (inline elements, table rows etc). So a "better" approach might be to > check the currentStyle/calculatedStyle objects where the *actual* > display property is available (once all the various inheritance has > been > resolved at rendertime), and remember before setting to ''none'', and > restore that value later, when you call show(); > > This would likely be slower, and the added complexity would surely > trip > someone up somewhere. On the other hand, that''s why we have > libraries - > to solve these kinds of problems for us - so it might be worth > exploration. I ran into this about this time last year though, so > surely > its been explored more since then? > > (yet another) Sam > > Sam wrote: > >> The one and only way to pre-hide stuff with Prototype and therefore >> script.aculo.us is a small sin: use inline style="display: none" on >> your element''s HTML. >> -------------------------------------- >> I discovered this by trial-and-error myself, but I never took it >> so far as to understand *why* hiding a div with a class doesn''t >> work with Effect.Grow. >> >> Anyone know? >> >> Sam >> >> .hide {display:none} >> >> <div class=".hide">... Whatever</div> >> >> >> >> >>> >> >> >> >> >> > > > >-- Thomas Fuchs wollzelle http://www.wollzelle.com questentier on AIM madrobby on irc.freenode.net http://www.fluxiom.com :: online digital asset management http://script.aculo.us :: Web 2.0 JavaScript http://mir.aculo.us :: Where no web developer has gone before --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~----------~----~----~----~------~----~------~--~---
Thomas Fuchs wrote:>This doesn''t help if you do display:none in external CSS. This overrides >the default setting of the element, and you''ve no clue afterwards if it >should be "block", "inline", etc. > >CSS should provide a general "render or render not" switch, but >doesn''t. :( > >Ugh. right. For kicks (and tangentially as it turns out), I went looking at what the browser differences were on those default display values. I''ve got a test page at: http://www.sam-i-am.com/work/sandbox/css/display/html4.html And xls / csv in: http://www.sam-i-am.com/work/sandbox/css/display/ There''s FF1.5, IE6 and Opera 9 in there so far. I''ll be able to check IE7 at work, Safari too maybe. (The wild-card here is does it matter if its quirks/standards mode? I''d suspect maybe. There''s a xhtml.html test page in there too if anyone''s interested.) But, like you say, you could have a stylesheet like: h1 { display: inline } and markup: <h1 style="display: none"> .. where the expected behavior if I was toggling show/hide on this h1 would be that it would be inline when showing. But without looking through all the style rules, all I know when the page loads is that its display: none, so by my own reasoning i''d have to guess at ''block'' as the showing value. Wrong. It still makes sense to check Element.getStyle(elm, ''display'') though, instead of just looking at elm.style.display? Sam (-i-am) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~----------~----~----~----~------~----~------~--~---