Nigel McFarlane Reporter
	Description • 20 years ago

Could SpiderMonkey support as an E4X extension (or as a hack):

  var foo = <tag att="{i}">bar</tag>;

Scripters are almost certain to type that instead of:

  var foo = <tag att={i}>bar</tag>;

in an attempt to create well-formed "inline" XML. How hard have we
all struggled to be good XML syntax people and leave bad old
tag soup behind? Now we should trip over a new special case
that operates against our hard-won rigour?

I appreciate that standards-wise an att can hold
"{i}" (3 chars) in pure XML. There is alternate syntax if
that unusual special case is required:

  var foo = <tag att="&#x7B;i&#x7D;">bar</tag>;

not to mention:

  var foo = XML(); foo.tag = "bar"; foo.tag.@att = "{i}";

or even as a further hack (since inline XML is not true XML
anyway):

  var foo = <tag att='{i}'>bar</tag>?

using shell interpolation semantics,  but that risks more tag
soup-ness. Most Windows scripters wouldn't know shell interpolation
if it bit them. Is att="{i}" feasible?

- N.

	Brendan Eich [:brendan]
	Comment 1 • 20 years ago

Note that Netscape in the old days (3 and 4, IIRC) supported JS entities: <foo
attr="&{bar+baz};">, e.g.

This is not a core JS engine RFE, and I'm not likely to do it.  If it's of
interest to WHATWG folks, I'm sure I'll hear about that.

/be

	:Ms2ger (he/him; ⌚ UTC+1/+2)
	Comment 2 • 13 years ago

E4X is on your side.

	Brendan Eich [:brendan]
	Comment 3 • 13 years ago

This is not a JS engine bug. Nigel (RIP) was clearly asking for HTML attribute values to be parsed for JS expressions enclosed in braces, and those expressions evaluated.

This is not the place to propose such a change. Try http://whatwg.org/ and http://w3.org/. I'm going with INVALID lacking a draft spec from one of those places.

/be