J. King

I haven't had much time to fiddle with Opera lately; I've mostly just been using it. Because of this I'm not sure whether a couple of new behaviours I've noticed started with 11.10 or 11.50 (or a mix of the two), but the changes they usher in have the potential to be far-reaching and also potentially limiting.

Put simply, zooming now appears to be... a little fucky. More specifically, zooming seems to have more side-effects than it used to, and these side effects, while sometimes beneficial, can also be harmful, and there doesn't seem to be a way around them.

window.inner(Width|Height)

Not so long ago, when one zoomed Opera would blithely continue to report an unzoomed viewport size when reading window.innerWidth and window.innerHeight. This could be a problem in some circumstances, to be sure: most of the time the "true" dimensions are not what you want, if you're zoomed in. There was a workaround which allowed one to find out what the zoomed size was, and though it was a somewhat ugly hack and wasn't always accurate, it nonetheless worked in all but the most extreme circumstances. Consequently you could get both data if you needed them.

Now things are different. Instead you now always get the zoomed size. Admittedly this is almost always what you'll want, but what if it's not? Now there's no way to get the true size, so you're stuck. This was a problem for me when writing improvements to my extension Make It So, as I've wanted to offer users the choice of ignoring the zoom level or not, but I cannot because Opera doesn't offer the tools to do it. Exposing the current and default zoom level to JavaScript would be useful, especially to user JS and extensions where the harm of abuse is easier to circumvent.

This is just the tip of the iceberg, though...

Media queries

This is something I haven't yet investigated much, but it seems as if the media query parser is also given zoomed values for width and height. As with the previous case, this is logical and even admirable in many situations, but also not necessarily what you want. As a trivial example, if I zoom Choose Opera as little as 220% with my usual viewport, it changes to a mobile-tailored layout which is absolutely nothing like what I'm trying to zoom in on. If what I want to do is actually zoom in on detail, I could be entirely thwarted because the detail could very well disappear. That is, to put it plain, not a good thing.

I'm not sure how one might best handle this situation. As I implied above, media queries acting on zoomed pixel values could in many situations be quite beneficial, but unlike with the JS values, it's not something you can really program around in a pinch. You'd either need to add query features (eg. (un?)zoomed-width), add some kind of switch to CSS or leave control solely in the hands of the user and add an Opera preference.

As rapidly becomes apparent, this isn't pretty. Thoughts welcome.

Conclusion

Ook.

In other words, I do wonder why zoom hasn't been more thoroughly embraced as a first-class component of Web UI. For many years full-page zooming was a quirk of Opera (and a wonderful one at that!), but now it's a pervasive feature, present in all of the common agents. Why, then, are there no standardized APIs of any kind to more intelligently work with zooming? Neither the editor's draft of Media Queries nor of CSSOM View mention zooming even once. I don't know about everyone else, but I find that's extremely surprising. I also find it's a bit of a problem.

3 comments

Retaining one's sanity, or removing lightboxes with user JavaScript

Wednesday, September 10, 2008 10:23:45 PM

The other day my girlfriend pointed me to the Web site for an upcoming graphic adventure game, viz. Everlight and expressed frustration that she could not save the screenshots viewable thereon. I looked for myself, and cursed at the scourge of my existance, lightboxes. Galvanised, I committed to eradicating these lightboxes from my Web browsing experience through the godly magic of user JS.

Initially I thought of removing the markup hooks which trigger the lightbox functionality, but as I brushed up on user JS functionality I realised I could easily suppress the lightbox script entirely. Thus, I did this, preventing "slimbox.js" from executing, and "lightbox.js" along with it. But still not satisfied I searched for other variants of the lightbox concept and in due course found the Lightbox Clone Matrix which allowed me to block nearly all of them, many of which I'd never even heard of.

The code I finally came up with is this:

//  remove lightboxen
//  See http://planetozh.com/projects/lightbox-clones/ for list.
//  Script handles all as of 2008-09-06 except Prototype Window and Control Window
window.opera.addEventListener('BeforeExternalScript', function(ev)
 {if(ev.element.src.match(/((light|slim|grey|thick|lite|awesome|face|fancy|float|image|lyte|milk|moo?dal|multi|roe|shadow|smooth|swf|tiny|talci|weeb|i)box|enlargeit|fancyzoom(html)?|highslide|light(view|window)|(sub|nyro)modal|prettyphoto)([\.\-_](new|plus|[\d\.]*\d)|\+\+)?([\.\-_](uncompressed|compressed|pack))?\.js\b/i))
   ev.preventDefault();
 }, false);

