- From: Kelly Miller <lightsolphoenix@gmail.com>
- Date: Sat, 07 Jan 2006 04:33:16 -0500
- To: www-style@w3.org
Over the last few days, I've been thinking hard about possible solutions to the continuous problems people mention about background-images in CSS. I'm basically submitting this as a series of ideas I had about how the background system might be improved. I don't consider myself perfect, or an expert, so these ideas are just opinions and shouldn't be considered me lecturing or anything like that. 1) background-position is too basic as it is right now. Originally, I suggesting augmenting it to allow more control over the position, but I had a much better and more backwards-compatible idea: add properties that match the position properties (left, right, top, bottom), and consider the box created by those 4 properties as the background as it is defined in CSS 2.1 (in short, right bottom would be the bottom-right of that box, not of the whole element). Since the default for such a situation would be 0 for all 4, not entering them would result in the current setup, thus preserving backwards-compatibility. 2) IMO, adding all the new background properties AND allowing multiple backgrounds is majorly complicating the syntax of the background shorthand. I suggest instead of using commas, it may be a better idea to consider using a pseudo-element ::background(n), where n is a positive integer. Besides allowing background to remain simple, this also allows authors to order their background images in a logical order, and also makes it easier for the author to quickly change the order of image rendering. This method would also preserve backwards-compatibility, because ::background(0) is the same as declaring background on the element itself. Other interesting possible results are using multiple background colors (allowing one to fake certain types of gradients in CSS, and saving download time by allowing only a portion of the background to be colored a certain color) and allowing for a fallback background if multiple backgrounds are not supported (since the user agent will understand background on the element). Obviously, ::background(n) should probably be restricted; things like float, position and content are useless on such an element, so it would have to be restricted similarly to how ::first-line and ::first-letter are restricted. 3) An idea I suggested before is to augment background-origin to allow using a singular point of reference in multiple elements. Some example additions besides border and padding are root (considered the <html> or <body> element in HTML, and the root element in XML), a grid number (for the newly proposed grid system; uses the element attached to that grid point as the starting source), and maybe something having to do with id's. Obviously, the intent is to avoid using an arbritrary point of reference; logically, the source element should be an ancestor of all the elements used for background-origins. 4) I believe besides background-size, another method of doing stretching may be useful. Maybe a property background-dist, which would take stretch and tile for values, where tile is CSS 2.1 behavior and stretch resizes the image to the size of the bounding box? I believe this would be useful with the coming of vector images such as SVG to the web; this would allow using small resized images instead of large images in the backgrounds. -- http://www.mozilla.org/products/firefox/ - Get Firefox! http://www.mozilla.org/products/thunderbird/ - Reclaim Your Inbox! Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
Received on Saturday, 7 January 2006 09:33:18 UTC