Oy. But <inputtext text=" this will \n\n not be normalized??? " />
? On 2010-03-31, at 12:52, Henry Minsky wrote: > That's a good question. We have this model for text content in LZX > code, where <text> content gets whitespace normalized away, in order > to behave like text that you enter into an HTML browser. So even though > Flash's "HTML" text field does not normalize away whitespace, we do it in > the > ViewCompiler. > > So the LZX code below would turn into a single line that says "This is HTML > so whitespace will be normalized away." > > <text> This is HTML > > so whitespace will be > normalized away.</text> > > So the question I have is what do we do in the ViewCompiler when you have > whitespace > in an inputtext field? > > I actually would expect that if you say > <inputtext>This will be > > normalized.</inputtext> > > That it will be whitespace-normalized for you. And if you do not want it > normalized you > would say > > <inputtext><pre>Please do not make this > > normalized.</pre></inputtext> > > So that the semantics of HTML in LZX code are more consistent, e.g., literal > text gets HTML-normalized unless you tell it otherwise. > > > > > > > On Wed, Mar 31, 2010 at 12:40 PM, P T Withington <[email protected]> wrote: > >> Ok, now I am really confused. Since inputtext is not supposed to be HTML, >> you should not need to say <pre>, right? You should just enter some >> multi-line text. >> >> <inputtext> >> A >> B >> C >> </inputtext> >> >> should show up as 3 lines. If not, something else has rotted. >> >> See http://jira.openlaszlo.org/jira/browse/LPP-7558 >> >> On 2010-03-31, at 12:32, Henry Minsky wrote: >> >>> Hmm, well the only thing I'm concerned about here is how to enter >>> linebreaks, and >>> using the <pre> tag actually will allow that, so I'll just do that in the >>> test case. >>> >>> <inputtext><pre>A >>> B >>> C >>> </pre></inputtext> >>> >>> On Wed, Mar 31, 2010 at 12:18 PM, P T Withington <[email protected]> wrote: >>> >>>> Start here: >>>> >>>> http://jira.openlaszlo.org/jira/browse/LPP-7533 >>>> >>>> and follow the links. >>>> >>>> I believe the current received wisdom is that input text is _not_ HTML >>>> unless you ask for it. (And if you think about it, you should never ask >> for >>>> it either. How could a user 'input' HTML?) >>>> >>>> On 2010-03-31, at 12:00, Henry Minsky wrote: >>>> >>>>> OK, here's another test case that's failing in the lztext-textheight >>>> suite >>>>> >>>>> <inputtext fontsize="20" fgcolor="red" id="it5" >>>>> multiline="true">E<br/>F</inputtext> >>>>> >>>>> The test expects that to come out as two lines, however it actually >> gets >>>>> xml-quoted by the compiler >>>>> and, given that the input text view treats text as plaintext, the >> field >>>>> displays the literal string "E<br/>F" as a single line. >>>>> >>>>> >>>>> >>>>> In LPS 3.4, you get a compiler warning >>>>> >>>>> element "br" not allowed in this context. Check whether it is spelled >>>>> correctly, and whether a class with this name exists. >>>>> >>>>> However in trunk the compiler just passes the XML through to the input >>>> text >>>>> constructor. >>>>> >>>>> What is the correct desired behavior here?? >>>>> >>>>> -- >>>>> Henry Minsky >>>>> Software Architect >>>>> [email protected] >>>> >>>> >>> >>> >>> -- >>> Henry Minsky >>> Software Architect >>> [email protected] >> >> > > > -- > Henry Minsky > Software Architect > [email protected]
