- From: Charles Pritchard <chuck@jumis.com>
- Date: Tue, 30 Aug 2011 12:03:13 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: "www-style@w3.org" <www-style@w3.org>
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.
Received on Tuesday, 30 August 2011 19:03:46 UTC