[html5] Thread about runat (or "server") attribute in WHATWG mailing list

Bjartur Thorlacius svartman95 at gmail.com
Mon May 14 05:54:13 PDT 2012

On 5/14/12, Markus Ernst <derernst at gmx.ch> wrote:
> I read a discussion on an attribute to specify server-side Javascript in
> the WHATWG mailing list. Now I do not know a lot about server-side
> Javascript, but I know that server-side code does usually (well, at
> least in the scripting languages I am familiar with) not appear in HTML,
> but rather the results of the server-side execution of that code. Thus I
> am very surprised to read HTML experts discuss about server-side stuff.
> Why should server-side code appear in the HTML spec?
The discussion is not so much about standardizing server-side code,
but rather about reserving the attribute for internal usage. That is,
rather than defining semantics for @runat or @server, WHATWG would
simply promise to never standardize an attribute so named for other
purposes. Reserving the attribute would allow servers to use a strict
superset of HTML internally without worrying about

If, on the other hand, an independent standardization group or any
HTML generator decided to start using @server without ever contacting
WHATWG, the WHATWG might incompatibly decide to use @server for
something else, perhaps web worker related. That would make the HTML
generators markup language into a subtly incompatible dialect of HTML,
instead of a compatible superset.

That can be resolved by using a different syntax that will not become
valid HTML in the foreseeable future. In theory, SGML would have made
this easier, but in practice SGML is too general and the standard
never was followed completely by every page out there. But server-side
includes solved this quite nicely. But if you prefer a syntax that
looks like HTML, smells like HTML, parses like HTML and could validate
as HTML - you'll have to prevent it from becoming valid differently.
And standards groups are precisely the place to do that sort of thing.

More information about the Help mailing list