W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2013

Re: [whatwg] <imgset> responsive imgs proposition (Re: The src-N proposal)

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 18 Nov 2013 09:05:25 -0800
Message-ID: <CAAWBYDCdg6WyOJrz45k6DYA5T8HG+o1oJib-fhv1hg+GG7eo9g@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Markus Ernst <derernst@gmx.ch>, Yoav Weiss <yoav@yoav.ws>, Ryosuke Niwa <rniwa@apple.com>, whatwg <whatwg@lists.whatwg.org>, Markus Lanthaler <markus.lanthaler@gmx.net>, "Jukka K. Korpela" <jkorpela@cs.tut.fi>, Adam Barth <w3c@adambarth.com>
On Sun, Nov 17, 2013 at 3:11 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> It seems like the blockers to this syntax working as-is are:
> - For Safari and Chrome, url(attr()) doesn't work.

This will never work; for legacy compat reasons, url() is not a
function, but a syntax construct specially recognized and handled by
the parser.  (Don't nest incompatible microsyntaxes, kids!)
url(attr()) is compatibly a bad-url token right now.

However, "attr(foo url)" does work, at least per spec.  I don't think
it's been implemented yet.

> - For Safari and Chrome, content: replaced url() doesn't work. I couldn't find a spec for the 'content' property that includes the 'replaced' token so I am not sure what it is even supposed to do.

Yes, this has been a longstanding suggestion to make a 'content' image
actually make the image replaced, as opposed to its current behavior
which inserts an anonymous replaced-element child into it.  As
fantasai and I haven't significantly picked up the Content spec
lately, we haven't added it yet.

> - For Firefox, the 'content' property doesn't work on an element (as opposed to :before and :after)..

This is just a lack of implementation.

> I was able to get Safari and Chrome to work by getting rid of 'replaced' and specifying the images in CSS instead of using url(attr). With those changes, I noted the following possibly undesirable effects:

It didn't actually work - if you try to size the element, you'll note
that the images don't care.

> (1) Saving the image from the context menu (or opening in a new tab or window, or other context menu operations like copy) always uses the "src" image instead of the selected image. Dragging it uses the correct image.

Sounds like something that could potentially be fixed.

> (2) Preloading will always preload the src (and I suspect the normal loader would do it to so that both the image src and the content: replaced source will be loaded).

This is because the preloader doesn't understand CSS yet.

Received on Monday, 18 November 2013 17:06:17 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:14 UTC