The One with the Thoughts of Frans

Archive for Internet

Stop Hijacking Annoyances

Here’s another rescue from My Opera. The script was compiled by the user pehage on February 3, 2012, after a quick pointer by me. It is Opera UserJS, so it won’t work in any other browser. Don’t forget to enable User JavaScript on HTTPS if you so desire. In Opera 12 it no longer pops up a warning all the time.

// ==UserScript==
// @name Stop Hijacking Annoyances
// @include *
// ==/UserScript==

var annoyances = ["focus", "focusin", "focusout", /*"click",*/ "dblclick", "mousedown", "mouseup", "mousemove", "mouseover", "mouseout", "mouseenter", "mouseleave", "select", "submit", "keydown", "keypress", "keyup"];

for (var i=0; i<annoyances.length; i++) {
	//opera.postError(annoyances[i]);
	window.opera.addEventListener("BeforeEventListener." + annoyances[i], function (e) {
		e.preventDefault();
		//opera.postError(e);
	}, false);
}

And here is a simple testcase I created.

<!DOCTYPE html>
<html>
<head>
<title>keypress hijacker</title>
<script>
document.addEventListener('keypress', function(e){alert('document.addEventlistener on keypress ' + String.fromCharCode(e.which))}, false);
window.onkeydown = function(e){alert('window.onkeydown ' + String.fromCharCode(e.which))}
</script>
</head>
<body>
This page hijacks keypress events in order to display an alert message.
</body>
</html>

Comments

Data URI Bookmarklet

This is a repost of something I wrote on My Opera forums on 8 January 2013. The My Opera forums will be shutting down on 1 March 2014.


The easiest method [to base64 encode an image] might be to use the newly supported (since v12) FileReader object, which has a readAsDataURL method. I wrote a quick proof of concept using XHR because I’m not really sure how else to get data to it (aside from a file input which is no good here). Alternatively you could load the image in a canvas and call toDataURL, but then you’ll lose stuff like metadata and I’m not even sure if the compression and such will remain the same.

var xhr = new XMLHttpRequest(),
	reader = new FileReader();
xhr.open('GET', location.href, true);
xhr.responseType = 'blob';
xhr.addEventListener('load', function () {
	if (xhr.status === 200) {
		reader.addEventListener('load', function (e) {
			location.href = e.target.result;
		});
		var responseWithMimeType = new Blob(new Array(xhr.response), {
			'type': xhr.getResponseHeader('Content-Type')
		});
		reader.readAsDataURL(responseWithMimeType);
	}
});
xhr.send();

It does seem a bit roundabout, so I’d love to hear it if anyone has more efficient suggestions.

I just realized you may not be aware of how to make a bookmarklet. To save myself the effort of removing comments and such I used http://chris.zarate.org/bookmarkleter to obtain the following result:

javascript:(function(){var%20xhr=new%20XMLHttpRequest(),reader=new%20FileReader();xhr.open('GET',location.href,true);xhr.responseType='blob';xhr.addEventListener('load',function(){if(xhr.status===200){reader.addEventListener('load',function(e){location.href=e.target.result;});var%20responseWithMimeType=new%20Blob(new%20Array(xhr.response),{'type':xhr.getResponseHeader('Content-Type')});reader.readAsDataURL(responseWithMimeType);}});xhr.send();})();

Create a new bookmark, paste that into the URL and give it a nickname of your choice.

Easier still, just drag this or right-click, bookmark link: To Data URI. There might be some security restrictions on MyOpera against javascript links, so I’m not sure if it’ll work.

But for local files a simple page would do just fine. All you need is input type=”file” and a tiny bit of scripting similar to the above. Something like this should do:

<!DOCTYPE html>
<html>
<head>
<title>File to Data URL</title>
</head>
<body>

<form>
<input type="file">
</form>

<script>
var file = document.querySelector('input[type=file]'), reader = new FileReader();

file.addEventListener('change', function(e) {
	reader.readAsDataURL(e.target.files[0]);
});

reader.addEventListener('load', function(e) {
	location.href = e.target.result;
});
</script>

</body>
</html>

Comments

Adding a User Font Size Preference to Simple Machines

Users should be able to choose their default font size easily through their browser, and their choice should be respected. But because all browsers default to 16px and most people never change the default, many sites—including Wikipedia—set their font-size to about 80% of that value to end up at a font size of 12px or 13px. Thus users might be prevented from lowering their font size on a site that actually respects their preferences if they so desire.

Because I don’t believe that either joining the 80% crowd or specifying a size in pixels is generally the right answer, I decided to add a user preference that overrides the font-size on the HTML element. For this to work as intended, your stylesheet needs to be entirely in percentages, em, rem, or use equivalent keywords like small and large.

First, in Admin > Configuration > Core Features, enable Advanced Profile Fields. Then, you can add custom profile fields in Admin > Configuration > Features and Options > Profile Fields. I added one named “Font size” with an input mask of /^[0-9]{1,3}(\.[0-9]{1,2})?(em|pt|px|%)$/.