Very little testing has gone into this, but it seems to work well enough for me. I know my colleague Dustin Wilson has found it a godsend (does that make me god?), so hopefully it will be useful for others as well!

1 comment

Stylesheet waste

Wednesday, June 18, 2008 8:22:12 PM

One thing that has bugged me about vanilla Opera for a while (since 8.0, maybe?) is the colouring of quoted text in e-mail, which changed at some point from 7.0's pleasant colours which I have grown disturbingly accustomed to, to wishy-washy colours largely reversed from what I'd come to know (a disorienting experience, to be sure).

Apparently this was changed for accessibility reasons. Fine, but I don't have to like them! I don't have to use them, either!

For a while (ie. several years) I've been toting around a (modified) MIME stylesheet from Opera 7.2, but when doing a manual upgrade to Opera 9.5, I lost the stylesheet due to my own negligence.

Therefore I sat down today, grabbed a stylesheet from a Linux .tar.gz package of Opera 7.5, and started tweaking. Changing the colours of the text was trivial enough, but this resulted in a curious visual artefact:

This fun little mix-up is caused by the following style rules being used in Opera 9.5's MIME stylesheet:

omf|ql.L1, omf|ql.L7, omf|ql.L13, omf|ql.L19, omf|ql.L25, omf|ql.L31 
 {color: hsl(218,49%,43%);}
#flowed omf|ql.L1, #flowed omf|ql.L7, #flowed omf|ql.L13, #flowed omf|ql.L19, #flowed omf|ql.L25, #flowed omf|ql.L31 
 {border-left-color: hsl(218,49%,43%);}

... as well as a number of similar rules which define the other cascading colours. That the text and border colours are defined in separate rules is fine; that I would need to change a whole bunch because of the different colours is fine, too, except that I don't need to! Indeed, this one rule will do the trick regardless of quoting depth:

#flowed omf|ql {border-left-color: currentColor;}

What's in the stylesheet right now is a pain and a waste. Is there a good reason I'm not aware of why it should remain as-is?

No comments

IE=fu^2

Thursday, January 24, 2008 8:30:30 PM

Much has been said about this whole IE metadatum nonsense, be it from implementors, authors, specification editors or interested parties. For what it's worth, I'm vehemently opposed to the switch as implemented. For those paying attention, this doesn't mean I'm necessarily opposed to a second quirks switch in theory, but how Microsoft chose to go about it is, to put it kindly, short-sighted.

The beauty of the original quirks switch is simple to appreciate: it depended on authors doing something they would probably want to do anyway: identify the schema of their document for validation purposes. This proposed switch, however, depends on authors doing something they would not otherwise need or want to do, for absolutely no other reasons than making Internet Explorer behave as it should in the first place. This, conceivably, until the end of time.

Never mind the additional difficulties this introduces for future interoperability; never mind how it could perhaps stifle competition; never mind that it either relies on a proprietary HTTP header-field or an attribute that no longer exists in HTML5 as currently drafted: worse, it raises the barrier to entry for all authors, everywhere, regardless of which user-agent they use, until the end of time, simply because Microsoft can't fix its problems with one CSS-based layout engine out of about a dozen I'm aware of. This is unacceptable.

For authors, the HTML4 and XHTML doctypes were difficult enough to deal with; certainly, I could never manage to memorize even the URI of one of the schemas, never mind all the dashes and slashes and other garbage that goes before the schema URI, and I'd feel very sorry for anyone who has felt compelled to memorize all the relevant doctypes.

Besides doctypes, there is also the error-prone metadatum syntax for character encoding detection and the attribute-filled link element for stylesheets. This is already an unreasonably high amount of arcane, seemingly cargo-cultish cruft one most have at the top of a hypertext document for it to work properly.

HTML5 gives us a light at the end of the tunnel by greatly simplifying the form of doctypes and character encoding specification, but now we have Microsoft shambling along and foisting upon us more cruft instead of less. And for what? All because they are either unwilling to bite the bullet and fix their engine, or too lazy to take a few minutes to come up with a non-intrusive way of getting themselves off the hook.

