[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:

      style="height: 1em;"
      title="Untranslated: 35.42 %"
      alt=" 35.42% untranslated"

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:

      style="height: 1em;"
      title="Untranslated: 35.42 %"
      alt=" 35.42% untranslated"

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.

Matthew Paul Thomas

---AV & Spam Filtering by M+Guardian - Risk Free Email (TM)---

More information about the whatwg mailing list