[HOME] [DOWNLOAD] [DOCS] [BLOG] [SUPPORT] [TIPS] [ISSUES] [Priority Support]

short and detailed buttons in the wiki, html help wanted


#61

Oh, right. I forgot its the /var/www/wiki/skins/strapping/theme.css for desktop, since the https://www.whonix.org/wiki/MediaWiki:Common.css is not used by strapping.

This seems to be a design choice (a bad one in my opinion).


#62

Ah. I forgot this also.

Updated:
https://github.com/Whonix/www/blob/master/w/skins/strapping/theme.css

Now “short version:”, “detailed version:” is totally gone in javascript disabled version.


#63

I see “Short version:” right above “Tor Controller” and “Detailed version:” above “Contents” when JS is disabled on desktop.

Done. Add the following to https://www.whonix.org/wiki/MediaWiki:Mobile.js

$(document).ready(function () {
    $('div.toc-mobile.view-border-box').prependTo('.mf-section-0');
    $('div.toc-mobile.view-border-box').next().prependTo('.mf-section-0');
    $('div.toc-mobile.view-border-box').next().css('clear', 'both');
});

#64

Both, firefox and chromium did not show “short version” with JS disabled.

The output of

curl https://www.whonix.org/wiki/Tor_Controller

Did not include “short version”.

The output of

curl --cookie test=yes https://www.whonix.org/wiki/Tor_Controller

Did include “short version”. (Sending a cookie circumvents caching.)

So it was a caching related issue.

Note to self:

Text “short version” can now be copied. Yay!


Added:
https://www.whonix.org/w/index.php?title=MediaWiki%3AMobile.js&type=revision&diff=25199&oldid=25160

It’s not working. (And this time hopefully not a caching related issue since login cookie is set.)


#65

There is a new bug now. Not sure related to the changes made during this thread or a new bug in mediawiki. (Desktop version) After editing and saving a page, often on the left side there is no white space. Does that sound possible?


Unless there are better suggestions, let’s go for the Recommended / Alternatives button labels and concept.

Can we have anchored links such as https://www.whonix.org/wiki/Tor_Controller#Recommended and https://www.whonix.org/wiki/Tor_Controller#Alternatives please? Would there be JS-on vs JS-off related quirks?

On some pages I would like to write something like:

This was the recommended version of this page. For more, see alternatives.


#66

