On 8/18/11 7:08 PM, Tab Atkins Jr. wrote:
> On Thu, Aug 18, 2011 at 6:14 PM, Charles Pritchard<chuck@jumis.com> wrote:
>
>> Proposing content-hidden for background-image and img content.
>>
>> I'd like to see a new option: "visibility: content-hidden", such as,
>> <img style="visibility: content-hidden; background: blue" />
>>
>> Like visibility, the content is not rendered, but, background and border
>> fills are.
>> A lot of work has gone into background-* paint services.
>>
>>
...
> I assume the use-case you're trying to hit is that you want an<img>
> element in your source (for semantics, @alt, etc.), but the actual
> image content could be generated by a CSS<image> value.
>
> In this case, the solution will be (once I or Elika pick up the
> Generated Content spec in the near future) just providing the image
> you want to the 'content' property (likely with some keyword that
> indicates it should still be treated as a replaced element; details
> are still vague).
>
I want to keep the content, just not in the render tree. Sure, content:
hidden; would be an alternative.
css generated content is a big spec, and a big undertaking. My thinking,
and it could be wrong, is that visibility: content-hidden
could/would be implemented much sooner than content: hidden. The
rendering block is already -mostly- developed in the browsers, for
visibility: hidden.
The code around css generated content is quite a bit more complex and
i'm concerned about the quantity of possible of side effects. Given that
it does not do any content generation, visibility: content-hidden is
simpler for vendors to pick up. In doing so, they can exploit a good
deal of that power that CSS <image> values have gained.