A proposal to simplify and improve image markup in Wikipedia

List overview All Threads
Download

newer

older

ANNOUNCE: OpenStreetMap maps will...

Accessibility 101

Håkon Wium Lie

3 Apr 2009 3 Apr '09

10:44 a.m.

I've spent the last few days analyzing Wikipedia's HTML code for images and captions. The current code is quite good, but verbose and it has redundancies. Here is a proposal that describes how to simplify and improve the code: http://www.princexml.com/howcome/2009/wikipedia/image/ The proposed solution reduces the number of elements from 10 to 6 and the code size is reduced by more than 50%. Cheers, -h&kon Håkon Wium Lie CTO °þe®ª howcome(a)opera.com http://people.opera.com/howcome

Show replies by date

Tei

3 Apr 3 Apr

11:42 a.m.

On Fri, Apr 3, 2009 at 12:44 PM, Håkon Wium Lie <howcome(a)opera.com> wrote:

...

neato!, this article could have been better with <s>some</s> more study of compatibility with old browsers. also, nice image :-) postdata: img[alt=enlarge] enlarge is english, I wonder if must/is different on other mediasites in spanish seems "Aumentar" http://es.wikipedia.org/wiki/Lupa -- -- ℱin del ℳensaje.

Håkon Wium Lie

2:24 p.m.

Also sprach Tei:

...

neato!, this article could have been better with <s>some</s> more study of compatibility with old browsers.

I've tested in IE6, IE7, IE8, Opera 9, FF2, FF3. The problems I have found are noted in the paper: - IE6 doesn't support attribute selectors, but the problems i minor - only Opera suport the 'content' propoerty as per CSS3, so it's not quite ready for use Cheers, -h&kon Håkon Wium Lie CTO °þe®ª howcome(a)opera.com http://people.opera.com/howcome

ABCD

12:02 p.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Håkon Wium Lie wrote:

...

Some quick criticisms:

...

The width of the element is set on a class ("w180") instead of using a style attribute. Wikipedia offers thumbnail images in six different sizes (120px, 150px, 180px, 200px, 250px, 300px) and this number is low enough to use classes. The main benefit of using classes is that alternative style sheets can change the presentation, e.g., for printing purposes. The style attribute, on the other hand, can never be overridden.

Actually, you can set the width to any value you wish in the input document, which would cause problems with your suggestion. ([[File:Example.png|123px|thumb|Some text.]] will always display at 123px wide, no matter what preferences are used). Also, as someone else already mentioned, the string "Enlarge" can be changed by local admins (at [[MediaWiki:Thumbnail-more]]), and is language dependent - users can change their interface language at any time, either via Special:Preferences, or by appending ?uselang=foo or &uselang=foo to the URL. Otherwise, this seems to be well presented. - -- ABCD

...PGP SIGNATURE...

-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknV+vEACgkQOypDUo0oQOoDkgCbB4j1eo0KHznoRowjiDa718ZA JlsAn1EBZF8v2XMRHwU98CGNbqusIxNb =j0J9 -----END PGP SIGNATURE-----

Håkon Wium Lie

2:31 p.m.

Also sprach ABCD:

...

Right. In this case, using a style attribute would probably be the only viable solution. But this is rare, no? If we can eliminate 99% of style attributes, I'm happy. Is there any way to count those that specify exact widths?

...

Also, as someone else already mentioned, the string "Enlarge" can be changed by local admins (at [[MediaWiki:Thumbnail-more]]), and is language dependent - users can change their interface language at any time, either via Special:Preferences, or by appending ?uselang=foo or &uselang=foo to the URL.

This is a good point. Having a class attribute may be better than trying to keep a list of language-specific selectors up to date. However, I'm proposing to drop the magnifier icon altogether.

...

Otherwise, this seems to be well presented.

Thanks, -h&kon Håkon Wium Lie CTO °þe®ª howcome(a)opera.com http://people.opera.com/howcome

Jim

2:43 p.m.

On Fri, Apr 3, 2009 at 10:31 AM, Håkon Wium Lie <howcome(a)opera.com> wrote:

...

Also sprach ABCD:

Actually this is not only rare but discouraged. Widths should only be specificed in unusual cases (such as very wide or very tall images). Using classes for the standard thumb widths is an excellent suggestion and then the use of styles for unusual situations would be the exception it should be. In other words we shouldn't base our decision to use a less flexible formatting feature because of rare exceptions. -Trodel

Roan Kattouw

12:35 p.m.

2009/4/3 Håkon Wium Lie <howcome(a)opera.com>om>:

...

