Talk:ShowHide/Archive 2

I've got a problem. This [hide] for Episodes should be on the right. Also adding style="background:#ACF", makes the [hide] disappear. &mdash; Balistic 19:02, September 5, 2009 (UTC)
 * That's due to the way you are marking up that template. JS and CSS can't do anything if you use bad markup. Instead of (which is a deprecated html tag) use . Also put the header on the same line as the div start/end tags, putting it on it's own like causes an extra   tag to be created which similarly forces a break. ~ NOTASTAFF Dantman(Local Talk &#8285; Animanga Talk)

Should NavPic be enabled ... or discarded
Dantman, wrt ShowHide I think the so-called magnify sprite ought to become the "collapseLink" whenever the NavPic class has been used. Currently that sprite is just a redundant link to the image's page in the File: namespace. This is the same href target as for the the image area itself.

What do you think?
 * Is that intuitive?
 * ... complex to implement?
 * ... simple enough to implement?

--najevi 08:50, November 10, 2009 (UTC)
 * That magnify glass only appears when using thumbs what you request could be a restriction for the people that dont use thumb. What i still dont understand is why Dantman is supporting the NavPic class since it got broken the moment the code got copy to en.wikipedia and then the CSS got "improve", the only wiki i have ever seen using this class has been the de.wikipedia where the original code comes --Cizagna (Talk) Central Dofus 23:00, 10 November 2009 (UTC)


 * Yes, I can see your point now. It would be messy to try and treat Thumb images differently within Show/Hide.


 * However, I wonder if the Show/Hide button function might shift to the image area itself. i.e when the reader clicks on the small image it expands the collapsed content. When they click on the large image it collapses the collapsible content. In other words since the image area istelf is the common feature let that assume the function of magnify/shrink in lieue of displaying show/hide buttons.


 * Again this would be enabled only when a div.NavPic element is specified and not when a div.NavFrame element is specified. I suppose that the Magnify sprite could one day be implemented by Wikia engineers and not coexist well with the div.NavPic. Who knows?


 * Otherwise the NavPic class label becomes superfluous baggage. --najevi 11:27, November 11, 2009 (UTC)

NavFrame link
See this 5 lines header and the link at the bottominstead the top right or top left and you can't fix it via CSS because then you are left with some ugly brakets at the end of your header also my header keeps changing size because of the show/hide changes while this is barely noticeable in english in other language this is not the case and can turn in to a very annoying thing --Cizagna (Talk) Central Dofus 09:00, 11 November 2009 (UTC)

I learned something by playing around with your question above! I'll call your multiple line text the "preamble text" rather than header text because I sincerely believe the header text should be outside of the div.NavFrame element. I'll refer to you note about the 'header' changing size the "collapsible content" in my explanation below.

The executive summary is that it is best to:
 * 1) place the header before the div.NavHead and preferably before the div.NavFrame
 * 2) avoid placing any preamble text in between the div.NavHead tags  and
 * 3) instead place it either immediately before or immediately after the first div.NavHead tag

If you play around with your Common.css to float the entire div.NavHead either right or left then you will see that the background color is really only there to draw attention to the Show/Hide button. You will see your preamble text rendered inside a border (due to NavFrame styles) that is obviously associated with both the Show/Hide button as well as the collapsible content.

First we float the Show/Hide buttons right. Of course this would be done in Common.css/Monaco.css/Monobook.css according to your site preference but I'll do it inline for these six examples. div.NavHead { float:right; } div.NavContent { clear:none; } See this 5 lines header and the link at the bottominstead the top right or top left and you can't fix it via CSS because then you are left with some ugly brakets at the end of your header also my header keeps changing size because of the show/hide changes while this is barely noticeable in english in other language this is not the case and can turn in to a very annoying thing
 * 1. Preamble text placed outside the div.Navframe (My old habit)

