"\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