Another point of criticism: the article seems to study thumbnails (images generated with [[Image:Foo.jpg|thumb]]) exclusively. Images without the thumb attribute are rendered differently (no caption, no wrapper div, no magnifier icon), so you might wanna take a look at those as well. Roan Kattouw (Catrope)

Håkon Wium Lie

12:45 p.m.

Also sprach Roan Kattouw:

...

> http://www.princexml.com/howcome/2009/wikipedia/image/

...

Yes. It seems that thumbnails are used more than other images so I started there. (Is there a way to count?) Here's a list of the things I'd like to study: - non-thumb images and other figures - multi-column text - the style sheets All in the context of Wikipedia, naturally. My hypothesis is that the current HTML code can be simplified and improved by relying more CSS. The benefits are reduced code size (what's the bandwidth of Wikipedia?) and easier reuse of the content. Cheers, -h&kon Håkon Wium Lie CTO °þe®ª howcome(a)opera.com http://people.opera.com/howcome

Chad

12:47 p.m.

On Fri, Apr 3, 2009 at 8:45 AM, Håkon Wium Lie <howcome(a)opera.com> wrote:

...

My hypothesis is that the current HTML code can be simplified and improved by relying more CSS. The benefits are reduced code size (what's the bandwidth of Wikipedia?) and easier reuse of the content.

/me waits for the obligatory "omg think of the text browsers" comments -Chad

Håkon Wium Lie

1:17 p.m.

Also sprach Chad:

...

/me waits for the obligatory "omg think of the text browsers" comments

It's a good question. Text browsers will generally do better with simplified markup. For example, lynx works much better with the dt/dd-based markup proposed here: http://www.princexml.com/howcome/2009/wikipedia/infobox/ than the current nested-table approach. So, when I say "rely more on CSS", I mean rely more on CSS for *styling* and leave the semantics to HTML. Cheers, -h&kon Håkon Wium Lie CTO °þe®ª howcome(a)opera.com http://people.opera.com/howcome

David Gerard

1:26 p.m.

2009/4/3 Chad <innocentkiller(a)gmail.com>om>:

...

On Fri, Apr 3, 2009 at 8:45 AM, Håkon Wium Lie <howcome(a)opera.com> wrote:

...

> My hypothesis is that the current HTML code can be simplified and > improved by relying more CSS. The benefits are reduced code size > (what's the bandwidth of Wikipedia?) and easier reuse of the content.

...

/me waits for the obligatory "omg think of the text browsers" comments

And the speech browsers. Thankfully, if something looks good in Lynx it'll generally work spoken. (/me awaits barrage of counterexamples) CSS is *good* for text browsers. Certainly better than what Lynx does with tables. - d.

Stephen Bain

2:22 p.m.

On Sat, Apr 4, 2009 at 12:26 AM, David Gerard <dgerard(a)gmail.com> wrote:

...

2009/4/3 Chad <innocentkiller(a)gmail.com>om>:

/me waits for the obligatory "omg think of the text browsers" comments

And the speech browsers.

Indeed. That's always going to be a small portion of the user base but it's very important that things work for such browsers.

...

From the point of view of such users removing the alt attributes on

images is a bad idea. -- Stephen Bain stephen.bain(a)gmail.com

David Gerard

2:28 p.m.

2009/4/3 Stephen Bain <stephen.bain(a)gmail.com>om>:

...

On Sat, Apr 4, 2009 at 12:26 AM, David Gerard <dgerard(a)gmail.com> wrote:

...

> And the speech browsers.

...

Indeed. That's always going to be a small portion of the user base but it's very important that things work for such browsers. From the point of view of such users removing the alt attributes on images is a bad idea.

Only from images without captions - the alt text and title text are presently the caption. So you could presently hear it three times. - d.

Håkon Wium Lie

2:39 p.m.

Also sprach Stephen Bain:

...

And the speech browsers.

Indeed. That's always going to be a small portion of the user base but it's very important that things work for such browsers.

Agreed.

...

From the point of view of such users removing the alt attributes on images is a bad idea.

Note that Wikipedia's current markup for thumnnail images only use one alt attribute and it's empty: <div class="thumb tleft"> <div class="thumbinner" style="width:182px;"> <a href="/wiki/File:Bryggen_(6-2007).jpg" class="image" title="Bryggen in Bergen is on the list of UNESCO World Heritage Sites."> <img alt="" src="http://upload.wikimedia.org/wikipedia/commons/thumb/ The only reason for keeping it is to claim validity wrt. some DTDs. Personally, I'd rather remove it. Cheers, -h&kon Håkon Wium Lie CTO °þe®ª howcome(a)opera.com http://people.opera.com/howcome

ABCD

4:32 p.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Håkon Wium Lie wrote:

...

Note that Wikipedia's current markup for thumnnail images only use one alt attribute and it's empty:

[snip]

...

The only reason for keeping it is to claim validity wrt. some DTDs. Personally, I'd rather remove it.

Having an empty alt= attribute also causes the image to be completely invisible in (some?) text browsers, notably Lynx. If there is no alt= attribute, then it appears as [Image], which I do not believe is desired. - -- ABCD

...PGP SIGNATURE...

-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknWOjsACgkQOypDUo0oQOp0SACgiryCpRwe+Suf4q9Ox6rRwyzl KhMAoLpnhTfoshZ3qocyHnpk0nJvyC6a =JB4d -----END PGP SIGNATURE-----

ABCD

4:35 p.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ABCD wrote:

...

Håkon Wium Lie wrote:

Note that Wikipedia's current markup for thumnnail images only use one alt attribute and it's empty:

[snip]

The only reason for keeping it is to claim validity wrt. some DTDs. Personally, I'd rather remove it.

Ignore that, I misread.... - -- ABCD

...PGP SIGNATURE...

-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknWOu4ACgkQOypDUo0oQOqVLACcD4E4abq9uTpE19K7xZA/MlW7 grcAn3s1XK2ZEgEkcukjWPZs3lBJqW54 =H/YH -----END PGP SIGNATURE-----

Aryeh Gregor

2:51 p.m.

On Fri, Apr 3, 2009 at 6:44 AM, Håkon Wium Lie <howcome(a)opera.com> wrote:

...

As others have noted, the thumbnails can actually be any size, so we really do need to use style="" for that (or at least height/width on the <img>). I guess we could use a class for the relatively common case, but I don't see the gain, honestly. I noticed you removed the " /" closing the <img> tags -- we use XHTML 1.0 for the moment, so we have to keep that (four more bytes! :) ). For the same reason, we need to keep alt="" -- it's stupid, since really the semantics we want is "we have no idea what the alt text should be since the users didn't specify it" rather than "this deserves no alt text", but we don't have any way to express the former in XHTML 1.0. We currently do have the goal of maintaining XHTML 1.0 conformance where possible, stupid though it may be at times. I'm not sure about the "enlarge" icon. It might not be intuitive that clicking on the image expands it. The icon itself might not be so great either, though. Personally, I won't remove that for now. I agree that the title attribute is pointless if there's a caption -- removing that would be good. (If I can figure out how. The code for this is *awful*. So not this second.) I removed the border="0" in r49154. The rest (i.e., the bulk of the proposal) is more complicated and will require more care to implement, which I can't give at this exact second. On Fri, Apr 3, 2009 at 10:22 AM, Stephen Bain <stephen.bain(a)gmail.com> wrote:

...

From the point of view of such users removing the alt attributes on images is a bad idea.

If an empty alt attribute and a nonexistent one are handled differently by anything, I'd guess a nonexistent one would be handled better, not worse, for our semantics. But XHTML requires the attribute, in any event.

David Gerard

3:55 p.m.

2009/4/3 Aryeh Gregor <Simetrical+wikilist(a)gmail.com>om>:

...

I'm not sure about the "enlarge" icon. It might not be intuitive that clicking on the image expands it. The icon itself might not be so great either, though. Personally, I won't remove that for now.

There's a proposal (which I'm supposed to be pushing forward) to use a more obvious magnifier, e.g. a small magnifying glass with a circle-i next to it. (One icon that looks like two, since it has two functions. There was enough bikeshedding over the proposal that the next stage is a proper UI test.) - d.

Håkon Wium Lie

9:19 p.m.

Also sprach Aryeh Gregor:

...

http://www.princexml.com/howcome/2009/wikipedia/image/ The proposed solution reduces the number of elements from 10 to 6 and the code size is reduced by more than 50%.

The gain is that the code is easier to reuse. When style is set through a class name, it can be overridden by another style sheet. For example, when creating these samples: http://www.princexml.com/samples/#wiki I wrote a style sheet that used the class names and attached new styles to them. Given a class name like "w180" I could write a new rule, e.g.: .w180 { width: 90px } Style *attributes* -- on the other hand -- are much harder to deal with. They always win in competition with other conflicting rules. Many of them are screen-centric so one is forced to ignore them for other media. When the style attribute is ignored, there is no hook to attach style to. It seems to me that setting the exact width is a rare exception, and one that shouldn't stand in the way of reusing content. Setting the height/width on the image is, unfortunately, not ennough -- the width of the container box must also be constrained. Otherwise, it will be widened by the caption.

...

I noticed you removed the " /" closing the <img> tags -- we use XHTML 1.0 for the moment, so we have to keep that (four more bytes! :) ). For the same reason, we need to keep alt="" -- it's stupid, since really the semantics we want is "we have no idea what the alt text should be since the users didn't specify it" rather than "this deserves no alt text", but we don't have any way to express the former in XHTML 1.0. We currently do have the goal of maintaining XHTML 1.0 conformance where possible, stupid though it may be at times.

Understood. Cheers, -h&kon Håkon Wium Lie CTO °þe®ª howcome(a)opera.com http://people.opera.com/howcome

Aryeh Gregor

9:30 p.m.

On Fri, Apr 3, 2009 at 5:19 PM, Håkon Wium Lie <howcome(a)opera.com> wrote:

...

Except by using !important, which is of course the point of !important.

...

Many of them are screen-centric so one is forced to ignore them for other media. When the style attribute is ignored, there is no hook to attach style to. It seems to me that setting the exact width is a rare exception, and one that shouldn't stand in the way of reusing content.

I don't know. I guess so. We could special-case the default permitted widths as classes.

Håkon Wium Lie

6 Apr 6 Apr

10:19 p.m.

Also sprach Aryeh Gregor:

...

.w180 { width: 90px } Style *attributes* -- on the other hand -- are much harder to deal with. They always win in competition with other conflicting rules.

Except by using !important, which is of course the point of !important.

Yes, that's possible.

...

It seems to me that setting the exact width is a rare exception, and one that shouldn't stand in the way of reusing content.

I don't know. I guess so. We could special-case the default permitted widths as classes.

That would be very helpful. It would make it much easier to create, say, a four-column printed encyclopedia where thumbnail images must be scaled. Cheers, -h&kon Håkon Wium Lie CTO °þe®ª howcome(a)opera.com http://people.opera.com/howcome

Brion Vibber

3 Apr 3 Apr

10:39 p.m.

Håkon Wium Lie wrote:

...

It seems to me that setting the exact width is a rare exception, and one that shouldn't stand in the way of reusing content.

Assume that it'll be used very frequently and that it should not break. (Would be interesting if someone wants to do a survey, but I rather suspect a lot of templates and one-off uses alike are setting sizes explicitly; I know pretty much every image I use in a wiki page is set this way.) -- brion

David Gerard

10:45 p.m.

2009/4/3 Brion Vibber <brion(a)wikimedia.org>rg>:

...

Håkon Wium Lie wrote:

...

> It seems to me that setting the exact width is a rare exception, > and one that shouldn't stand in the way of reusing content.

...

Yes. And, although the primary user of MediaWiki is Wikimedia, please don't break things for third party users of the software! (At this point we get into the tricky twists and turns of what's "software" and what's "user settings" and how the two stipple into each other.) - d.

Håkon Wium Lie

4 Apr 4 Apr

11:50 a.m.

Also sprach Brion Vibber:

...

It seems to me that setting the exact width is a rare exception, and one that shouldn't stand in the way of reusing content.

Assume that it'll be used very frequently and that it should not break.

If necessary, you use a style attribute. That solution will always be there, but it is not welcoming to reuse.

...

(Would be interesting if someone wants to do a survey, but I rather suspect a lot of templates and one-off uses alike are setting sizes explicitly; I know pretty much every image I use in a wiki page is set this way.)

Like here: http://en.wikipedia.org/wiki/Light_meter Your markup is: [[Image:Digital ambient light meter.jpg|145px|thumb|right|A handheld digital ambient light meter, showing an f-stop of 5.6 for 24 frame/s 500 ISO filming]] I'm curious about your reasons for setting 145px, though. Is it because the original size is 145px and you don't want it to be enlarged? If so, wouldn't it be better to indicate this in some other way, e.g. a 'no-enlarge' class name? Or, are also insisiting that users always see it with a width of 145px? Even on a tiny cellphone screen? -h&kon Håkon Wium Lie CTO °þe®ª howcome(a)opera.com http://people.opera.com/howcome

David Gerard

12:06 p.m.

2009/4/4 Håkon Wium Lie <howcome(a)opera.com>om>:

...

Your markup is: [[Image:Digital ambient light meter.jpg|145px|thumb|right|A handheld digital ambient light meter, showing an f-stop of 5.6 for 24 frame/s 500 ISO filming]] I'm curious about your reasons for setting 145px, though. Is it because the original size is 145px and you don't want it to be enlarged? If so, wouldn't it be better to indicate this in some other way, e.g. a 'no-enlarge' class name?

The usual way to do this is "frame" rather than "thumb" - which does a frame with caption around a small image. Feel free to fix these when you see them ;-) - d.

