- From: Mathew Marquis <mat@matmarquis.com>
- Date: Tue, 4 Sep 2012 18:40:22 -0400
- To: Andy Davies <dajdavies@gmail.com>
- Cc: Anselm Hannemann <info@anselm-hannemann.com>, Brett Jankord <bjankord@gmail.com>, Andrew Kirkpatrick <akirkpat@adobe.com>, "public-respimg@w3.org" <public-respimg@w3.org>
On Sep 4, 2012, at 6:17 PM, Andy Davies <dajdavies@gmail.com> wrote: > On 4 September 2012 23:03, Mathew Marquis <mat@matmarquis.com> wrote: >> >> On Sep 4, 2012, at 5:46 PM, Anselm Hannemann wrote: >> >> We had this discussion a couple of months ago in the W3C community group. I >> started it with the same intends as Andrew but after all it we came to the >> resolution that it's not what picture is thought for. >> If you define a picture-element you will most likely link to one image. This >> image crop/color/properties can vary but not the image meaning / content >> itself. If you want the meaning / content to change, just use a >> server-technology or JavaScript to properly change the source and alt. But >> it's no use-case for the picture-element. >> >> >> Agreed: this is a case better solved by way of JavaScript or server-side UA >> detection. If the subject matter cannot be accurately described by a single >> `alt` attribute ( or additional descriptive markup, as discussed previously >> ), it is a disparate set of images and not a case I feel we should account >> for with `picture`. > > I guess my question would be how does someone specify a 'null' image > then i.e. have an image a certain breakpoints but no image at others. One could make a case that an image not essential to every browsing context may well be presentational in nature, and should be handled through CSS. Else, in the case of strictly *content* images, that markup should likely be injected/removed or shown/hidden through JavaScript by way of matchMedia — alternately, that markup could be omitted entirely based on server-side device detection. I wouldn’t want to encourage inherently "null" markup with regards to images any more than I would encourage a solution for serving "null" text — which is to say, the "null" case is best represented by the absence of said markup altogether. A native solution for controlling the *presence* of markup based purely on client capabilities is a larger conversation, and very likely one worth having. I don’t feel this is best solved on an element-by-element basis, however. > > Resorting to JS to fix this seems the 'wrong' way to go to me > > Cheers > > Andy >
Received on Tuesday, 4 September 2012 22:40:50 UTC