W3C home > Mailing lists > Public > public-html-comments@w3.org > November 2011

Re: Image width specification in html5

From: T.J. Crowder <tj@crowdersoftware.com>
Date: Mon, 21 Nov 2011 12:14:46 +0000
Message-ID: <CAH65x-wUrQFBrTma0+XPs_X-=M1JD8LsJY4LLCMUy3+B6i6Mhw@mail.gmail.com>
To: "Jukka K. Korpela" <jukka.k.korpela@kolumbus.fi>, public-html-comments@w3.org
On 21 November 2011 11:59, Jukka K. Korpela <jukka.k.korpela@kolumbus.fi>wrote:

> 2011-11-21 13:03, T.J. Crowder wrote:
>  Separately: Do you have a use-case for using percentage values for
>> `width` / `height` on `img` elements?
> The most obvious use case is perhaps showing an image as large as possible
> within the available width, by setting width="100%".

True. It runs afoul of the note[1] in the current draft that "The dimension
attributes are not intended to be used to stretch the image."

I should have been clear that I don't particularly advocate using
percentage values on `width` and `height` (not that anyone's likely to ask
me), as at least one who replied off-list thought. I was addressing the
claim that inconsistency in implementation was a justification for removal,
which appears not to be the case.

It would be useful if someone actually involved in the decision pointed to
the rationale, ideally by pointing to where it was discussed and agreed.

The primary purpose, as I understand it, of `width` and `height` on `img`
elements is that they are rendering hints, so the layout engine can set
aside space for the image prior to downloading the image data (in fact, the
HTML5 draft says[1] "User agent requirements: User agents are expected to
use these attributes as hints for the rendering."). Percentages do that
just as well as pixel values, implementations do it consistently, so it's
unclear why removing percentage values is important.

[1] http://www.w3.org/TR/html5/the-map-element.html#attr-dim-width
T.J. Crowder
Independent Software Engineer
tj / crowder software / com
www / crowder software / com
Received on Monday, 21 November 2011 12:15:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:28 UTC