Assuming your theme is based on the default, start editing index.template.php. Then, under the linked stylesheets you can put the override:

	// Custom user font-size
	if ($context['user']['is_logged']) {
		global $user_profile;
		loadMemberData($context['user']['id']);
		
		if (!empty($user_profile[$context['user']['id']]['options']['cust_fontsi'])) {
			echo '
	<style>', 'html {font-size: ', $user_profile[$context['user']['id']]['options']['cust_fontsi'], '}', '</style>';
		}
	}

To find out exactly what kind of useful values you can obtain from e.g. $context and $user_profile, you can use var_dump($user_profile).

Comments

Textarea Backup Localstorage v1.21

I figured I’d drop a note that I updated my Textarea Backup UserJS last month. What follows is the description from ExtendOpera.


Textarea Backup Localstorage

Retains what you type into textareas and contentEditable elements.

This script is only compatible with Opera 10.50 and up. If you need to use it with an older version use Textarea Backup but be advised that it comes with some disadvantages.

  1. Can automatically place previously typed text in textareas.
  2. Can add an unobtrusive menu in the top right corner of textareas

Actions menu screenshot (note the transparent object in the top right corner of the textarea):

Development can be followed on GitHub. Don’t be shy, open an issue or send me a pull request if you think you have something to contribute! 😉

Changelog

1.21 July 25, 2013. Sorry, I was a bit hasty about that last one. I passed my testcase, but only noticed that many contentEditables work differently in practice on this very site.

  • Fixed a bug that occurred when BODY was contentEditable, as is typical in iframes.
  • Properly compare initial value of contentEditable element to backed up value so you’ll only get prompted to overwrite when relevant.
  • Full changelog.

1.20 July 25, 2013. I wasn’t going to make yet another release in three days, but these new features could be implemented much faster than I initially predicted.

  • Trustworthy old persistent preferences support added. I also uploaded a sample settings file.
  • Fixed the keep_after_submission bug, so setting it to false is safe again.
  • Removed the form requirement.
  • Support contentEditable. This is a pretty big one, seeing how it was the most obvious missing feature.

1.11 July 24, 2013. Added configuration switches for the new feature.

  • For Opera 11.6x and Opera 12.x it now defaults to off because of potential performance concerns.

1.10 July 23, 2013. Added support for dynamically added textareas.

  • This new feature will only work in Opera 11.6x and up.

Comments

Cutting Corners With Linear Gradients

Presumably unnoticed by all, back in December 2012 I replaced the image-based cut corners in post headings with pure CSS. Border-radius removed the need for images to round corners, but you don’t need images anymore to cut them either.

Edited down to only the cutting of corners, this is what it looks like now:

