W3C home > Mailing lists > Public > www-style@w3.org > August 2011

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

From: Charles Pritchard <chuck@jumis.com>
Date: Tue, 30 Aug 2011 13:38:30 -0700
Message-ID: <4E5D4A46.7000103@jumis.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: "www-style@w3.org" <www-style@w3.org>
On 8/30/11 1:17 PM, Tab Atkins Jr. wrote:
> On Tue, Aug 30, 2011 at 12:03 PM, Charles Pritchard<chuck@jumis.com>  wrote:
>    
>> 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.
>>      
> 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.

-Charles
Received on Tuesday, 30 August 2011 20:39:02 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:43 GMT