On 2010-06-10, at 17:05, André Bargull wrote: > On 6/10/2010 10:41 PM, P T Withington wrote: >> On 2010-06-10, at 16:35, P T Withington wrote: >> >>> On 2010-05-26, at 17:42, P T Withington wrote: >>> >>> [...] >>> >>>> I propose then that we distinguish the types `text` and `html` from >>>> `string`, and that we permit them on any attribute (not just on an >>>> attribute named "text": although it is by defining an attribute named >>>> text that you tell the schema that your class defines a tag that permits >>>> content, you might want other attributes with these types). I propose the >>>> following semantics: >>>> >>>> string: Value is parsed as an ECMAScript string >>>> text: Value is parsed as XML CDATA >>>> html: Value is parsed as XML content >>> >>> There's one issue with my proposal: >>> >>> Currently, LZX treats string, text, and html as synonyms. They are close, >>> but if we distinguish them as above, they are clearly not, if you have any >>> ES or XML characters that would be escaped. >>> >>> I tried making the declared type of<text>'s text field be honest (it is >>> really `html`, because it is not quoted in any way), and run into lots of >>> compiler type warnings because in lots of places, components and demos have >>> created subclasses of text, or simply initialized the text attribute and >>> have (pointlessly) re-declared the type of the text field. >>> >>> I don't have a solution other than removing the declarations from the >>> components and demos as we come across them. >>> >>> Other opinions? >> >> Or, maybe I am wrong. Maybe the intent is that<text> is of type `text`, >> that it does _not_ interpret HTML? But I think it does, since we seem to >> allow simple markup in text, right? > > <text> needs to be styleable with html markup. > > I think we should try to split your change in two parts: > (1) make string, text and html distinct types > (2) change how these types are quoted > > Both changes may break components and demos (at least (1) does, as you've > observed), so we shouldn't step in with the chain saw and then desperately > try to make things working again. So I vote for incremental steps.
Henry and I talked last night and we have a proposal on how to handle this: o Keep the `text` attribute of <text> as type 'text'. o Add a new `html` attribute of <text> with type 'html' This is in keeping with how DHTML handles the issue. There are two setter/getters on the DOM node, "text" addresses the node content with no interpretation, "html" addresses the node content and interprets markup (will create interior nodes, represent the nodes as markup). I claim LZX still needs the 3rd type, 'string', to distinguish the case where you want to have an attribute that is interpreted as a Javascript string (when a literal value is given). This is exactly the case with the `pattern` attribute. I understand that pattern could _also_ be of type 'text' and that you _could_ write the pattern using HTML entities for the unicode characters, but I think the natural expectation is to be able to use a Javascript string literal. The summary of the three types becomes, instead of what I originally proposed: 'string', 'text', and 'html' attribute values are parsed as literals. If you want to assign an expression value to an attribute of one of these types, you must use the constraint syntax. (I.e., you don't have to say value="'string'", just value="string".) 'string' has the additional property that it is parsed as a Javascript string literal (and Javascript escapes will be recognized). 'text' and 'html' are interpreted as XML string literals (and XML entities will be recognized, although this is really a function of runtime). In the short term, the distinction between 'text' and 'html' is (as a kludge) handled in the <text> setters for the `text` and `html` fields. The `text` field will XMLescape, the `html` field will not. In the long term (when I ever get http://jira.openlaszlo.org/jira/browse/LPP-7354 solved) the presentation types for 'text' and 'html' will extend that capability to any attribute.
