W3C home > Mailing lists > Public > www-html@w3.org > December 2008

Proposal for small enhancement

From: Sorin Schwimmer <sxn02@yahoo.com>
Date: Thu, 4 Dec 2008 11:15:19 -0800 (PST)
To: www-html@w3.org
Message-ID: <499352.44388.qm@web56001.mail.re3.yahoo.com>

Hello everybody,

I'm not exactly a specialist in web development, and am writing HTML code (manually, btw) only now and then. Doing it, I felt that I'm missing a certain functionality (or is it there and I don't know about it?): when it's about style, we have the very powerful CSS, allowing one definition to be used again and again. When it's about content, I couldn't find anything like inlining (a feature found for instance in wikis).

So, here is my suggestion: lets add a tag in one of the following forms:
<r id=ID/>
<r src=URL/>
"r" stands from "replace", and the idea is to use a substitution in the text the same way #define does it in C.

The first form is introducing an ad-hoc definition, the second one is refering another resource to be inlined (can I use such a verb?).
For the first situation, ad-hoc definitions can be grouped in an external file, with the prefered CCS extension (from cascading content sheet), and it is introduced similar with a CSS file, in the <head> section:
<link href="myfile.ccs" rel="contentsheet" type="text/ccs" />

Let's look at an example:


i1 {</td></tr><tr><td><img src="icon1.jpg" valign="top"/></td><td>}
i2 {</td></tr><tr><td><img src="icon2.jpg" valign="top"/></td><td>}
e {<r src="otherfile.html"/>}


<link href="myfile.ccs" rel="contentsheet" type="text/ccs" />
<table border=0><tr><td><img src="icon1.jpg" valign="top"/></td><td>
Content of this cell
<hr/><r id="i1"/>
Content of that cell
<hr/><r id="i1"/>
Content of this cell
<hr/><r id="i2"/>
Content of that cell
<hr/><r id="i1"/>
Last cell
<p>this is a paragraph, stating that <r id="e"/>, and <r src="file2.html"/>

Comments: this approach allows the gradual adoption of the new tag. Old browser, oblivious to the <r> tag, will ignore it, but the respective content is not retrieved. The onus is on the server side to detect that the user agent has the ability to work with <r> and, if not, to serve alternative content (defined by the same authors). In plain English, until <r> becomes generaly accepted, there will have to be two versions of the same file, one with <r>'s, one with <r>'s already replaced, and the server will send the appropriate one.

Plugins can be the first solution to allow <r>, then newer versions of the user agents can simply implement <r>.

If accepted and implemented, for authors, it simplifies a lot the work: if there is a need to change a certain thing in the replaced paragraph, it is done only once, in the definition. Not having this feature means going through all the affected files and operating the change. It also can work as a shortcut for the lazy ones (I subscribe here).
For user agents aware of <r> it reduces traffic, as there is no need to GET the same fragment again and again.

>From a DOM prospective, this is a non-issue, as <r> is eventualy replaced, and dissapears.

Regarding the second form, to avoid circular referencing, as the user agent is processing the substitutions, it needs to maintain a list of URLs invoked for a particular substitution. If an URL repeats itself, then the user agent should stop expanding, and signal an error.

Sorin Schwimmer

Received on Friday, 5 December 2008 10:40:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 5 December 2008 10:40:47 GMT