It's Javascript, and what is in ""'s is Javascript.

On 2010-03-31, at 14:05, Henry Minsky wrote:

> "\n" isn't XML or HTML!
> 
> 
> On Wed, Mar 31, 2010 at 2:00 PM, P T Withington <[email protected]> wrote:
> 
>> 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]
>> 
>> 
> 
> 
> -- 
> Henry Minsky
> Software Architect
> [email protected]

Reply via email to