W3C home > Mailing lists > Public > www-style@w3.org > January 2006

Re: Idea: background-image-frame attribute

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Sat, 31 Dec 2005 21:32:16 -0800
Message-ID: <000d01c60e94$b9fdbb40$3201a8c0@Terra>
To: "HeroreV" <herorev@yahoo.com>, <www-style@w3.org>

  ----- Original Message ----- 
  From: HeroreV 
  To: www-style@w3.org 
  Sent: Saturday, December 31, 2005 9:03 PM
  Subject: Re: Idea: background-image-frame attribute

  > Except it is returning a value, specifically image data.

  If url() returns the data that is present at the given URL and not the URL itself, it is not very semantic. And if url() really does represent a URL, then properties such as background-image aren't very semantic, since a URL pointing to an image is not an actual image.

  background-image - Give me the source of some image data.
  url() - Here's a source.
  me - Why is background-image asking for a source?

  background-image - Give me some image data.
  url() - Okay, here's some.
  me - Why is an expression named "url" returning image data?

  > [paraphasing] What's really going on is:
  > background-image: image(url(some-already-clipped.jpg));
  > but image() is never explicitly used.

  I think it is actually more like background-image being a shorthand property consisting only of background-image-source. If this functionality is added to CSS, I would like to see background-image split into background-image-source and whatever else deals with background images. The same with other properties that accept a URL.

  background-image-source - Give me the source of some image data.
  url() - Here's a source.
  background-image-crop/region/area - Tell me what parts to use.
  rect(0, 0, 50%, 50%) - Use the top left quarter.

  I don't understand how introducing more properties is any worse than creating new expressions, especially nested ones. Wouldn't a new expression also be more confusing?
The only problem here: Such attributes are independently inheritable. 
I believe that in most cases such images will be specifically designed to play role
of image lists so its (location, url) and area defintion are integral parts. 

  > Since you can achieve this now by background-position in a
  > limited manner, do you think the explicit framing can extend
  > the possibility of usage?

  You can't tile only part of an image across an entire area with just background-position. Whether this is an important feature is debatable of course.


  One weird way to solve this that I just thought of would be to create something like "named image! s". Not gonna happen, but I can dream. It introduces a new expression, a new @-rule, and some really crazy syntax, but no new properties. :b

  @image { "daisy" url("http://site.com/all-images.png") 0, 0, 50, 50 }
  @image { "roses" url("http://site.com/all-images.png") 0, 50, 100, 50 }

In fact this is the best possible approach in my opinion. 
And I like the idea of part names.  Useful if such images will appear not once in the document.
  div { background-image: named-image("daisy"); }
  li { list-style-image: named-image("daisy"); }
  p { background-image: named-image("roses"); }
Andrew Fedoniouk.
Received on Sunday, 1 January 2006 05:32:20 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:22 UTC