Karn Kallio wrote:
On Tuesday, August 30, 2011 06:45:10 PM Adam Chlipala wrote:
Currently, Ur/Web supports an 'id' attribute on any XML element. I
added this when someone requested support for the<label> tag.
Currently, 'id' attributes have type [string]. This freaks me out
somewhat, since it's anti-modular; different functions written by
different people might need to coordinate to avoid duplicating IDs. The
use of IDs is convenient for FFI JavaScript code that wants to get
handles to DOM nodes.
So, I'm thinking of adding an abstract type of IDs, with only one
built-in operation: "generate fresh ID." Every tag's 'id' attribute
would change to take a value of this type. Under the hood, these would
just be strings, making for easy FFI integration.
Does anyone object to the idea? Any other feedback?
No objection, I think it is a good idea. For integration with external CSS
and FFI Ecmascript, would it be possible to have a second operation that takes
a "suggestion" string and generates an id having that as the under the hood
value if it is not already taken? Already taken "suggestions" then cause an
error if given again, or alternatively are ignored or modified. Without some
sort of mechanism for controlling or mapping id string values I think it will
generally be impossible to use external resources (eg style sheets on another
server or under control of some other team).
Stylesheets don't need to mention IDs; you can do everything you can do
with IDs using "singleton classes." So, presumably you're talking about
integrating with stylesheets not written with the Ur/Web application in
mind. I wasn't planning to make an effort to support that.
Allowing arbitrary string values suggested by the programmer
significantly complicates a sound implementation. If IDs are abstract
in the Ur semantics, then IDs can be generated with a simple counter.
That's my current plan.
_______________________________________________
Ur mailing list
[email protected]
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
