W3C home > Mailing lists > Public > www-archive@w3.org > September 2011

Image blurring bookmarklet

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Fri, 16 Sep 2011 05:08:44 +0200
To: www-archive@w3.org
Message-ID: <u5757792u9km1v9magrhprvh65tcj89ob7@hive.bjoern.hoehrmann.de>

  The Wikipedia "Board of Trustees" has decided that Wikipedia readers
need an option that hides from their view multimedia that they, or who-
ever pressures them into using it, ought not to be exposed to, and they
recently concluded a fig leaf poll where editors could rate importance
of this feature being added by choosing among ten integers. The idea is
that editors are to fight over which censorship label should be added
to multimedia content so readers can choose among a few categories what
better not invade their personal filter bubble.

In response the German Wikipedia asked high profile contributors (with
more than 200 edits in the article namespace, 50 of which less than one
year old, the standard criteria to participate in this kind of thing)
if this functionality is desired for the German Wikipedia. The outcome
was very clear, among the 430 who participated and met the requirements
to participate, over 86% voted against introducing this feature.

I wonder if there will be a Jimbo setting, so you don't have to see the
face of Jimmy Wales ever again. That is the filter setting I already use
by way of manual configuration and I am quite happy with it.

It http://meta.wikimedia.org/wiki/File:Importance_votes_vertBarChart.png
is interesting to note that in the global poll procentually more people 
considered addition of this feature to be of the highest importance than
there were high profile editors (the global poll required just ten edits
in any wiki) who favoured this for the german Wikipedia. Unfortunately,
as far as I am aware, there are no proper breakdowns detailing where the
supporters came from or what their wiki seniority levels might be.

I have not seen a proposal for a plausible process that would allow the
editors to find some consensus on how they classify content, especially
not if this is to happen mainly on Wikimedia Commons which is shared by
all the projects for multimedia hosting. Consider that editors who don't
agree with having this feature at all would likely oppose classification
into the censorship http://meta.wikimedia.org/w/index.php?oldid=2858656
categories, so you are unlikely to get anything resembling consensus for
images where it matters (they have to actually be used in articles). A
simple majority based system would not work either if the german results
vaguely reflect how the most active wikipedia communities see it. And a
representative system, elected censors, would face the same problem.

A minority regime is easily abused, you'd have organized troll groups
flagging everything making the filter perform poorly in addition to the
general friction problems. Looking at it from the other direction, if it
was likely that editors agree on wish images should be hidden, they are
also fairly likely to agree that the images should not appear in the
articles themself. http://en.wikipedia.org/w/index.php?oldid=450276263
for instance has a fairly innocent cartoon illustrating Arachnophobia,
and no intimidating monster spider pictures.

If you compare the "Vulva" articles in various language versions, you'll
find that some have no images, some only drawings, while others feature
extensive photography. In part this is related to the state of develop-
ment of the article, a stub is less likely to feature photography, but
it also seems to match cultural stereotypes, possibly with nuances, like
photography being featured at later points in the article, so if you'd
get to the article unsure what to expect, it's basically your fault if
you scroll too far down. Related would be policies on spoilers for story
media like movies and literature. If you read the Plot section, well.

The english Wikipedia in this sense is a bit of a problem, as it serves
as a hub across cultures (like some other language versions, but to a
lesser extent generally). But then that is what one should expect when
using it, it's derived from culture that's different from one's own.

With the mockup above I would also have no idea what would go into cate-
gories like "Medical". So I just loaded en:Leg. The article is quite im-
pressive in how poorly worked out it is, but anyway, it features a car-
toonish insect leg. In contrast, de:Untere_Extremität [sic] has photos
of a horse leg, wolf leg, and human leg, featuring the human's behind.
While featured from the side, the human is clearly fairly naked, unsure
if that http://commons.wikimedia.org/wiki/File:Beine.JPG counts as nudi-
ty or sexually explicit.

It's also interesting to note that, with nuance and modestiy in picture
selection and placement as discussed above, having such a filter would
drive picture selection. Editors might want to use only images that have
been filter-approved, which would then affect people who do not want to
have the filter experience.

Well, I don't really understand what problem is to be solved with this
exactly, so far I have not seen much data that would explain what types
of issues users face here, it's obvious that editors would disagree with
having such a feature, and a neutral point of view can't really allow
for subjective image classifications. The alternative idea to deal with
this silliness is to allow for an option to hide all images.

I certainly haven't read all of the coverage and discussions, but so far
I haven't come across someone suggesting what I would find the most ob-
vious simple solution, namely to obscure all images and show them when a
user hovers over the image (or performs some other action with devices
or other conditions where hovering is not easily available). Clearly, it
would not make people who want easy content but also not have their sen-
sibilities affected very happy if they have to hover images, or if they
are constantly reminded they are using this option, but they would get
this anyway short of them organizing the censor list with like-minded
people, which would seem a far more viable solution, to a point where it
is quite reasonable to argue that because this does not exist already,
we can fairly assume there is no actual demand for this feature.

Anyway, I wondered how many minutes it would take to write a script that
blurs all images client-side and reveals them when hovering, and so I
wrote the following (you can ender this in whatever Console your browser
offers, though I have only tested it with Opera and Firefox; note that
the element selection code is designed for Wikipedia, not other sites):

  var replace = function(img)  {
    var svgns = 'http://www.w3.org/2000/svg';
    var xlink = 'http://www.w3.org/1999/xlink';
    var imgid = img.src.replace(/[^a-zA-Z0-9]+/g, '');
    var svg = document.createElementNS(svgns, "svg");
    svg.setAttributeNS(null, "width", img.width);
    svg.setAttributeNS(null, "height", img.height);
    var filter = document.createElementNS(svgns, "filter");
    filter.setAttributeNS(null, "filterUnits", "objectBoundingBox");
    filter.setAttributeNS(null, "width", "120%");
    filter.setAttributeNS(null, "height", "120%");
    filter.setAttributeNS(null, "id", imgid);
    var blur = document.createElementNS(svgns, "feGaussianBlur");
    blur.setAttributeNS(null, "in", "SourceGraphic");
    blur.setAttributeNS(null, "result", "blur");

    // This might need to depend on image dimensions
    blur.setAttributeNS(null, "stdDeviation", "8");
    var image = document.createElementNS(svgns, "image");
    image.setAttributeNS(null, "width", img.width);
    image.setAttributeNS(null, "height", img.height);
    image.setAttributeNS(xlink, "xlink:href", img.src);
    image.setAttributeNS(null, "filter", "url(#" + imgid + ")");
    image.setAttributeNS(null, "class", "blurred");
    img.parentNode.insertBefore(svg, img);
  var style = document.createElement("style");
  style.setAttribute("type", "text/css");
  style.textContent = ".blurred:hover { filter: none }";
  [].forEach.call(document.querySelectorAll(".image img"), replace);

What I found is that this takes a whole lot longer to write than it used
to take to write the equivalent for Internet Explorer 5.5 a decade ago.

Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Friday, 16 September 2011 03:09:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:18:39 GMT