2015-09-30
There are good and bad wikitext dialects
One of the things about wikitext dialects that I've essentially asserted in passing is that there are 'good' and 'bad' dialects. Perhaps this raises your eyebrows, either because you think all wikitext dialects are a bad idea or because you don't see what creates such a difference.
There are two possible criteria for goodness in wikitext (or in general any simple markup scheme), depending on why you're using a wikitext. For a markup aimed at empowering beginners, what probably matters is how simple, straightforward, and error-free it is. This ties into your desired style, in that it should be both easy and obvious to create the kind of content that you want, marked up and styled in the ways that you want.
For a markup aimed at smoothing the way of frequent authors, what matters is how unobtrusive and smooth the markup is. The more that you have to spray large amounts of special text all over your content (and the harder they are to tell apart), the more the markup is getting in your way and the less it's giving you compared to just using normal HTML. This leads me to feel that good wikitext here either looks close to what you'd write in plain text or is simple and terse. The goal in both cases is to minimize the extra friction of adding and using markup.
(I feel that aesthetics matter here because you don't just write your text, you also read it as you're writing and revising. A wikitext dialect that is obtrusive or ugly winds up obscuring your actual content with its markup. If you can't easily read your content for flow in its un-rendered form, well, that's a kind of friction.)
A bad wikitext dialect is one that moves away from these virtues. It's obtrusive and verbose; it's complicated and perhaps hard to keep straight; it makes it hard to decode what the markup means at a glance (due to eg using a bunch of very similar markup characters). It gets in your way. It may make it too easy to put markup mistakes in your text or too hard to find and fix them. Overall, it contorts and distorts your writing process.
(My fuzzy view is that a wikitext dialect being incomplete doesn't necessarily make it bad. In the abstract incompleteness just makes a wikitext unfit for some purposes, but then if you're forced to use the wikitext anyways for these purposes it can turn into something that's getting in your way and thus is bad. I wave my hands.)
2015-09-19
Experimenting with Firefox's 'Reader' mode (or view)
In an exchange of comments on my entry on blocking floating web page elements, Nolan mentioned Firefox's Reader mode and I said that I'd had bad experiences with it and used 'view page in no style' instead. Well, let me take that back. Back the last time I looked at it there were various glitches and issues that convinced me I didn't want to use it (and in fact I banished it from my Firefox's by setting reader.parse-on-load.enabled to false in about:config). But this week, sparked largely by Nolan's comment, I've been giving it another try and it's improved to the point where it's actually reasonably decent now.
(If you use NoScript, as I do, note that you have to explicitly whitelist 'about:reader' or the Reader mode displays an almost totally blank page.)
Reader mode doesn't work on everything and it's not perfect, but what I'm finding is that it often does a more attractive job than the blunt hammer of 'view page in no style'. In part this is because Reader mode makes a whole bunch of page elements go away entirely instead of leaving me to scroll through a mess of unstyled menus and top bars and so on. And some of it is somewhat more aesthetic formatting than an almost plain text sprawl of text (which works well for some but not all web pages).
However there is one fly in the ointment; the Reader view styles unvisited and visited links the same, leading me to irritation. This is a real usability issue for some but not all sites, since it lets me distinguish between things I haven't read (and might want to go on to read) and things that I already have read. I've hacked a CSS modification for this into my custom Firefox build but for some reason it's not entirely successful; some visited links still show as if they're unvisited.
(The Firefox Reader CSS source is quite clear about this; all forms of links are styled the same, explicitly including visited links.)
For a fair number of things this doesn't matter because I'm highly unlikely to follow even unread links to explore more; this is typical of things like news articles. But if I've wound up on an interesting blog entry that has hideous styling (which is far more common than I'd like), I'm much more likely to potentially explore further and so I want that visited/unvisited marker.
(I note, apropos of ongoing controversy over the release of iOS 9 and the popularity of adblockers for it that Reader view also strips out ads. Since you have to load the page normally first, ad networks will still get to count a page load based ad impression and of course spy on you as much as possible. Unless you use an adblocker as well, which I think you should.)
Sidebar: What the unvisited-links problem may be in Reader view
I got curious and used the built in Firefox debugger tools to look
at the version of the links in the raw HTML in Reader view (you
can't just do 'view source', because the HTML is dynamically
inserted). I've been testing my patched Firefox on Wandering
Thoughts itself (it's an easy source of content with visited
URLs), and what my exploration suggests is that I may be running
into problems because Reader view is re-encoding my URLs to change
that /~cks/ part of the URL to /%7Ecks/. In theory this
should not make any different to whether or not they are visited
(the two URLs are the same), but in practice Firefox's history
system seems to consider them different URLs.
(This is where I sigh a lot at the combination of technical issues colliding here.)
The good news is that this is unlikely to be an issue on most sites that I want to use Reader mode on. If I'd used something else as a test case I might not even have noticed it at all.
2015-09-13
I should have started blocking web page elements well before now
uBlock Origin has a feature where it adds a 'Block element' option to Firefox's popup page menu (and I think other adblockers do too). For a long time I ignored it; after all, I had already had an adblocker (several of them, in fact), so what need did I have for yet another way of blocking ads, a manual one at that? Let me tell you, I was wrong. I was wrong about ignoring it, and wrong about what I should be using it on. I discovered this because I recently started using it and it's made a real difference in my experience of the web.
The secret is that the thing to use 'Block element' on is not ads, it's all of those floating bits and pieces that modern websites like to put on top of their content. 'Please subscribe', 'please tweet this', 'please see this other thing'; for some reason far too many websites are far too in love with little messages and calls to action of that sort. What makes these things especially irritating is that they don't run the full width of the page. This screws up page-based scrolling and acts as a constant partial intrusion into the side of the content.
(Conventional overlaid headers and footers run the full width of the page, which I usually find less obtrusive. They may make me unhappy by taking away content space, but they no longer cause problems with page-based scrolling.)
Before I started this experiment of blocking all of those floating elements I didn't realize how much they irritated me and degraded my site browsing experience for sites that they appeared on. Now that I'm aggressively getting rid of them, well, I've been surprised at how much of a difference it makes in how I feel about some sites. They seem to have been yet another one of those low level irritations that I don't realize were nagging away at me until I get rid of them.
(Perhaps they are less obtrusive for other people because other people browse with much wider browser windows than I do, so the floaters aren't necessarily over the content but instead over unimportant side elements. Or perhaps the people designing these sites just don't care.)