On Sun, Nov 17, 2013 at 3:11 PM, Maciej Stachowiak <[email protected]> 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. ~TJ
