Skins-Talk

Flexbox

Does or will PMWiki be using CSS Flexible Box Layout Here are some links:

gnuzoo

Flexbox (and also the more recent Grid) have always been available. Just define styles in pub/css/local.css and use them in WikiStyles. --Petko

Is it used in the Responsive skin?

It is not used in the responsive skin, but it is available if anyone needs it. --Petko

Why is it not used?

The Flexible Box Layout Module, makes it easier to design flexible responsive layout structure without using float or positioning.

The CSS Grid Layout Module also offers a grid-based layout system, with rows and columns, making it easier to design web pages without having to use floats and positioning.

I would like to see PMWiki keep up with newer advanced technological methods available. Would PMWiki default skin would be greatly improved using these? Can you make a "Responsive Flexbox" skin or a "Responsive Grid" skin or a "Responsive Grid Flexbox" skin?

gnuzoo

Flexbox is not used because in 2016 when I started working on the flexible responsive skin, browsers didn't support flex or grid very well. Now they do, but even if we rewrite the skin to use these, nothing will change visually or functionally, the skin is already mobile-first and responsive. Flex and Grid can really help with complex layouts but our skin layout is very simple and already works without these. You can have wiki page content with flex or grid as needed. In your opinion, specifically how would the skin be greatly improved using these? I already have a lot to do and this one would not be a top priority, but obviously you or anyone else are free to create a new flexbox skin, publish it to the cookbook, document it, and support it. :-) --Petko


$GUIButtons scrolling interference

Some weird interaction is going on between GUI buttons and edit area scrolling. With $GUIButtons enabled and the default pmwiki adaptive skin, edit a page on pmwiki.org and resize the browser window smaller until the adaptive skin turns to a view for mobiles. Now click at the end of the first line in the edit area to set the caret position. Then click the third GUI edit button (link to internal page) to append link markup to the current line. You should see the edit area jump down (scroll) to about 2/3 of its height (my guess). This jump makes the GUI buttons pretty much unusable on a tablet or phone. I can also reproduce this issue with a full desktop view but so far not with the pmwiki adaptive skin. I can with the Amber skin. --SteP February 01, 2020, at 11:33 PM

Do you mean that the mobile browser scrolls the page down so that the border of the textarea comes to the top of the viewport and the buttons are hidden? My guess is that the browser does this because with the on-screen keyboard the textarea becomes taller than the viewport. Try adding to pub/css/local.css something like #wikiedit textarea {max-height: 60vh; } This will work better if you have only one line of buttons. --Petko February 01, 2020, at 11:54 PM

Okay I can see what you describe (scroll down 2/3) happens in a desktop Chrome, but not in Firefox. --Petko February 02, 2020, at 12:01 AM

max-height: 60vh; enabled at Main.WikiSandbox how does it work for you? --Petko February 02, 2020, at 12:05 AM

Main.WikiSandbox works fine now but I still get the same effect using the Amber skin in my test site. I added the CSS rule you suggested, and compared #wikitedit CSS properties side by side between the pmwiki adaptive and the amber skins. They're essentially the same, except that amber uses em's instead of pt's for font-size, and sets #wikiedit textarea { font-size: 0.85em; }. Any ideas? Thank you. --SteP February 02, 2020, at 01:16 PM

They are alike because Amber was heavily based on an early version of PmWiki-responsive (2016). Do you have the problem at Main.WikiSandbox?action=edit&skin=amber? (I don't. If you don't, you may have added the rule in the wrong pub/css/local.css file -- it needs to be in the field relative to index.php not necessarily pmwiki.php.) --Petko February 02, 2020, at 02:34 PM

I do have the problem at Main.WikiSandbox?action=edit&skin=amber but it takes some pains to trigger it. I start with a large window (Amber calls it desktop mode), add some loreipsum and click the local link button to insert a couple of links here and there. This works fine. Then I shrink the window until the skin adapts to a mobile view. Again I add a couple of links (or more) and this also works fine. Then I widen the window again to desktop mode. Again click to add links in different places. Sometimes one of the clicks will make the text area scroll down. Sometimes not. But repeating the cycle shrink-clicks-widen-clicks eventually makes it happen. The same cycle doesn't affect pmwiki adaptive (excellent job you did on that skin...)

On a side note, I noticed that pmwiki adaptive and amber take opposite views about text size. While pmwiki enlarges text going into mobile view, amber enlarges text going into large desktop view.

