W3C home > Mailing lists > Public > www-style@w3.org > April 1996

RE: URLs in CSS

From: Chris Wilson (PSD) <cwilso@microsoft.com>
Date: Mon, 15 Apr 1996 12:58:16 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-76-MSG-960415195816Z-13725@red-05-imc.itg.microsoft.com>
To: "'www-style@w3.org'" <www-style@w3.org>, "'Abigail'" <abigail@tungsten.gn.iaf.nl>
>Abigail [SMTP:abigail@tungsten.gn.iaf.nl] suggests:
>>BODY { background: <URL:http://foo/bar> }

The problem with this syntax is that some HTML parsers may not like '<'
occurring in HTML text (inside a <STYLE> block).  Using "&lt;" in its
place is obviously ugly for a human author, although easy to produce
from an authoring tool.

	-Chris
Chris Wilson
cwilso@microsoft.com
-[-

>----------
>From: 	Abigail[SMTP:abigail@tungsten.gn.iaf.nl]
>Sent: 	Monday, April 15, 1996 12:01 PM
>To: 	www-style@w3.org
>Subject: 	Re: URLs in CSS
>
>Scott E. Preece wrote:
>++ 
>++ From: Hakon Lie <howcome@w3.org>
>++ |  
>++ |  Several CSS properties take URL values. Up to now, URLs have been
>++ |  identified with quotes. This works quite well for absolute links:
>++ |  
>++ |    BODY { background: "http://foo.com/png/marble" }
>++ ---
>++ 
>++ I would *strongly* urge that quotes have no special semantics beyond
>++ grouping characters into a string - it's just too confusing.  You
>*need*
>++ to have a way of unambiguously indicating that a sequenec of
>characters
>++ is a single value, regardless of its context, and that should be
>what
>++ quotes mean.
>++ 
>++ I'm pretty sure that's what the formal grammar says - that a
>++ sequence of characters surrounded by quotes is a string.  The quotes
>++ should never be visible to the parser at all - the lexer should have
>++ used them to turn the surrounded characters into a token of type
>string.
>
>I agree with Scott. Quotes should be used to group characters;
>nothing else.
>
>++ ---
>++ |  Here are some suggestions for alternative schemes;
>++ |  
>++ |    BODY { background: [http://foo/bar] }
>++ |    BODY { background: url:http://foo/bar }
>++ |    BODY { background: href:red }
>++ |    BODY { background: url:red }
>++ |    BODY { background: url(red) }
>++ |    BODY { background: url(http://foo/bar) }
>
>Or:
>BODY { background: <URL:http://foo/bar> }
>
>It has the advantage that this notation is already in use; though
>I do not know if there is any formal status for it.
>
>++ I'd slightly prefer url(...) over href(...). It generalizes
>naturally to
>++ explicitly indicating other units.  I would avoid using another
>colon,
>++ just to make life easier for the parser.
>++ 
>++ ---
>++ |  Also, should the identification be optional for absolute URLs?:
>++ |  
>++ |    BODY { background: http://foo/bar } 
>++ ---
>++ 
>++ I guess I would require it wherever the syntax allows alternative
>units
>++ that could be confused - that is, if you had a property whose value
>was
>++ *always* a URL, it would be OK to omit it there, but it would be
>++ required wheever the units alternatives left it open to
>interpretation.
>++ While it's unlikely that the name of a color would be a string that
>++ started "http:", it's quite possible that for some other property it
>++ *would* be ambigous.  For instance, if you had a "Footer" property,
>you
>++ would have no way of knowing whether "http://..." was meant to be a
>++ string that would be printed in the footer or meant to be a URL
>where
>++ the actual footer contents would be found.
>
>Indeed, specially since an URL can have another scheme than http.
>For now, I can only think of using ftp in this context, but that
>can change in the future.
>
>
>Abigail
>
>-- 
><URL: http://www.edbo.com/abigail/>  (Changed)
>
>
Received on Monday, 15 April 1996 15:57:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:53:44 GMT