- From: Anne van Kesteren (fora) <fora@annevankesteren.nl>
- Date: Mon, 12 Apr 2004 20:04:35 +0200
- To: Ian Hickson <ian@hixie.ch>
- Cc: www-style@w3.org
>>>I think that when image within a "serie" could not be found, the next >>>"serie" (separated by commas) should be used. If none such serie exists, >>>as with all the examples from Boris, "contents" should be used instead >>>(as final fallback). > > That was what I was considering, the problem is in the details. Should a > lone url() always be a replaced element? Should text-followed-by-url be > allowed to fallback on a single url? Should text on its own be allowed to > have a fallback (which would always be ignored)? Should it always default > to fallback on 'contents' if there is a url in the last "serie"? Let's discuss by the examples you mention: 1. foo{content:url(img); 2. foo(content:"text"url(img),url(alternateimg); 3. foo(content:"text",url(img); The first example is an example how OBJECT could be implemted so I think that should be a replaced element. (I actually would like that when 'content' is used the contents of the selected element/pseudo-element are removed, including generated content, and the new content is inserted in one or multiple "boxes", depending on how many strings/uri values are used.) The second example, when the image with the relative URI "img" can't be loaded (not found, unsupported content-type, etc.) the image with the relative URI "alternateimg" will be used instead, without the string "text", of course. The third example will always result in "text" to be inserted. By default, the browser checks if 'contents' is the last from the "series", if not, the browser will "insert" it. Therefore, there will always be a fallback. The author has the choice to prevent this from happening by adding 'none' as last of the series, like: content:url(img),none; When the browser sees that string it will create the following: content:url(img),none,contents; And when "img" can't be retrieved the next "serie" will be chosen, 'none'. -- Anne van Kesteren <http://annevankesteren.nl/>
Received on Monday, 12 April 2004 14:05:05 UTC