Brion Vibber

2:12 p.m.

Håkon Wium Lie wrote:

...

It looked good at that size. :) The default sizes being based on width alone is pretty horrible -- it makes the actual total image size dependent on the aspect ratio, so images will be varyingly annoyingly small or annoyingly large. Thus nearly every image needs to be customized to look decent inline. Note that for reformatting for small screens you'll basically need to decide at the reformatter level if and how much you need to size images for that screen. In theory we could create a new, more useful set of generic sizes targetting sidebar-type floats, page-wide panaramas, half-page-ish diagrams (which might need to be full page-width on a small screen) etc. There is not currently any provision for this, just a general thumb size which is rarely useful or comfortable. -- brion

Håkon Wium Lie

4:35 p.m.

Also sprach Brion Vibber:

...

I'm curious about your reasons for setting 145px, though.

It seems that you are seeking an certain area for the thumb, not an exact width. This is quite reasonable. It's fairly easy to compute this server-side and sort images into a few different classes (e.g.: square, portrait, landscape, x-landscape, x-portrait). Each class would be given a certain width for a certain media type. E.g., @media screen { .thumb.portrait { width: 145px } .thumb.landscape { width: 160px } } @media handheld { .thumb.portrait { width: 40% } .thumb.landscape { width: 50% } }

