Re: Proposing content-hidden for background-image and img content

On 8/30/11 1:17 PM, Tab Atkins Jr. wrote:
> On Tue, Aug 30, 2011 at 12:03 PM, Charles Pritchard<>  wrote:
>> On 8/18/11 7:08 PM, Tab Atkins Jr. wrote:
>>> On Thu, Aug 18, 2011 at 6:14 PM, Charles Pritchard<>
>>>   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.
> Relying on background-image and hidden content prevents you from doing
> certain useful things as well, like auto-sizing the element to the
> size of the element.
> The rendering of "content: url(foo.jpg) replaced;" is also already
> mostly in the browsers, so that's not a strong concern.
Thanks for the reference to content: replaced;
How do I avoid re-flowing the content?

content: url(img.jpg) replaced; is very different from
background: url(img.jpg); background-size: contain;

One reflows content, one does not.


Received on Tuesday, 30 August 2011 20:39:02 UTC