See this 5 lines header and the link at the bottominstead the top right  or top left and you can't fix it via CSS because then you are left with some ugly brakets at the end of your header also my header keeps changing size because of the show/hide changes while this is barely noticeable in english in other language this is not the case and can turn in to a very annoying thing
 * 2. Preamble is immediately before the div.Navhead

See this 5 lines header and the link at the bottominstead the top right or top left and you can't fix it via CSS because then you are left with some ugly brakets at the end of your header also my header keeps changing size because of the show/hide changes while this is barely noticeable in english in other language this is not the case and can turn in to a very annoying thing
 * 3. Preamble is immediately after the div.Navhead

Now we float the buttons left instead. It looks ugly if we don't clear:both before the collapsible content is displayed. div.NavHead { float:left; } div.NavContent { clear:both; } See this 5 lines header and the link at the bottominstead the top right or top left and you can't fix it via CSS because then you are left with some ugly brakets at the end of your header also my header keeps changing size because of the show/hide changes while this is barely noticeable in english in other language this is not the case and can turn in to a very annoying thing
 * 4. Preamble text placed outside the div.Navframe (My old habit)

See this 5 lines header and the link at the bottominstead the top right  or top left and you can't fix it via CSS because then you are left with some ugly brakets at the end of your header also my header keeps changing size because of the show/hide changes while this is barely noticeable in english in other language this is not the case and can turn in to a very annoying thing
 * 5. Preamble is immediately before the div.Navhead

See this 5 lines header and the link at the bottominstead the top right or top left and you can't fix it via CSS because then you are left with some ugly brakets at the end of your header also my header keeps changing size because of the show/hide changes while this is barely noticeable in english in other language this is not the case and can turn in to a very annoying thing
 * 6. Preamble is immediately after the div.Navhead

There you have it! Of the six examples the only one that I really don't like at all is #6. I think I might prefer #3 but then I suspect that could ask 12 people and get at least 5 different responses! Sorry I could not be any more helpful than that! --najevi 11:04, November 11, 2009 (UTC)
 * This alternatives are clever yet the issues are still there... and even more,
 * Test
 * Test
 * If i could tolerate this off-center effect then I would be using tables instead of divs and as said before it will keep changing making it noticeable depending on how long is each word on different languages.


 * Also doing this alternative way requires to go and create new way of coding for styles and HTML making it more complex to use and for me to go and apply them to every single div using navframe on the wikis I'm in charge (where im the only active sysop) is simply insane. So in my personal case, I prefer not to update my older version and if im force to i prefer not to use hide/show at all until the navframe bug is resolve. Hence why im asking for it to be corrected --Cizagna (Talk) Central Dofus 23:21, 11 November 2009 (UTC)

I am sorry! I had misunderstood your intent with the centered block of text in the earlier example. I did not think a header would ever be so many lines so assumed it was only preamble text. Since you are determined to make all text in the entire NavFrame container centered (I can only imagine you are presenting poetry or song lyrics or images in the NavContent container) then the best idea I can come up with is to also center align the ShowHide button.

You could place that above or below the Title as shown below. If the full width colored background is undesirable then you could set background:none inside NavHeader

Personally I would not use text-align-center across the entire NavFrame container for an article but I realize that you may have special requirements for your articles.

Test Test
 * 1 fix

Test Test
 * 2 fix alternative

Test Test
 * 3 fix alternative clean up

Going back to your original example with a new understanding of your goal, I think that the workaround is very simple.

See this 5 lines header and the link at the bottominstead the top right or top left and you can't fix it via CSS because then you are left with some ugly brakets at the end of your header also my header keeps changing size because of the show/hide changes while this is barely noticeable in english in other language this is not the case and can turn in to a very annoying thing
 * 4 original - fix with

or

See this 5 lines header and the link at the bottominstead the top right or top left and you can't fix it via CSS because then you are left with some ugly brakets at the end of your header also my header keeps changing size because of the show/hide changes while this is barely noticeable in english in other language this is not the case and can turn in to a very annoying thing
 * 5 original - fix with clr

or perhaps

