[whatwg] <img> element comments
Matthew Paul Thomas
mpt at myrealbox.com
Wed Jul 30 14:58:25 PDT 2008
Ian Hickson wrote on 30/07/08 04:08:
>
> On Sun, 14 Oct 2007, Matthew Paul Thomas wrote:
>>
>> On Oct 14, 2007, at 2:03 AM, Henri Sivonen wrote:
>>>
>>> I don't think "If both attributes are specified, then the ratio of
>>> the specified width to the specified height must be the same as the
>>> ratio of the logical width to the logical height in the image file."
>>> solves any real problem given what browsers already have to
>>> implement, so I'd remove that sentence.
>>
>> As a real-world example, Launchpad currently stretches the width of
>> static images to produce simple bar charts of how much particular
>> software packages have been localized.
>> <https://translations.launchpad.net/ubuntu>
>>
>> We have to specify both width= and height= for the images, because
>> specifying width= alone causes w3m to stretch the images vertically to
>> maintain their aspect ratio. Meanwhile, elsewhere we're using <canvas>,
>> so we should really be declaring our pages to be HTML 5 site-wide.
>>
>> The sentence Henri quoted would require us to choose between server-side
>> generation of every chart image, incompatibility with w3m, or
>> non-conformance with any HTML specification. I know w3m isn't exactly a
>> major browser, but I don't see any good reason for having to make that
>> choice.
>
> As far as I'm aware, the behaviour you describe for w3m matches what
> all the UAs do.
Sorry, I was unclear there. Previously we were using markup like this:
<img
width="35"
style="height: 1em;"
title="Untranslated: 35.42 %"
alt=" 35.42% untranslated"
src="/@@/red-bar"
/>
That gave us the desired result in every browser we cared about, except
w3m, which obeys the width= attribute but (because it doesn't do CSS)
ignores the style= attribute.
So now we include a height= attribute as a fallback:
<img
width="35"
style="height: 1em;"
height="10"
title="Untranslated: 35.42 %"
alt=" 35.42% untranslated"
src="/@@/red-bar"
/>
That works in every browser we care about, but would be non-conformant
HTML 5 according to the current draft.
> I'm not sure that this usage of <img> is one that the spec today
> considers valid. Wouldn't <canvas> be the better way to do this?
Indeed it wouldn't, because <canvas> wouldn't work in w3m at all! It
also wouldn't work when JavaScript was off in any other browser (a
serious consideration for our user base). And it seems a little
excessive to need to construct a <canvas> when all we want to do is
stretch an image horizontally.
So to reiterate Henri's point, given that browsers (I assume) have to
obey disproportionate width= and height= attributes for compatibility
with the Web anyway, I don't see the point of requiring authors to make
them match the image's proportions.
Cheers
--
Matthew Paul Thomas
http://mpt.net.nz/
---AV & Spam Filtering by M+Guardian - Risk Free Email (TM)---
More information about the whatwg
mailing list