Maybe it’s a race condition, because it works when run manually via console.
Try replacing $(document).ready( with $(window).load( which will get executed a bit later.

Seems unrelated to me, but it wouldn’t be the first time MediaWiki surprises me. Any way to reproduce this?

There has to be an HTML-element with the attribute id="Recommended" inside the section that would be targeted. I’m not sure if we can use the <p class="sd-heading">Recommended:</p> element we just added because it will be hidden if JS is enabled, so auto-scrolling to the anchor might not work. Aside from that there shouldn’t be any JS-on vs JS-off related quirks.

Or you can just set the link target to the first anchor in the section, that would work without any changes.
For example:

This was the recommended version of this page. For more, see alternatives.


#67

Done:
https://www.whonix.org/w/index.php?title=MediaWiki%3AMobile.js&type=revision&diff=25215&oldid=25199

Does not work for me.

I get back to it when I find a way as I am failing to willingly reproduce it at the moment.


Perhaps also stable (always some anchors, #recommended #alternatives) links can be used? Because then it gets simpler to use this by using a template.

I was wondering if this can be implemented within the templates and simple anchor links alone. Partially works.

https://www.whonix.org/wiki/Template:Sd-start-short

{{Anchor|Recommended}}
{{#widget:Sd-start-short}}
This was the [[#Recommended|recommended]] version of this page. For more, see [[#Alternatives|alternatives]].

The recommended link already works nicely. (I wanted to jump above the recommended / alternatives button.) The alternative link already works but the issue is it jumps below the recommended / alternatives buttons. Do you think this can be fixed?


https://www.whonix.org/wiki/Template:Sd-end-short-start-detailed

{{#widget:Sd-end-short-start-detailed}}
{{Anchor|Alternatives}}
This was the [[#Alternatives|alternative]] version of this page. For the recommend version, see [[#Recommended|recommended]].
  • The recommended link is broken.
  • Same. (The alternative link already works but the issue is it jumps below the recommended / alternatives buttons. Do you think this can be fixed?)

#68

Yes, that’s no problem, requires just a dummy element like <span id="recommended"></span> in the widget. (which is the same what you already have tried using {{Anchor|Recommended}})

Yes, I can fix that.

That is because the anchor is outside of the corresponding section. You just jump to the anchor but don’t switch tabs.


#69

To fix the anchors, switch these lines in https://www.whonix.org/wiki/Template:Sd-start-short

And change in https://www.whonix.org/wiki/MediaWiki:Mobile.js and https://www.whonix.org/wiki/MediaWiki:Common.js the following lines from:

// watch window for change to expand tabs for fragments later
$(window).on('hashchange', (function () {
    if (hash === window.location.hash) {
        return;
    }
    hash = window.location.hash;
    sdJump($(hash));
}));
// make fragment links work
$('a[href]').filter(function (i, e) {
    return $(e).attr('href')[0] === '#';
}).on('click', function () {
    sdJump($(this).attr('href'));
});

to:

// watch window for change to expand tabs for fragments later
$(window).on('hashchange', (function () {
    if (hash === window.location.hash) {
        return;
    }
    hash = window.location.hash;
    switch (hash) {
        case "#Alternatives":
            return sdShowDetailed($('.sd-container'));
        case "#Recommended":
            return sdShowShort($('.sd-container'));
        default :
            return sdJump($(hash));
    }
}));
// make fragment links work
$('a[href]').filter(function (i, e) {
    return $(e).attr('href')[0] === '#';
}).on('click', function () {
    sdJump($(this).attr('href'));
});
// move anchors
$('.sd-container #Recommended, .sd-container #Alternatives').prependTo('.sd-container');

Note: I use “fragment” and “anchor” interchangeably


#70

Switched.

Done.


It works quite well. This is very good already. Minor issue: the no-JS version jumps below recommended / alternatives text rather than above that text.

Can you please add link/anchors to the actual buttons recommended / alternatives? That gets visible when hovering over the buttons by mice and going to the actual anchor when clicking these? [and also links/anchors for the no-JS text recommended / alternatives?]


Can you style the following text please? Perhaps a border around it and perhaps making the links look like the above buttons? (I guess this texts can be added to the templates.)

This was the [[#Recommended|recommended]] version of this page. For more, see [[#Alternatives|alternatives]].

This was the [[#Alternatives|alternative]] version of this page. For the recommend version, see [[#Recommended|recommended]].


#71

I’m late but I read the thread to get up to speed.

I think the aesthetics of the expansion buttons are less important than
what you stand to gain from changing the underlying wiki platform. Its
best if you focus on that instead and keep things as they are with
expand buttons. The amount of bugs you keep running into will make this
solution unmaintainable in the future and put off new users who see
broken pages. They will likely just leave without telling us why.
I don’t think this new feature should be justified by the effort already invested - that’s a sunken cost fallacy. ( I’m still thankful for those who put in the effort)

However if you choose to stick with this here are other points:

  • recommended / alternatives sounds very confusing. Suggests that the
    details about the topic is a completely different type of information
    than what is shown. Subconciously suggests the hidden text is not up to
    standard of the snippet shown.

  • The single button solution for short/long versions of a page is
    disorienting because I have no visible marker of what new information
    becomes visible (if any) for some section. I don’t want to re-read the
    entire page to see what relevant information I may be missing.

  • Don’t hide the footnotes in the short versions - they may be very
    important and someting we want the user to be aware about. For example
    references to research papers to show claims are substantiated.

  • This solution looks very fragile. I don’t think you should do heavy
    changes yet when it might all break when you move away from mediawiki. A
    replacement wiki that produces simple offline documentation possible
    should be a priority IMHO.

  • JS seems inevitable though the alternatives are worse. As long as it
    works with Noscript on Orfox and TBB its ok.