Re: [css3-background] CSS Image Replacement

On Thu, Jun 4, 2009 at 12:30 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> Note, though, that this really *is* just a theoretical solution - I
> don't believe anyone implements it yet.
>
> Keep in mind, though, that many times image-replacement isn't actually
> necessary.  Just using an <img> with @alt does what you want while
> retaining semantics and accessibility.  In the 9 solutions link you
> provide, they basically did this with solution #4, except then they
> mixed in Phark image replacement for some reason.  I'm really not sure
> what that's supposed to gain you.  In fact, all it seems to do is
> cause problems, as it causes the technique to fail in the
> CSS-on/Images-off case, and may result in two image requests.  Take
> out the Phark, and you've got a solution which passes all four
> CSS/Image possibilities, you have no additional markup, and no
> additional concerns.
>

I agree that <img> takes care of the problem too, but it still has a
few drawbacks:

1. CSS sprites are not possible (I believe an increasing amount of
sites are using this technique, and will probably stick to it until
something more practical comes along to deal with the http request
issue)
2. You'd have to change the markup to be able to use it, making it
less powerful.


On Thu, Jun 4, 2009 at 12:33 PM, Giovanni Campagna
<scampa.giovanni@gmail.com> wrote:
> I expect that image-position / content-position applies only to
> replaced content (ie images, videos, embedded plugins...)

Oh, okay then. If so, it might work.

On Thu, Jun 4, 2009 at 1:22 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
> You can still use a separate image for :hover, etc., if using sprites is not
> a requirement.
>
> It's also worth noting that with font embedding via @font-face, many of the
> needs to do CSS image replacement  go away, especially when you can combine
> that with text-shadow, RGBA colors (for translucency), etc.

True, that probably solves many of the header replacements, just not most logos.


So I guess in the end one would weigh the cost of adding a new,
relatively easy to implement property versus waiting for other, more
complicated specs to mature and be implemented that would be better
suited to deal with the situation.

I suspect the difference between the two could unfortunately be many
years, but since the benefit versus current solutions is probably too
minor, it may make more sense to wait. As long as this use case is
kept in mind when developing these specifications, that's okay by me.


Thanks,

Alexis Deveria
http://a.deveria.com

Received on Thursday, 4 June 2009 17:49:34 UTC