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@opera.com http://people.opera.com/howcome
On Fri, Apr 3, 2009 at 12:44 PM, Håkon Wium Lie howcome@opera.com wrote:
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%.
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.
Also sprach Tei:
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%.
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@opera.com http://people.opera.com/howcome
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Håkon Wium Lie wrote:
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%.
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
Also sprach ABCD:
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).
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@opera.com http://people.opera.com/howcome
On Fri, Apr 3, 2009 at 10:31 AM, Håkon Wium Lie howcome@opera.com wrote:
Also sprach ABCD:
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).
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?
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
2009/4/3 Håkon Wium Lie howcome@opera.com:
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%.
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)
Also sprach Roan Kattouw:
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.
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@opera.com http://people.opera.com/howcome
On Fri, Apr 3, 2009 at 8:45 AM, Håkon Wium Lie howcome@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
Also sprach Chad:
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
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@opera.com http://people.opera.com/howcome
2009/4/3 Chad innocentkiller@gmail.com:
On Fri, Apr 3, 2009 at 8:45 AM, Håkon Wium Lie howcome@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.
On Sat, Apr 4, 2009 at 12:26 AM, David Gerard dgerard@gmail.com wrote:
2009/4/3 Chad innocentkiller@gmail.com:
/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.
2009/4/3 Stephen Bain stephen.bain@gmail.com:
On Sat, Apr 4, 2009 at 12:26 AM, David Gerard dgerard@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.
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@opera.com http://people.opera.com/howcome
-----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
-----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.
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.
Ignore that, I misread....
- -- ABCD
On Fri, Apr 3, 2009 at 6:44 AM, Håkon Wium Lie howcome@opera.com wrote:
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%.
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@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.
2009/4/3 Aryeh Gregor Simetrical+wikilist@gmail.com:
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.
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%.
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.
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@opera.com http://people.opera.com/howcome
On Fri, Apr 3, 2009 at 5:19 PM, Håkon Wium Lie howcome@opera.com wrote:
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.
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.
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@opera.com http://people.opera.com/howcome
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
2009/4/3 Brion Vibber brion@wikimedia.org:
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.)
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.
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@opera.com http://people.opera.com/howcome
2009/4/4 Håkon Wium Lie howcome@opera.com:
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.
Håkon Wium Lie wrote:
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.
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
Also sprach Brion Vibber:
I'm curious about your reasons for setting 145px, though.
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.
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@opera.com http://people.opera.com/howcome
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
Michael Daly wrote:
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.
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
wikitech-l@lists.wikimedia.org