...

In theory we could create a new, more useful set of generic sizes targetting sidebar-type floats, page-wide panaramas, half-page-ish diagrams (which might need to be full page-width on a small screen) etc.

Exactly. -h&kon Håkon Wium Lie CTO °þe®ª howcome(a)opera.com http://people.opera.com/howcome

Michael Daly

5:02 p.m.

New subject: [SPAM] Re: A proposal to simplify and improve image markup in Wikipedia

Brion Vibber wrote:

...

It looked good at that size. :)

On your monitor maybe. Unfortunately, basing sizes on absolute pixel counts makes no sense in todays computer world. When (almost) everyone used 640x480 monitors, fixed sizes were more reasonable. However, with everything from low-res large screens to very-high-res small screens or high-res big to low-res small, fixed image sizes suck. If a single number was to be used, scaling it to the width as a percentage might be better. However, when I put any images into a wiki page, I make sure it uses the user default - set in preferences. It still forces a fixed width, but at least a fixed width that the user can choose to match their screen size (within limits - perhaps instead of allowing the user to select from a small set of fixed values, an input field could be provided so they could choose any value). I find that a single parameter (e.g. width) works reasonably for most images regardless of orientation (landscape, portrait). Only those with extreme aspect ratios are problematic. I like the idea of having images characterized on upload and then have parameters attached that could map to CSS as HWL has suggested. But not if the resulting CSS uses a fixed pixel size. If the CSS is modified on the fly to include the user's chosen size that would be better. Mike

