Amber-Talk
This space is for User-contributed commentary and notes. Please include your name and a date along with your comment. Put latest comments at top please.
Resizing edit box
I also found that in edit mode, I could not widen the edit box. However if I pressed the F12 key twice (in and out), I could easily grab the bottom right handle of the edit box and resize it to my taste. I might have discover an Easter Egg! Alex March 16 2023
Odd. You can resize the edit box here. The default is 100% width of the content text. - HansB
Resizing problem
I noticed the following behaviour using the Amber skin: While on a page, hitting F12 to go into Dev mode and then F12 again to step out of it, some elements take all the horizontal space instead of being restrained to the frame. This is especially obvious while in PmWiki edit mode. Is this normal behaviour? Doing a page reload corrects the situation, but it could be annoying at times. Alex - March 14 2023
Thanks for pointing this out, Alex! I hope I got this fixed with the latest update. - HansB
CSS errors and warnings:
Maybe you can have a look to correct the next version of Amber. It is not really critical, just for your information. ;-) Holger March 12, 2020, at 11:21 PM
Discussion
Hi Hans, there is a discussion concerning Amber here: PmWiki.Skins-Talk#scroll. --Petko February 02, 2020, at 05:46 PM
Page shadow
Hi Hans, in desktop view the sidebar hides the #page box shadow. See on this page that the right-edge subtle shadow stops at the breadcrumb and starts again right below the sidebar. Is it intentional?
-- SteP January 05, 2020, at 02:18 PM
>>clear<<
Hi Hans, there is a conflict between >>clear<< and nested divisions, i.e. when I use 'clear' any nested divisions on the wikipage (including GroupFooter and GroupHeader) no longer work. See here (sandbox section).
Frank 2017-11-13 6:40 PM
I wonder if you misunderstood the use of >>....<< markup. Your example uses >>clear<< without closing this div. Plus you cannot nest divs within >>....<< markup, nesting divs only work with (:div...:) markup. In your example you should use the clear class as part of the first div (div-1), i.e. like (:div1 class="frame clear" ... :), that way div-1 will receive the css attribute of clear:both and a floated div above will not float beside div-1. - HansB November 13, 2017, at 12:04 PM
Yes, I'm sorry, you are right, I did not understand it. Now it's all clear, thank you (I have deleted the example).
Frank 2017-11-13 7:59 PM
menu button collides with site title (if sidebar is on the left side)
The button (the three horizontal lines) appears when the page become small. On my website MoerkePortal the sidebar is on the left. Unaestheticly the button then appears in the left upper edge amongst the site title. Is there a possibility to move the button or the site title accordingly?
HansB: in default mode with $AmberConfig['menu'] = 'left'; the header has a left padding, so header text will be clear of the menu icon. Check your css/Main.css file and compare with skins/amber/skin-left.css. Note the various @media conditional rules. Your Main.css file should reflect that. The skin-left.css file has only the rules for the position changes, like padding. You need to make sure your Main.css rules will not override those, otherwise inlcude them again, and add the colour rules. Hope this helps!
VolkerM: I copied the content of skins/amber/skin-left.css into css/Main.css. No effect. I moved the included @media rules to the top of Main.css - above the header entry. No effect. - 2016-10-28
PS: I think your css/Main.css file should work, if you just leave out the padding:....; line. HansB October 27, 2016, at 04:33 PM
VolkerM: I commented out the "padding" line in Main.css. No effect. Thats what I tried first ofcourse. Besides, modifying the "background" entry to change the menu background color did not work. :-( Even worse! My website does not change to the "mobile look" when opened with any of my smartphone browsers (firefox, chrome) no more at all. What am I doing wrong? Have I missunderstood some of your hints? - 2016-10-28
HansB: I don't know if you missed something... To set the header background with a grey gradient, as I see from your css/Main.css file, it should be sufficient to set there (or in css/local.css for a site-wide change) the following, and nothing else for the #header div (no @media rules necessary, as we do not overwrite any left padding values):
#header {
background: #dbdbdb;
background-image:
linear-gradient(to top right,#c0c0c0,#ffffff);
}
PS: any changes to css files may need a forced browser reload, forcing a clearing of cached files. That may explain some problems seeing changes on your mobile device.
VolkerM: Thank you very much again for your support, Hans! The header now moves a little bit to the right to make room for the menu button. ;-) And you are perfectly right regarding the mobile browser's caching. I have to maltreat it quite much to force it to display my page correctly. After all I just entered your header definitions to my /css/Main.css. Unfortunately the background color is still blue (#ffc)...!? - 2016-10-28
HansB: you mean the fold-out side menu (#leftmenu) on mobile devices? See below now, I missed your question before.
change background color of the "mobile" menu
The default background color of the "mobile" menu (the one which is flipped out and off with the menu button mentiones above) is a dark blue. Is there a possibility to change it?
Kind regards!
VolkerM - 2016-10-27
HansB: For this we need a @media screen condition, so it does not apply to the side menu on desktops. Try this, for a darkish grey background (still retaining the white text for menu links):
@media screen and (max-width:54.9em) {
#rightmenu, #leftmenu, #topsearch, #topactions { background-color: #777; }
#leftmenu .selflink { color: #ccc; }
}
I added #rightmenu for standard scenarios, but you are just using #leftmenu with SideBar on the left. I added the selflink class rule, as I see that you are using markup extensions which change links to the page one is on into text, and this was showing black.
VolkerM: The fold-out side menu works pretty well now. Thank you very much for your support, Hans! - 2016-10-30
Hello Hans!
I switched over from Triad to this wonderful skin and I have a little question. ;-)
Different header designs per group?
Is there a possibility to define the background color of the #header individually für each group? Preferably to be defined in the PageElements...?
Kind regards!
Volker - 2016-10-17
HansB: You can create Group-specific PageElements pages. A GroupName.PageElements page section will be used if present (and in that case not the Site.PageElements section, for that specific group). You need to update to the latest version just released for this (there was a bug in previous versions preventing this). But this will not really allow you to apply different CSS rules for the HTML #header div. For this you would need to create a group-specific css file in the pub/css/ directory, like GroupName.css with your modified CSS rule for #header. If you are not happy with that method, and want to allow style settings via a wiki page, have a look at the CSSInWikiPages recipe.
VolkerM: I already knew the group-specific PageElements page concept. (...and I love it!) The second part of your answer is it - for me. :-) Now my MoerkePortal has different headers depending on the group. Perfect! Vielen lieben Dank!
Hello Hans. Thank you for this beautiful development. I have set up a homepage with this skin (broprax.de). There are however two minor flaws.
site-title problem (solved)
I have imported two fonts (@import url('https://fonts.googleapis.com/css?family=Baloo|Lato');) Baloo and Lato. The site-title does not display in Baloo although the site-subtitle does and the h1 does too.
I have this code in skin.css:
/* header & page titles */
.site-title { font: 2em 'Baloo'; }
.site-subtitle { font: normal 1.2em 'Baloo', sans-serif;
display:block; padding-bottom:3px; }
HansB: try changing the first line to
.site-title a { font: 1.2em 'Baloo'; }
In fact change all three instances of .site-title to .site-title a, and adjust em sizes if needed. The site title is a link, and the 'a' seems necessary here. I have now fixed the distributed skin. Thanks for bringing this to my attention!
Yep! That did the trick! Thank you. It's a really beautiful skin.
titlebar link problems (solved)
The other issue is, I have changed some of the data such as to have
$ScriptUrl= 'http://broprax.de/pmwiki.php';$PubDirUrl= 'http://broprax.de/pub';
On every page I have the line at top saying for example "Home > Praxis > Startseite". If you click on "Home" you get an error message.
As you are using different default names (not 'Main' and 'HomePage'), try adding this in config.php (Ref: PmWiki.BasicVariables):
$DefaultGroup = 'Praxis'; $DefaultName = 'Startseite'; $DefaultPage = 'Praxis.Startseite'; //not needed if the two above are used
You also need to modify the #titlebar section in page Site.PageElements, replacing 'Main' for 'Praxis' and 'HomePage' for 'Startseite', and perhaps $[Home] for 'Startseite' too (to change the link text). - HansB September 09, 2016, at 02:35 AM
DefaultName and DefaultGroup already did it. It's perfect. I'm really satisfied with this skin. It's beautiful. I think you can now delete all of the above if you like.
HansB: ich würde noch empfehlen, auf der Startseite (:notitle:) reinzusetzen, damit Startseite nicht als Seitentitel erscheint.
Hi Hans, Thank you for this skin, I'm trying to switch from triad to amber but I have some problems (see below). Thank You - Frank September 05, 2016, at 10:12 PM
Wrapping of lists around a floating div (solved)
Here (Block Tests) I have created a couple of tests with bulleted list and >>lfloat... and >>lf25... so you can see the odd behavior.
HansB: Horizontal rule had a clear:both css rule, now removed.
Unfortunately the problem remained. Could be a problem of my installation?
Then I do not understand what is not working for you with bulleted lists. The list with skin names on the test page is floating correctly to the right.
I'm sorry, my english is not good. What I mean is that normally the bulleted list, after the left-box, should continue below the box (as in the standard pmwiki skin), it should not continue to the right side of nothing leaving an empty space below the box. Note in the test the gap between the box and the normal string after the bulleted list.
That is exactly my intention. Apart from getting the bullet list at a good distance from any floating element, like an image. If you want the list to wrap around, add this rule to your pub/css/local.css file:
dl, ul, ol {overflow: visible;}
That applies to definition, unordered and ordered lists.
Problem solved. Thanks. I didn't expect it was your intention for the lists too. - Frank September 08, 2016, at 11:43 AM
Conflict with Cookbook.HorizontalVerticalMenu (solved)
There is a conflict with the menu markup - the levels (based on bulleted list) don't open anymore.
HansB: Amber has some general css list rules which conflict with this recipe. Please add to pub/css/local.css:
/* style corrections for menus.php */
div#hmenu ul, div#vmenu ul { overflow: visible; }
div#hmenu:not(li) > ul > li { margin-left:0; }
Problem solved. Thanks. - Frank September 08, 2016, at 04:51 AM
Conflict with Cookbook.CSSToolTipsToGo (solved)
There is a conflict with the tooltip markup within the bulleted list texts - the bottom part of the popup-content disappears if the next line below begins with a non bulleted line (standard line of text).
HansB: I cannot get this recipe to work, even without Amber skin. I would need some working example perhaps to see what you mean.
I think I have found the problem in the tooltip recipe, just correct the Markup_e("CSSTTTG")..., line 124. Then if you try this example (below) you'll see the problem.
* [|||hovering-text||popup-contents\\ Suspendisse nisl tellus, tincidunt ac, adipiscing in, tincidunt non, urna. Praesent lectus. Nulla ultrices metus in mauris.|] Standard (no bulleted) line
I find this recipe really difficult to work with, and it has an odd way to construct the class names for the spans it creates, which makes it difficult to create a CSS rule to accommodate it (because the class handles change). The conflict with the Amber skin is caused by Amber's CSS rule in content.css dl, ul, ol {overflow: hidden;}, but the reason for this rule is to make lists behave in a better way when floated, so I do not want to throw this rule out. Ideally the tooltip popoup recipe should be rewritten to change its odd way of creating class names. Then we could create an exception rule for local.css.
Thanks for the clear explanation. Yesterday I thought about it and I changed the recipe so now there are only some fixed classes so the users can just use them but they cannot create new ones. The css classes of one of them looks like:
class -> span.tttgTooltipOne
text -> span.LtttgTooltipOne
hover - span.tttgTooltipOne: hover span.PtttgTootlipOne
Pop-up text -> span.PtttgTooltipOne
But create a rule is beyond my abilities (I tried but working with 'spans' is too complicated for me). I hope now this has bettered the situation and you can help me creating a rule, otherwise I will warn users not to use tootlip within bulleted list. Thank you in advance, this is the last attempt I will do to fix the problem 'tootlips', I am not going to bother you once again about it.
I can see that this problem will disappear if you have added to pub/css/local.css (same as for the bullet list wrapping)
dl, ul, ol {overflow: visible;}
so then we would not need to create a special exemption rule for a specific tooltiptogo class.
Problem solved. Thanks. This solution is fine for me. - Frank September 08, 2016, at 11:43 AM
Horizontal scroll bars for wide tables (solved)
The test (tables) that I had written here was moved to the bottom of the wikipage, if you move it again at the top of the wikipage you can see that when the tables are horizontally too long, the text is superimposed on the sidebar. My idea was to add via css: #content { width:100%; overflow:scroll; }, but I'm not so sure It could be a good solution.
HansB: I am not sure what you are referring to, I cannot observe this overspill. Can you create another example page please?
Oops, someone cut the tables I'd written. See now here (Long tables). In order to see the problem clearly I've included (temporary) the section at the top of the wikipage.
I now added script code to add horizontal scrollbars to tables as necessary.
Problem solved. Thanks. - Frank September 08, 2016, at 04:51 AM
Unsetting font increase for wide displays (solved)
I tried to prevent the font-increase for very wide or full screen windows with @media screen and (min-width: 75em) {body {font-size:1em;}} but widening the window the sidebar goes out the window (i.e. it disappears).
HansB: this should now be fixed in the latest update.
Unfortunately the problem remained. Could be a problem of my installation?
I do not know if this information can be useful, but if I enlarge a lot the window and then I reload the page, the font remains unchanged (1em) and the sidebar in the correct position ... as soon as I touch the window to make it smaller or larger, the sidebar ends half under the right edge of the window (if I continue to enlarge it disappears under the right edge of the window).
I need to see a page which illustrates this please.
Problem solved. My mistake, the last update had no effect because I inadvertently left a string on local.css from my previous triad customization, now the position of the sidebar is perfect. Thank you. - Frank September 08, 2016, at 04:51 AM
Preventing slide-out side menu from closing when clicked on (solved)
Clicking any toggle-button or toggle-link (UnToggle, Toggle, Action Menu, etc.) closes the right|left menu... this is not a big problem when those markups are in the wikipage because if a user opens the toggle-menu means he is not reading the wikipage, but I used some of them within the sidebar, and now I cannot anymore. Is there a way to prevent this behavior?
HansB: Could you please provide a test page or some markup I can copy and test locally?
I just realized that the same odd behavior occurs with input buttons too, so I have created a page that can be seen online here (Forms).
Do you mean this happens on a mobile browser screen, i.e. narrow screen, where the side menu slides in from the side? Clicking anything on the page when the side menu shows will hide it again, by design. Again, I like to see an examples which illustrates the behaviour, and a clear explanation of what is not working as it should be. Thanks! - HansB September 07, 2016, at 05:37 AM
I'm sorry again for my poor english. Yes, clicking anything on the page (and some things that are in the side menu like toggle-links, buttons, etc.) when the side menu shows will hide it again. In my installation I have written some toggle-links and some input buttons in the sidebar (consequentely they are in the side menu when it slides from the side).
I can't create an example online because I can't edit the PmWiki Site/SideBar.
I hope I have explained things better now, my question is: Can you avoid this behavior (the closing of the side menu) if you click anything (e.g., toggle-links, buttons input, etc.) that there is in the sidebar (consequentely in the side menu when it slides in from the side), please?
With the latest update the closing of the sidemenu script got more differentiated, so clicking/tapping on elements on the sidebar should keep it open (of course any link opening a new page will result in its closure anyway). - HansB September 08, 2016, at 07:25 AM
Problem solved. Thank you very much. Everything works perfectly. - Frank September 08, 2016, at 11:43 AM