Writing HTML is hard enough already, guys; either help, or fuck off. Thanks.

[Post Scriptum: My colleague Dustin Wilson has also written on the matter in his endearing style. More importantly, he actually took the time to reference a number of other opinions on the matter as well as the original anouncement itself.]

No comments

Over-the-air digital television: the great experiment (continued)

Saturday, May 26, 2007 2:11:12 AM

Today we had a television antenna installed onto the back of our roof. It was a rather lengthy process, but thankfully we weren't the ones doing it. In any case, I'm glad to report that, this time, we have excellent reception! With fourteen digital channels and seventeen analogue channels, we couldn't be happier.

The antenna itself is a little ugly (VHF antennae are by necessity), but it works very well. I'd recommend it (and those who installed it, AF Marsh) to anyone in the Toronto area.

No comments

Feeling the Rush

Tuesday, May 15, 2007 9:24:41 PM

Rush have for many long been the definition of Canadian rock music. In my case, though, I had not heard Rush until a couple of years ago, when my brother played 2112 for me. I was instantly blown away. From the eerie and titillating opening instrumental; to the loud, warbling priests; to the bright-eyed man's first experiments on his new-found treasure; all the way to the ominous ending, the album's title track was an amazingly bountiful feast for a science-fiction fan like myself. This, coupled with the other excellent offerings on the disc prompted me to find more Rush and embrace their excellence as if it were my patriotic duty.

Since, I have purchased many albums from the 1970s, and a few from the 1980s. Although I enjoyed Rush's 80s sound (especially on Grace Under Pressure), I preferred the 1970s segment of their body of work, perhaps in large because they had many over-long songs like the aforementioned 2112 and Xanadu from A Farewell to Kings (just to name two). Today I may have to revise my opinion.

Earlier I started listening to Hold Your Fire. Although this had not been my first time listening to it, it was my first time listening from beginning to end. I can easily say that each track on the album is at least good; many are excellent. The last two tracks, Tai Shan and (especially) High Water lift my spirits as little has been able to do these days; they alone are worth the modest purchase price of the album.

I wouldn't say that I prefer 1980s Rush necessarily, but I can safely affirm that it no longer plays second fiddle to its earlier kin. If you're someone who is not afraid of a few synthesizers, I would definitely recommend getting Hold Your Fire. You shall not be disappointed.

No comments

Well, it is only ten years old

Tuesday, May 8, 2007 10:10:30 PM

Over the last few days I have been, for reasons I myself am not entirely sure of, researching free graphic editors. I don't generally do much graphic editing; I just don't have the knack for visual stuff. However, I do occasionally do some touch-ups, croppings and whatnot.

If there's one thing that can be said about me, it's that I have an almost zealous love for good, free, public technologies. Whether it be HTML, CSS, Atom, Jabber, Vorbis, FLAC, SVG (although I hesitate to call SVG good) or any number of other wonderful little goodies, I'll latch on and probably never let go. Thus is the case with PNG.

Adoption of PNG over the last decade of its existence has been quick in some circles and torturously slow in others; most notably, Internet Explorer gained a suitably complete (though still buggy) implementation just last October. Generally, though, Web browsers today have no major troubles with PNG. The picture, on the other hand, is a little different when it comes to editors.

One of the more useful and famous features of PNG is what is called alpha blending: any pixel in a true-colour image can be partially (or completely) transparent. This becomes especially useful on the Web, when it's advantageous for images to be able to blend in with arbitrary backgrounds. Less known, however, is the fact that a very similar feature exists for paletted images: any colour in an image's palette can have a level of transparency associated with it. Instead of, say, having a monochrome image with only black and transparent, you could have four blacks, one of them opaque, another 25% transparent, a third half-transparent and a fourth mostly transparent so that the edges of the visible pixels are smoothed out. Thus, you have all the size advantages of GIF without the jagged edges.

Unfortunately only one image editor I know of, Adobe (formerly Macromedia) Fireworks, implements this immensely useful feature. Having tried over two dozen free and freeware editors for Windows (yes, including The GIMP) over the past few days, I found not a single one that will produce proper paletted images, and few that will even read them. If one doesn't have the money for Fireworks or is using Linux, the only option appears to be pngquant, which doesn't exactly give one easy control over which colours will end up in the palette.