Brion Vibber

5:20 p.m.

New subject: [SPAM] Re: A proposal to simplify and improve image markup in Wikipedia

Michael Daly wrote:

...

Brion Vibber wrote:

It looked good at that size. :)

Since the rest of the computer's UI is based on fixed pixel sizes too, I'm afraid you're pretty much stuck. ;) HTML/CSS pixels are actually not strictly related to device pixels -- rather they have a defined relation to CSS inches. The device pixels will depend on the browser's zoom setting, whether your system has been configured for super-high-resolution display, whether you're on screen or printing, etc. "Pixels" on the web refer to a size range which is _roughly_ similar on most displays, and very large screens will usually be showing multiple windows which are closer to the size of smaller screens. Trying to make your images different sizes makes no sense at all in these cases and would actually be hugely counterproductive.

...

I find that a single parameter (e.g. width) works reasonably for most images regardless of orientation (landscape, portrait). Only those with extreme aspect ratios are problematic.

This is not my experience; simply flipping between portrait and landscape of a typical photo will change your final size by a hugely visible margin, and anything slightly more extreme such as a human-shaped cutout or a panoramic view or widescreen screenshot becomes completely inappropriate to work with. -- brion

5521

days inactive

5524

days old

wikitech-l@lists.wikimedia.org

Manage subscription

28 comments

11 participants

tags (0)

participants (11)

ABCD
Aryeh Gregor
Brion Vibber
Chad
David Gerard
Håkon Wium Lie
Jim
Michael Daly
Roan Kattouw
Stephen Bain
Tei