.posttitle a {background:#0b0; background:linear-gradient(225deg, transparent 8px, #0b0 8px)}
.posttitle a:hover, .posttitle a:active {background:#6c0; background:linear-gradient(225deg, transparent 8px, #6c0 8px)}

And this is how it used to be:

.posttitle a {background:#0b0 url(images/posttitle.gif) no-repeat top right;overflow:hidden;}/*overflow:hidden for Webkit which insists on adding some kind of margin*/
.posttitle a:hover, .posttitle a:active {background:#6c0 url(images/posttitle.gif) no-repeat 100% -91px;}

Size-wise the difference is small: the GIF was only 107 bytes. You’d pretty much make up the difference by adding prefixed versions of linear-gradient if desired, albeit you do still save an HTTP request and you avoid one of Webkit/Blink’s bugs.

For scaling it matters only very little. But not having to open up an image editor for simple things like this? Fantastic.

Comments

How To Fix SVG Height in Webkit/Blink

It’s pretty simple: also specify a height if you specify a width. To quote from the workaround in my stylesheet, which I added on account of my previous post:

figure svg {
	width:100%;
	/*what follows is because Webkit/Blink is broken https://bugs.webkit.org/show_bug.cgi?id=68995*/
	height:100%
}

I really shouldn’t have added that as I don’t cater to broken browsers anymore, but I have a bit of a soft spot for Opera—even if it’s never required any workarounds before. Presto is clearly superior, and so is Gecko. Chromium still doesn’t support SVG favicons. Gecko does. And just look at this table. Unfortunately Gecko doesn’t support SVG fonts, so it’s all looking pretty miserable without Presto.

Comments (1)Tags:

parseIntHelper()

The results of parseInt() are somewhat inconsistent, so I wrote this to clean it up (also see there). What to do with it? Who knows; it might come in handy someday.

function parseIntHelper(numberString, radix) {
	numberString = (typeof numberString === 'number') ? numberString.toString() : numberString; // I guess we should support number input just like parseInt.
	radix = (typeof radix === 'undefined') ? 10 : radix; // Set radix to 10 if undefined.
	
	numberString = numberString.replace(/^\s\s*/, '').replace(/\s\s*$/, ''); // Trim. Taken from http://blog.stevenlevithan.com/archives/faster-trim-javascript
	
	// Check if octal; non-standard but in line with other languages
	if ( numberString.indexOf('0o') === 0 || numberString.indexOf('0O') === 0 ) {
		numberString = numberString.slice(2); // Remove '0o'.
		radix = 8;
	}
	
	// Check if hex
	if ( numberString.indexOf('0x') === 0 || numberString.indexOf('0X') === 0 ) {
		numberString = numberString.slice(2); // Remove '0x'.
		radix = 16;
	}
	
	for (var i=0; i<numberString.length; i++) {
		var nStr = numberString[i];
		if (nStr === '.') {
			continue; // Ignore decimal mark, or rather the radix point. Maybe a check against more than 1 of these?
		}
		var parsed = parseInt(nStr, radix);
		if (isNaN(parsed)) {
			return parsed; // Return NaN if found
		}
	}
	return parseInt(numberString, radix); // Return regular parseInt if there was no shenanigans. Note that we do not support octal numbers prefixed with 0 because it's not in the ECMAScript 5 spec, although we do support the equally non-standard prefixed with 0o. That's because the behavior prefixed with 0 is just too unreliable, while we control what happens with 0o.
}

Comments

Using WordPress Excerpts in Meta Description

For a long time I’ve been aware of the fact that few, if any, WordPress themes seemed to do anything with the META element’s description feature. I never bothered to look into a solution, especially since I never used to add excerpts to my posts half a decade ago. However, I’ve bothered to do so ever since I started notifying people about updates on Twitter. It already makes the search results much more readable if you’re looking for something in the archives of this site, and I figured I should do the same for search engines.

Some uneventful searching later I found what I was looking for, but it definitely wasn’t right for me: I’ve got a huge volume of posts without any excerpts, so printing empty descriptions no matter what would be silly at best, and besides there are more descriptions out there than merely those of posts. After all, categories and even my site itself have a description as well. The comment by Matthew Slyman was much more to my liking, which I then customized as follows:

<?php
$desc;
if ( is_single() ) {
	$desc = get_the_excerpt();
}
elseif ( is_page() ) {
	$desc = get_the_excerpt();
}
elseif ( is_category() ) {
	$desc = category_description();
}
elseif ( is_home() ) {
	$desc = get_bloginfo('description');
}
$desc = htmlspecialchars(trim(strip_tags($desc)));
if (!empty($desc)) {
	echo '<meta name="description" content="';
	echo $desc;
	echo '"/>';
}
?>

Add the whole thing anywhere in your HEAD element in header.php. If excerpts seem to be missing from pages, there’s a simple solution. If you want to reuse the code above for some reason, wrap some sort of function around it and stick it in functions.php. Enjoy.

Comments

Word Count

Since I wanted to know the actual number of words in a paper in near-MLA format and couldn’t find my previous (simple) PHP script, I reimplemented an equally simplistic word counter in Javascript. It strips out citations between parentheses. Suggestions welcome and use at your own risk.

Comments

Why Opera’s XHTML Error Handling Is Superior

I found this old, unfinished post in my drafts. I’m not quite sure when I originally wrote it, but it was over a year ago. Rather than updating the content I decided to publish it as is, as I’m not sure why I didn’t, with a small addendum at the end.


I made a little compilation of the various error messages displayed by browsers upon encountering an XML syntax error. Firefox (Gecko) has the unfriendly looking error on top, Chromium (Webkit) renders the page up to the error, but shows a large error message (albeit not at all useful like in Opera & Fx), and for Opera I included 10.10 and the latest 10.50 pre-alpha build. Note that it’s just the styles behind the error message that changed a bit: the content and helpfulness of the error message is still the same. I’ll run it down a bit more:

  • Firefox displays an error message that’s only useful if you already know sufficiently much about X(HT)ML, whereas Opera’s error message not only highlights more clearly where parsing failed — although ultimately this difference might just be one of preference. More important, its error message might just helpfully link you precisely where you need to go to learn how to avoid it. When I first started messing about with XHTML back in ’03 or so, I probably would’ve appreciated it if Opera had done that. At the time Opera behaved the same as Fx does now.
  • Chromium displays an error message that doesn’t even manage to clearly indicate what’s the problem. This compares negatively to Fx and Opera highlighting the &.
  • Chromium renders the page up to the problem, which may result in a get out of jail free card. The error message doesn’t seem very annoying, but if the error is in the middle of the page it’ll still be in the way. In my sample page it’s at the end, however. (My example page is basically a standard installation of phpGraphy on which I decided to switch to application/xml+xhtml because it claims to be more or less XHTML compliant now — I had to fix all the unclosed meta and link tags first.)
  • Despite rendering the page, you won’t be able to see the page fully in Chromium. You will with Opera’s reparse as HTML function.

I hope that clarifies why I think Opera’s handling is best, both as a user and as an author.


This blog post is now outdated. You can return to the behavior I hailed by disabling the opera:config#UserPrefs|AutomaticallyreparseXHTMLwithparsingerrorsasHTML option.

Comments

« Newer EntriesOlder Entries »