Just to chime in here, I'm looking at the new flash text API's (flash.text.engine, and flash.textLayout or something like that). instead of the catch-all "TextField" object, which we've been using, they now have a range of objects, starting from basic single-format text runs, and more complex mixed formatted combinations of these text elements, into single or multiline text. For HTML rendering, they have a much higher level set of API's that you pass the HTML content to and they produce these compound objects with flows of text and so on.
So it's going to be pretty important that we distinguish between simple text objects and HTML formatted text objects, because we definitely do not want the overhead of all that HTML rendering machinery in most of the common text views people will be using, such as labels for buttons, etc. If we preserve the single <text> tag in LZX, the compiler or runtime will really want to know if it's got HTML content or not. And I agree with Tucker, it would be best to pass HTML content through verbatim, rather than trying to adjust it in any way in the LZX compiler. On Sun, May 30, 2010 at 8:15 PM, P T Withington <[email protected]> wrote: > IMO, the `html` type should imply that the value of the attribute is not > processed in any way. (It is passed through ScriptCompiler.quote solely to > make it a valid Javascript string literal. Otherwise it is unprocessed. > Hence, namespaces should be preserved.) > > I think where the confusion lies is when we state that by giving a <node> > an attribute named `text`, we imply that the node, like a <text> node, takes > its content as the value of the `text` attribute. And that brings us around > to: > > http://jira.openlaszlo.org/jira/browse/LPP-8898 > > The never-ending story.... > > On 2010-05-30, at 11:20, Raju Bitter wrote: > > > I have one question on the html type: Does the html type preserve > namespace > > values when it's parsed or processed? > > > > On Wed, May 26, 2010 at 11:42 PM, P T Withington <[email protected]> wrote: > > > >> [refined subject, laszlo-reviews -> laszlo-dev] > >> > >> On 2010-05-25, at 18:06, André Bargull wrote: > >> > >>> On 5/25/2010 11:40 PM, Henry Minsky wrote: > >>>>> > >>>>> Is there documentation on what "text" and "html" types are supposed > to > >> mean? (My intuition is that "text" should mean "interpreted as CDATA" > and > >> "html" should mean "interpreted as node 'content'". I.e., < and & don't > >> have any special meaning in the former, but they do in the latter. > >>>> > >>>> We had the concept of elements which were allowed to contain HTML tags > >>>> in their text vs ones which weren't, but I don't remember what the > >>>> compiler was supposed to do about enforcing that. Maybe it was > >>>> supposed to warn if you had HTML elements in a content > >>>> that was declared as "text" rather than "html"? > >>> > >>> We've got a (rather simple) table covering valid attributes types at > [1]. > >>> > >>> And "text" and "html" types are mentioned here [2]: > >>>> A tag may also contain text if it defines an attribute named text with > >> a value > >> > >> Should read "type" (not "value")? > >> > >>> of text (for plain text) or html (for XHTML text), or if it extends a > >> class that does so. This technique may be used to define a tag that > contains > >> text but does not extend <text> or <inputtext> . > >>> > >>> [1] > >> > http://labs.openlaszlo.org/trunk-nightly/docs/developers/methods-events-attributes.html#d0e76574 > >>> [2] > >> > http://labs.openlaszlo.org/trunk-nightly/docs/developers/introductory-classes.html#introductory-classes.text-classes > >> > >> 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 > >> > >> Implementation: > >> > >> string: call the string literal parser on the value, use > >> ScriptCompiler.quote to store the result > >> text: call xmlEscape on the value, use ScriptCompiler.quote to store > the > >> result > >> html: use ScriptCompiler.quote to store the value > >> > >> > >> > >> > >> > >> > >> > > -- Henry Minsky Software Architect [email protected]
