Summary: Talk page for 2016 skin.
Maintainer: Petko
Users: +1 (View / Edit)

This space is for User-contributed commentary and notes. Please include your name and a date along with your comment.

Your comments are welcome. Please add new sections here. --Petko

The skin https://www.pmwiki.org/wiki/Skins/2016 says

    I currently recommend the "pmwiki-responsive" skin which ships with recent PmWiki versions 
    or which you can get here: pmwiki-responsive.zip. --Petko August 18, 2017, at 12:11 PM

but pmwiki-responsive.zip is not listed in the main list of skins at https://www.pmwiki.org/wiki/Skins/Skins Can you please add "pmwiki-responsive" to the list? --gnuzoo

Added to Skins. If it is unclear, PmWiki-responsive is enabled the whole pmwiki.org site, except where the page is about another skin like Skins:Triad. --Petko May 08, 2019, at 08:38 AM

You can add to Test.2016 Skin wikitext samples that need review/fix.

Install Problem?

Sorry to jump in here. I'm trying to install this skin. Currently using "Triad" but want responsive site. I can't make it work. Same problem with "Adapt." But I can switch to "Amber" and it works. Not sure of Pmwiki version, but Amber requires >=2.2. What could I be missing? glenn blalock, August 18, 2017, 11:00 am (Our Pmwiki is one of PM's original installations. He was a faculty member here, way back when.)

What is your PmWiki version (see your pages PmWiki.PmWiki or PmWiki.Version), and what is your PHP version? This 2016 skin requires at least PmWiki 2.2.58. I'll currently recommend the pmwiki-responsive skin which ships with the nightly PmWiki version, it should work with PmWiki 2.2.0, probably earlier, only before PmWiki 2.2.56 [[#anchors]] will be output in HTML4 and not HTML5 (you'll see no difference). --Petko August 18, 2017, at 12:09 PM

Thank you! We are still on 2.2.26, so that is obviously one problem. If I can't get a full upgrade on our install here, I'll work with the responsive skin you point to. I really appreciate your assistance. And all you continue to do with this software. glenn, August 19, 2017, 10:16 am

This 2016 skin was used as a base for the pmwiki-responsive skin, they look and are mostly the same but the latter contains improvements suggested by more people. --Petko August 19, 2017, at 11:21 AM

Suggest to make code overflow

I would suggest to add code and non escaped lines an overflow : auto; property. (rather than wrap I guess). gb July 03, 2016, at 08:59 AM I would suggest to add code and non escaped lines an overflow : auto; property I would suggest to add code and non escaped lines an overflow : auto; property I would suggest to add code and non escaped lines an overflow : auto; property

Should work as of 20160703, only in "Desktop" (large) mode. To see stretched elements on a touch-screen mobile phone it is easier to swipe the whole page, than to scroll an element within the tiny paragraph frame. (As long as all other lines do not stretch.) --Petko July 03, 2016, at 11:37 AM

