W3C home > Mailing lists > Public > public-html@w3.org > May 2007

Re[2]: Substitutions for site/path in SRC,HREF

From: Dmitry Turin <html60@narod.ru>
Date: Tue, 22 May 2007 12:10:21 +0400
Message-ID: <12615400367.20070522121021@narod.ru>
To: public-html@w3.org

DG> you tend to invent whole new sub- and super-languages

Let's think together.

The most hard condition for substitution is
to put value _inside_ meaning of attribute, i.e.
<link href="site.com$path$filename.txt">
  (or <link href="site.com/$path$/filename.txt">
  to look at /$ and $/ as at brackets)

Thus mark is the _hardest conclusion_ from this the _hardest condition_.

CSS, <sbs> or any other way needs,
that some mark was inside meaning of attribute
(to replace this mark by value of substitution).

I don't know, how should $path$ be appreciated -
as sub- or super-languages :) -
but it's impossible to solve without $path$.

DG> define and reuse variables /within/ style sheets, e.g. for ... file paths

Let's imagine, that 'path' is specified in css-file as any other property.
One definition should specify substitution _simultaneously_

If you offer to specify in css-file (like in example below),
i agree (i cared about presence of functionality),
but that is not elegant variant:
to remember magic list of all tags with links.

/*** in css-file ***/
img,link,a,form,object,frame {
  path1:  dir1/dir2/dir3;
  path2:  folder1/folder2;
  path99: directory1/directory2;

DG>  Your example,
DG> on the other hand, shows what can be substituted on the server side.

My idea is inverse, i.e. idea is to substitute on client side
in additional file (like css-file).

  <link href="a.sbs" rel="substitution" type="text/sbs">

Dmitry Turin
Received on Tuesday, 22 May 2007 13:13:18 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:21 UTC