See this 5 lines header and the link at the bottominstead the top right or top left and you can't fix it via CSS because then you are left with some ugly brakets at the end of your header also my header keeps changing size because of the show/hide changes while this is barely noticeable in english in other language this is not the case and can turn in to a very annoying thing
 * 6 original - fix with centered title in it's own div (button top-right)

and finally

See this 5 lines header and the link at the bottominstead the top right or top left and you can't fix it via CSS because then you are left with some ugly brakets at the end of your header also my header keeps changing size because of the show/hide changes while this is barely noticeable in english in other language this is not the case and can turn in to a very annoying thing
 * 7 original - fix with centered title in it's own div (button bottom-right)

Where there's a will there's a way! --najevi 03:47, November 13, 2009 (UTC)
 * As i said before for me its to much time consuming if i have to go and edit every single navframe that exists in the various wikis im the only active admin with no steady user/community who can really help me. Also as you may know im a helper in charge of the spanish community so the time i have available to attend my wikis is very short most of the time patrol so unless i devote a couple of months finding and updating navframes this is simply not achievable if i still need to edit every single navframe, hence why my request for fixing by simply wrapping the link and adjusting editing the CSS since i dont know jquery i would do my changes in a separate version. Also this situation applies also for other wikis where i can inform/suggest this JS but are on similar situation where they have to update every single navfram as that discouraging for them (as spanish wikis the communities are less participating that english ones) to change if they have to do so much work and will say "if its not broken, and we have to do so much... why change it?".
 * And as a separate note by doing this change your request below title "Beautiful buttons !" will be easier doing it via css as you can hide the braces using with  and telling to color the   plus rest of stuff --Cizagna (Talk) Central Dofus 17:32, 13 November 2009 (UTC)

A derivative of Dan's script
At w:c:test-najevi:ShowHide_usage/jQ-najevi-v2.js you'll find a derivative that addresses two issues raised above:
 * 1) The non-essential wrapping of the user specified button labels in square brackets
 * 2) * the default strings now include those square brackets explicitly and the user is free to change the default using the message feature provided for that
 * 3) The span.collapseLink element is now prepended inside the div.NavHead container.
 * 4) * I am fairly certain this is what Cizagna was asking for. (It biases the placement of the button to be above the heading text when the heading runs to multiple lines and that is really a matter of personal preference I guess.)