Sometimes yes (yet sometimes one will prefer to move the mobile lines and and keep the static context readable, rather than moving the full page one way to read something, and move back to remember what it's referring to ;)) ; subsidiary, what will happen if I want to use that Skin, with a sidebar on right side ? To make the touch action more convenient, on may want to border the lines' contain air and give it a stronger padding (strictly suggesting). gb July 03, 2016, at 05:00 PM
I agree with gb. I do not think it is easier to swipe the whole page. Especially not if there is no indication that content stretches beyond the page side. Horizontal scrollable elements should have an indication that they are scrollable, and I rather scroll them individually than the whole page on a touch screen. - HansB April 29, 2017, at 01:44 PM

We cannot add padding (space) selectively only when the element is scrolling. There are 4 ways to make a code element very wide:

[@ (1) Your example, single line wrapped with "[ @" and "@ ]" @]

 (2) A line that starts with spaces
     Consecutive lines are part of the same block

 (3) A block containing line breaks wrapped with "[ @" and "@ ]"

 [=(4) A leading space then multiline block 
    wrapped with "[ =" and  "= ]"=]

(1) Your example, single line wrapped with "[ @" and "@ ]"

 (2) A line that starts with spaces
     Consecutive lines are part of the same block
 (3) A block containing line breaks wrapped with "[ @" and "@ ]"
 (4) A leading space then multiline block 
    wrapped with "[ =" and  "= ]"

PmWiki produces different kinds of preformatted HTML elements.

  • Your example (1) is code.escaped which is an inline element, meant to appear inside a paragraph or a sentence - I don't think an editor can mistakenly create such an element that makes the page so wide that becomes unreadable, and I don't want to add spacing around these elements: see how I use such an element in this paragraph, adding spacing would change the line heights which is not pretty.
  • The (2) example is most likely to happen by mistake with new editors that don't yet know about the leading space rule. But such code blocks can also happen intentionally, like in our documentation. Also, this type of code can contain links, bold and other inline markups. I don't mind adding borders and space to such blocks: even if this would be unlike the current default skin, this will indeed make the content structure easier to read. (The HTML element is pre.)
  • The examples (3) and (4) also cannot appear by mistake, such markups are used intentionally by more "advanced" editors. They are separate, intentional blocks of preformatted text, and I don't think borders and spaces will go against the meaning. As HTML elements, (4) is also pre, (3) is pre.escaped.

So I'm willing to add borders and spacing ("padding") to the pre blocks which are intended as blocks, but not add borders or spacing to the inline code.escaped lines that are intended to be part of a sentence among other words.

About your question: when the sidebar is on the right, if the skin designer has copied and kept most of the styles, the elements will scroll, like when the sidebar is on the left. The sidebar can only be to the right in "Desktop" mode.

All these styles can be overridden by custom rules in local.css, so if an admin doesn't like the scrolling or the borders, she can remove them. --Petko July 04, 2016, at 04:29 AM

Educational value

As a (future) core element, this skin will be a major entry point for derivative works and therefore should be well documented. Noticeably, as the skin development is a rather sharp field in web development, giving pointers on technical considerations and hints should be very useful to regular developers.

Dfaure July 02, 2016, at 02:17 AM

Yes, it will be documented. --Petko July 03, 2016, at 09:54 AM

CSS class instead of id

Please consider using class as selectors rather than id for labelling entities (cf the recent change to Site.EditForm), but great to see entities now given an identifier (maybe PITS:00638).

simon June 30, 2016, at 04:23 PM

For the needs at hand (easier styling and scripting, unique non repeating elements), using ids has clear benefits over using classnames. --Petko July 01, 2016, at 02:44 AM

Header and footer to include wiki pages

Would it be possible to turn the header and footer into fully fledged wiki pages (the same as the side bar), thus reducing content in the template? (Simon, on the mailing list)

I wanted to make sure that the skin will work if no wiki.d or wikilib.d directories are found. So I wrote a function that will use page sections from Site.SkinElements if such a page section exists, otherwise the default, hardcoded HTML. Note that the skin features require certain CSS ids and classes, and the wikicode of these sections is a bit complex in order to work and be aligned; a simpler wikicode could be used, this would disable the selective opening and hiding in mobile mode. --Petko July 01, 2016, at 07:07 AM

Maximum page width

A question: what consideration has been given to moving to a design where the page content is styled to use a maximum em width? This would make pages more readable on wide screens, without the reader having to adjust the window size. (John Rankin, on the mailing list)

This may be configurable, I've added sample rules to the recipe. I don't want to argue about this: people do not read books like they read webpages - they scan/skim the text. Moreover, I don't want to impose a specific width: different types of content require different widths. My objective to stay very close to the default skin in no way prevents a website to change the width. --Petko

Making it configurable would be very helpful. It takes a non-trivial amount of work (and knowledge) to modify the default skin to produce, for example, a layout centred in the browser window with a width that adjusts with zoom in/out. --jr

I have documented it in the recipe page, simply set #bodywrap{max-width:50em;} to local.css. :-) --Petko July 01, 2016, at 06:07 PM

Just some comments: Super-wide content hurts usability because people read web pages using an "F Pattern". Extreme variability in page width also can make a page's content appear differently than an author intended (PmWikiPhilosophy #1). --Hagan


The first thing I noted is that lists are no longer indented in the smallest mode when the sidebar changes to a hamburger list. You can see this with the UL and OL on the skin page. XES July 01, 2016, at 07:01 AM

In mobile mode the list number or bullet should be aligned with the left margin of the above paragraphs (to save screen real estate, other indents are also reduced). Bullets/Numbers of indented lists should align with the left margin of the "text" of the parent item. Firefox, Chrome and Safari render this a little differently, and indeed on the iPhone the lists appeared more to the left. Now it should be better: either aligned, or a little to the right. --Petko July 01, 2016, at 07:21 AM

A minor bug and 2 feature suggestions

There is a typo on line 36 of skin.php: metgod should read method.

In small-screen mode, would it be better to display a link to Recent Changes immediately to the left of the magnifying glass icon? This is a very useful link and it seems a pity to lose it in the mobile view.

Would it be better to make xmenu.svg a 3 bar icon, rather than 4? The ☰ symbol seems to be a widely-used convention for a pop-up menu icon. For example, I edited the svg and tested <path d="M 0,30 H 60 M 0,54 H 60 M 0,6 h 60"/>. --jr

Thanks for reporting the typo, fixed for 20160822. About the Recent changes link: I fear that if a website logo is wider, the Recent changes link may get a line break; I've made the RC and Search links that are in "desktop" mode before the search field, appear in "mobile" mode above the search field in the same frame (now enabled on this page). Will this be acceptable? About the 3-lines menu: I've modified the icon to have 3 lines, and indeed it looks better to me; if nobody objects, it will be included in the next version. Thanks! --Petko August 22, 2016, at 01:59 AM

For consistency, consider making the mobile search box flush left rather than centred. All other screen elements are flush left. By way of a comparison, I made a version that makes the recent changes link visible in "mobile" mode here. It is true that this may not work with a wide logo. Perhaps the recent changes link could be visible by default. An administrator could then over-ride the default in local.css. jr August 23, 2016, at 05:54 PM

Talk page for 2016 skin (users).