It seems strange to me that with so many obvious benefits this feature isn't given more attention and love. I guess I shouldn't be too surprised, though: PNG is only ten years old.

5 comments

SVG interoperability

Monday, April 30, 2007 3:54:10 AM

SVG is curious technology. In simple terms it was designed to drawn various shapes, especially useful if one aims to draw a diagram or chart. Most of the basic shapes are trivial to "draw" by hand, writing the appropriate markup in a text editor rather than using a drawing program. These same basic shapes also have fairly intuitive presentational attributes that can alter the appearance of the shape in question, all of which can be written without too much difficulty. However, there are several subtle problems which end up making hand-authoring of SVG a largely intractable option:

First of all, while drawing shapes is trivial, positioning shapes on the canvas and aligning them relative to each other is at best tedious, mostly quite difficult, and often practically impossible. Because the different kinds of shapes in SVG are drawn in different ways, it's often difficult to tell what is exactly where. Circles are drawn using a centre point and a radius; rectangles are drawn using an upper-left corner and a width and height; text is drawn using a point for the first character's baseline; other shapes are usually drawn by specifying a series of absolute points.

All these disparate drawing methods mean that it's often difficult to tell just how much space a given component of your drawing is going to take up, or even where on the canvas it happens to be! Considerable mental gymnastics are required to keep track of all the numbers required to position just a handful of elements; the mathematics required for even a vaguely complex drawing are too much for me to even imagine.

To make matters worse, aligning text is made that much more difficult when font substitution takes place, or if by some chance a user-agent sets a minimum or maximum font size, or if the drawing's font style is otherwise changed in some way. The textArea element helps somewhat in this regard, but that's just more numbers to keep track of.

At this point one might be tempted to cry out "Just use an editor!" or (if one is feeling particularly helpful but also a touch irate) "Download Inkscape and shut up, you fucking whack-job!". Aye, I would feel quite tempted to utter such phrases myself if I had no concern for the byte-for-byte size of my SVG drawings. That's a whole other can of worms, though:

I've tried a handful of vector-drawing programs, from Adobe's heavy yet featureful Ilustrator, to the clunky yet focused Inkscape, to more obscure pieces of software that merely export SVG, locking my source drawings into proprietary formats. Without exception, the drawings they produce are fat, fragile monstrosities that mix and match different requirements, hindering interoperability. Indeed, a long-standing habit of Illustrator involved defining namespace URIs as character entities, which are often not parsed by XML processors. Some ditors also thoroughly enjoy silently embedding bitmap thumbnails of the drawing itself, or references to hidden or previously removed shapes or images. An SVG drawing produced by Inkscape, even when saved as "plain" SVG, can easily be twice the size of the same drawing produced by hand.

In the end, I think SVG needs facilities for positioning shapes using more than one method for each kind of shape. It would help if I could position a rectangle using a center point; easily draw a line using a single point, a direction and a length; or plot an arbitrary point solely for the purposes of giving it an ID.

Probably, though, I'll just have to put up with fat SVGs. Either that, or I'll have to spend the rest of my life writing a gargantuanly complex post-processor to clean SVGs up. I think we can all guess which route I will take.

1 comment

Over-the-air digital television: the great experiment

Thursday, April 26, 2007 7:38:35 PM

Today I received my digital television tuner care of Khadgar, who was kind enough to order it and ship it from the United States on my behalf. After two weeks of wait and not-inconsiderable expense, however, I must sadly report that it is, as yet, something of a disappointment. Whereas we managed to receive half a dozen channels on our ground-floor television and seventeen channels from my brother's television on the second floor in our analogue tests, the extent of our digital reception is less than ten channels from my brother's second-floor bedroom, and only a single channel from the ground floor (namely CBC). As the ground floor is the tuner's intended destination, this is an unacceptable outcome, and comes as a great disappointment.

We are not opposed to the notion of acquiring an outdoor antenna and pointing it south in the direction of Buffalo, but this entails further expense, and will require us to further research the technology, as well as how we might go about running coaxial cable. I'm not too worried, as this is all dealing in fixed costs, but I was hoping that we could simply enjoy free TV without any more effort. Not so, I suppose.

No comments