Just tweak your monaco.js as folows: importScriptPage('ShowHide usage/jQ-najevi-v2.js', 'test-najevi'); /* importScriptPage('ShowHide usage/jQ-najevi-v1.js', 'test-najevi'); importScriptPage('ShowHide/code.js', 'dev');

-- najevi 08:34, November 14, 2009 (UTC)

FYI the 2nd point mentioned above is not terribly important to the problem Cizagna was describing. It seems that getting rid of the text node appended to the div.NavHead is all that was really necessary. That text node was only created to contain the square brackets so removing it has not introduced any problems. You can verify this for yourself by importing jQ-najevi-v1.js (see above). -- najevi 09:55, November 14, 2009 (UTC)

Version 3 returns CSS styling power to the user
I was not satisfied with v2 (described above) because I realized that the fundamental problem was that the heading and the toggle button are sharing the same div.NavHead container. (This is at the heart of Cizagna's issue.)

Therefore, in version 3 what I have done is
 * 1) revived the use of div.NavToggle as the container for the toggle button
 * 2) and inserted that container after div.NavHead
 * 3) * this effectively makes the heading and the button separate. CSS can now be used to style/align one independently of the other.
 * 4) I found it necessary/expedient to add div.NavClear which was inserted immediately after div.NavToggle
 * 5) * it's sole purpose is to allow the user who wants to center-align the toggle button to do so by specifying a clear:both style to "push down" any text that might have been inserted after NavHead but before NavContent.


 * Details
 * http://test-najevi.wikia.com/wiki/ShowHide_usage/jQ-najevi-v3.js
 * demonstration and test pages
 * you must use  inside your personal monaco.js (see w:c:test-najevi:User:najevi/monaco..js) because I intentionally do not specify the source code at MediaWiki:Common.js
 * you must copy w:c:test-najevi:User:najevi/monaco.css to your own personal monaco.css - once again because I am keeping that test wiki free of any site-wide CSS (and JS) that might affect what you see when you experiment with the test pages.
 * w:c:test-najevi:ShowHide_usage
 * w:c:test-najevi:ShowHide_usage/Test_cases

Daniel, I did not understand why the tag might be used in a NavFrame. Therefore I left that line of code untouched. I do not have a test case to verify handling of a legend tag.


 * After a short break I plan to see if I can further extend Dan's code to implement my idea for "magnify/shrink" between a pair of images placed inside the NavPic container.

-- najevi 12:10, November 15, 2009 (UTC)


 * After some working out and streesing me to understand the differences in languages i found the following lines

var $buttonLink = $(' ').text( msg("hide") ) .onLink(function(e) { toggleNavigationBar( $(this).closest('.NavFrame') ); }); var $button = $(' ') $navHead.append( document.createTextNode(config.brackets.substr(0, config.brackets.length/2)), $buttonLink, config.brackets.substr(config.brackets.length/2) );
 * And was astonish that Daniel in fact had partially coded the span but was not actually using it at all, talk about wasting load times. So i add/change this

var $buttonLink = $(' ').text( msg("hide") ) .onLink(function(e) { toggleNavigationBar( $(this).closest('.NavFrame') ); }); var $button = $(' ') $button.append( document.createTextNode(config.brackets.substr(0, config.brackets.length/2)), $buttonLink, document.createTextNode(config.brackets.substr(config.brackets.length/2)) ); $navHead.prepend( $button );
 * For the clever eyes I change also the "append" for "prepend" because thats the way the old navframe handle that and since the documentation does not explain the reason of the change I'm in favor or avoiding compatibility issues unless needed
 * Now that I have something to target and it has a class i can use/add the following CSS

.NavToggle { float:right; position:absolute; top:0px; right:3px; } .NavHead {position:relative;}
 * This will let me handle left, right or center and with the absolute and relative combo it will not interface with the center alignment of the navhead like the old one
 * All this lets me obtain my desired effect of backward compatibility with out having to edit every navframe div already created so it can be adjusted.
 * Any way i will try to check tomorrow your 3 versions im curious to see how they will work and if i will require to edit the divs
 * --Cizagna (Talk) Central Dofus 10:30, 16 November 2009 (UTC)

Beautiful buttons !
var ShowHideConfig = { autoCollapse: 3, userLang: false, en: { show: "[show]", hide: "[hide]", showAll: "[expand all]", hideAll: "[collapse all]" } };
 * 1) Note that the Common.css at this site refers to   when, in fact, the appropriate class label is
 * 2) I think that the square brackets ([...]) should be specified by the user rather than hard coded into the javascript. I realize the backward compatibility aspect of how it is done now. Backwards compatibility can be preserved by letting the default button labels include leading and trailing square brackets. Remember that a user can always customize those strings.

Removing hard coded square brackets from the NavHead DIV will allow a more contemporary button to be styled such as this one: show    without having those square brackets visible at either side: [show ]

.collapseLink { color:#002bb8; border:2px outset lightgrey; background-color:lightgrey; padding:3px 5px; font-weight:bold; }

--najevi 04:31, November 13, 2009 (UTC)


 * Brackets are not part of the link, adding those to the message would put them inside. I added a new brackets config, it takes a string such as "[]", "{}", and splits it up, things like "" will work and it'll split it up into and  . ~ NOTASTAFF Dantman(Local Talk &#8285; Animanga Talk)


 * That's odd, I just tested removing brackets altogether by specifying

 var ShowHideConfig = { brackets: '', };
 * however, the square brackets still appear outside my stylish lightgrey button.


 * What did you think of the NavToggle and NavClear classes for simplifying the styling of the button versus the heading? (see section just above this one) -- najevi 16:42, November 15, 2009 (UTC)