As regards adding the rule in the wrong local.css, my test server doesn't run a FarmD so there's only one pub/css/local.css file. --SteP February 02, 2020, at 05:13 PM

Indeed, in mobile view some phones zoom-in when you click into a textarea or other field with a font-size<16px. This is annoying and hard to read, edit and navigate, that's why the "mobile" textarea font is set to 16px. The "desktop" font is 14px to be closer to the older "pmwiki" skin. Otherwise the fonts when reading a page should be the same, but the spacing in lists is different -- in mobile view horizontal spacing is a bit smaller to allow more text on the screen (left indent), and vertical spacing is larger to prevent people with large fingers from clicking on the wrong links. BTW these are "reference pixels" and unlike MSIE6 modern browsers do resize them depending on the device. --Petko February 02, 2020, at 05:51 PM

I left a message at Skins:Amber-Talk linking here. --Petko February 02, 2020, at 05:51 PM

I fixed this issue on my test server, which uses the Amber skin. Amber isn't broken; it's just that it was designed in 2016 and some modern browsers have changed. The gist of it: make sure that the skin stylesheet (or the local one) explicitly set the font size of #wikiedit textarea in px units, not ems, otherwise the scrolldown jump issue that I described will occur. My preference is for styling textarea early in the stylesheet and not change it anymore. If further rules change its font size, for instance media queries, make sure again to use px units.

Now coming to how I changed Amber. The skin stacks several stylesheets, the ones that matter are skin.css and content.css because they set textarea font size -- always in ems. To start with a clean slate I just elimitated all font-size settings involving textarea from both files. Then I added textarea { font-size: 16px; } to skin.css before media queries (16px is the zoom-in trigger point for some mobiles, as Petko noted), and textarea { font-size: 14px; } inside the "desktop" media query rule. This fixed the scrolldown jump for good. Then I looked at how the pmwiki-responsive skin styles textarea and discovered that it does it exactly the same :) This was a good learning exercise.

To finish the job, I moved #wikiedit textarea { max-height: 60vh; } from local.css to skin.css inside media queries, with 60vh set for "desktop" and portrait "mobile", and 40ev set for "tablet" and landscape "mobile". I think this issue is browser dependent but not site content dependent, therefore it should be dealt with in the skin.css file. As a final touch, my config.php hides the page title when $action == 'edit' so more vertical space is available to fit the edit area, otherwise 40ev wouldn't be short enough for 1280x800 notebooks -- at least not with the Amber skin. It would be more precise to introduce media queries with max-height constraints but in practice the following width breakpoints seem to be enough to handle most devices regardless of device orientation: 30em/480px portrait mobile, 40em/640px tablet and 55em/880px desktop. --SteP February 03, 2020, at 03:00 PM

I suggested local.css because setting your custom styles there will allow you to easily upgrade to newer versions of the skin without losing your changes or having to re-add them. That file is loaded after skin/skin.css and any setting/value there overrides those set by the skin. You can use pixels and @media queries too. --Petko February 03, 2020, at 07:29 PM

Agreed. Since in this case I am already in need to change skin.css I might just as well keep all related changes in one file (skin.css). My preference for having the skin deal with this issue is an aside. --SteP February 03, 2020, at 07:47 PM

404

Both skins listed in the 'hosted elsewhere' section are 404

--dixonge? 10/21/2017

Thanks, fixed (found them by browsing from their home page). --Petko October 21, 2017, at 12:16 PM


After every skin I install, on each of the browsers I use, I get the following error messages above the actual wiki:

Warning: fopen(pub/cache/Site.StyleSheet.css) [function.fopen]: failed to open stream: Permission denied in /f1/content/.../public/pmwiki/cookbook/stylepage.php on line 105

Warning: fclose(): supplied argument is not a valid stream resource in /f1/content/.../public/pmwiki/cookbook/stylepage.php on line 107

Warning: Cannot modify header information - headers already sent by (output started at /f1/content/.../public/pmwiki/cookbook/stylepage.php:105) in /f1/content/.../public/pmwiki/index.php on line 1079

Please could someone explain what this is all about?

The wiki loads and works as normal (as far as I can tell), but this stuff just spoils it.

This looks like a problem with a recipe: Cookbook:CSSInWikiPages which supplies the file stylepage.php. You may want to ask the recipe author there. --Petko July 12, 2009, at 07:22 PM


I'd like to put out a warning about the Bs-001Skin. This folder, when extracted to the proper server-side directory, effectively freezes my entire wiki-farm field.

Jagtig

This is a talk page for improving PmWiki.Skins.