Page Rendering Proposed Standard
Page Rendering Proposed Standard
By Dave Winer, dwiner@well.com
Sorting out conflicts between page rendering software, across platforms.
Increasingly, macro languages are showing up in HTML content and serving software. At some point in the life of a page, it is converted from a stream of text that contains HTML and macros into HTML. When macros are converted, the page is said to have been rendered.
In real life, several different kinds of macros can appear in one stream, and therein lies the core of the problem we are attempting to address in this proposal.
The problem hasn't become commonplace yet. But soon it will as authors get more sophisticated, and start using multiple tools, and more tools ship. Eventually the most powerful web authors will hit the wall -- a macro intended for one processor is erroneously processed by another one. Before that happens, authors will be confused by different syntaxes, and worried that conflicts might occur. With some coordination, we can achieve more orderly growth in page rendering software.
It's inherently a cross-platform problem, because the content tools are cross-platform, and because rendering might not happen on the platform that the content was created on.
Having a powerful standard for rendered text will make it possible for web developers to make more diverse tools that work well together; for content designers to build more powerful websites, and make more efficient use of system resources by rendering items that can be generated statically, and only computing things that must be rendered at serving time.
This spec was discussed and informally agreed to at a meeting of a working group of the Macintosh Internet Developer Association, meeting in Austin TX, on September 9, 1996.
For the purposes of this discussion, we assume the reader is the developer of a web content authoring tool or server software that renders source text producing HTML output.
The basic rules
Under the new scheme, you will continue to recognize the macro syntax that you currently recognize, maintaining backward compatibility with all content created by users of your software.
Additionally, you will recognize a new macro delimiter, [[double square-braces]]. This pair of delimiters can be overridden with the new <macrosyntax> tag, explained in the following section.
If the first character after the [[ is a pound-sign, then the macro is directed to a specific processor. The identifier following the pound-sign names the processor. If it's your name, process the following text, and do the substitution; if it's not your name, pass the text thru unmodified because it's a macro intended to be processed by some other software.
Further, if there is no #identifier, process the macro. This way it's easier for people who are using only your rendering software.
An example, an unambiguous macro to be processed only by Frontier would appear as follows:
[[#frontier "This page was last built on " + string.dateString ()]]Examples of other processors could be #perl, #tcl, #c, #javascript, #java.
An "identifier" is any string of at most 255 characters followed by a space.
Custom processors could be registered that also specified the time that rendering takes place. This spec doesn't need to say how that would work, other than it leaves open the possibility because the potential namespace of processors is virtually infinite.
Random notes
Authors that never experience a conflict can use the syntax that you find most natural, or prefer, or have specified in an earlier version of your software. When they experience a conflict, because you support this standard, you can offer a clean way for them to work around the problem.
Discussion
For the ratification of the this protocol, please use the main Midas list. See the Midas site for details, http://www.biap.com/midas/.
For a discussion of the Frontier implementation of this syntax, please use the Frontier-talk list.
Pointers
A new, related, HTML tag has been proposed. A two-week old spec is on the macrosyntax page.
Website Scripting with BBEdit explains how Frontier's macro processor works.
Website Building with Frontier provides more info.
The DaveNet piece, Watch This!, 5/15/96, provides background on page rendering software.
See Macro Confusion for an earlier discussion of this problem and pointers to other comments.
|
This page was last built with Frontier on a Macintosh on Wednesday, August 27, 1997 at 7:40:12 PM. Thanks for checking it out! Dave |