Re: 2) The issue of preserving whitespace in <text> (or <inputtext>) elements is really a separate issue and should not be confused with permitting markup in <text> elements. Our intent is that the content of <text> should preserve whitespace and line breaks (for back-compatibility). That is, by default, the whitespace style of our text elements is meant to be `pre-line`. It is a bug that line breaks are removed from literal text by the compiler, and it is a bug that they are removed from dynamic text by the DHTML kernel.
Re: 1) I can see that if you don't allow editing, you don't have to answer the question of what editing means. But it seems you are proposing that we allow general markup in input elements, which by default are editable. So I think my question is valid. On 2010-04-11, at 13:03, André Bargull wrote: > I don't see any problems with users editing the text for the two use cases > I've outlined: > >> 1) You want to display HTML formatted text, but you also want to have >> inputtext look&feel > > In this use case, the text is only displayed, thus not editable. > > >> 2) To insert pre-formatted text with line breaks in an inputtext. Just >> one day ago I've responded to this thread [1] in the German OpenLaszlo >> forum and that thread was about exactly this issue! > > Any <br> line-breaks are automatically changed to \n (resp. \r in Flash). > > > On 4/11/2010 6:46 PM, P T Withington wrote: >> So, what happens, when you have set an inputtext element to display HTML and >> the user edits the text? How does the editing interact with the >> (essentially invisible) markup? >> >> On 2010-04-09, at 14:03, André Bargull wrote: >> >>> (I've changed the mail's subject back to the original title) >>> >>> >>> As stated earlier [1], sometimes it is useful to have HTML capability for >>> inputtext. >>> >>> [1] http://www.openlaszlo.org/pipermail/laszlo-dev/2010-March/022618.html >>> >>> >>> On 4/9/2010 7:35 PM, Henry Minsky wrote: >>>> oh yes, you're right, I guess we never did that. >>>> >>>> If someone wants to style an input field, they can set the font >>>> size/style on an input text field without calling setHTML. But if there >>>> are style changes in the text >>>> it's just going to make a mess when they start editing it. >>>> >>>> I notice that we have a capabilities for this feature, which is disabled >>>> for >>>> DHTML, maybe we should should disable it for swf also, so people get >>>> a warning in the debugger, and don't expect it to do anything useful. >>>> >>>> >>>> >>>> >>>> On Fri, Apr 9, 2010 at 12:59 PM, André Bargull<[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> "setHTML(..)" is only defined on lz.inputtext. There is no >>>> corresponding method for lz.text, is it? See LPP-6617 >>>> >>>> >>>> On 4/9/2010 6:35 PM, [email protected] >>>> <mailto:[email protected]> wrote: >>>>> Hi Roger, >>>>> >>>>> The inputtext class doesn't support HTML formatting in any useful way >>>>> right >>>>> now. It inherits the >>>>> setHTML flag from lz.text, but the behavior is not well defined when >>>>> you >>>>> start entering text. >>>>> >>>>> There is a rich text editor component that is specific to Flash 8, in >>>>> the >>>>> incubator/rich-text directory, >>>>> but it works by doing low level calls to the Flash TextField and >>>>> TextFormat >>>>> objects directly. >>>>> >>>>> That component could probably be made to work in swf910 with some >>>>> effort, >>>>> but it's a somewhat difficult >>>>> task, because the code pokes directly into the LzSprite object, and >>>>> that >>>>> implementation has diverged >>>>> somewhat from swf8 to swf10. >>>>> >>>>> We're looking at the design of an updated text class that can take >>>>> advantage >>>>> of some of the >>>>> powerful features of Flash 10's text engine. The challenge will be to >>>>> see >>>>> how to expose these >>>>> new features and also try to have as much cross-platform compatibility >>>>> as >>>>> possible with the >>>>> DHTML runtime. >>>>> >>>>> >>>>> >>>>> On Fri, Apr 9, 2010 at 11:29 AM, Roger Yarrow<[email protected]> >>>>> <mailto:[email protected]> wrote: >>>>> >>>>> >>>>>> > This is occurring in OL 4.7.1 swf9/10. I searched JIRA for a bug >>>>>> but >>>>>> > couldn't seem to find a match for this situation. Are users >>>>>> supposed to >>>>>> > just enter bugs directly into JIRA or post here first?:) >>>>>> > >>>>>> > The issue is that inputtext, once clicked or selected, gets all >>>>>> screwy with >>>>>> > drawing HTML. Once clicked/selected, all text is rendered >>>>>> improperly and >>>>>> > cannot be recovered -- meaning it is always drawn wrong no matter >>>>>> how many >>>>>> > times you set the text. >>>>>> > >>>>>> > Run the test program. Just click each button back and forth as >>>>>> many times >>>>>> > as you want and the HTML will render properly. Next, click >>>>>> inside the >>>>>> > inputtext (focus) and/or select text within it. Then click one >>>>>> of the >>>>>> > buttons -- when the text updates, ALL the text will forever be >>>>>> displayed >>>>>> > underlined or bolded depending upon which tag was in use at the >>>>>> time of the >>>>>> > click. So, if you click Bold and then select from the inputtext, >>>>>> click >>>>>> > Underline, and all your text is bolded. Reload the app, perform >>>>>> the same >>>>>> > feat on Underline, and all your text will forever be underlined. >>>>>> > >>>>>> > If I set the inputtext selectable="false" the problem still >>>>>> occurs. You >>>>>> > click on the text, it selects it ALL (which I think is another >>>>>> bug?) and >>>>>> > then the HTML rendering behavior appears. >>>>>> > >>>>>> > <canvas width="100%" debug="true" height="560"> >>>>>> > <simplelayout axis="y" spacing="10"/> >>>>>> > <button>Bold >>>>>> > <handler name="onclick"> >>>>>> > <![CDATA[ >>>>>> > test.setAttribute('text','<b>Here is >>>>>> bold<//b><br//><br/>And this >>>>>> > should be plaintext<br/><br/><b>And bold again</b>'); >>>>>> > ]]> >>>>>> > </handler> >>>>>> > </button> >>>>>> > <button>Underlined >>>>>> > <handler name="onclick"> >>>>>> > <![CDATA[ >>>>>> > test.setAttribute('text','<a href="#"><u><font >>>>>> > color="#0000ff">Here is a >>>>>> hyperlink<//font><//u></a><br//><br//>And this should >>>>>> > be plaintext'); >>>>>> > ]]> >>>>>> > </handler> >>>>>> > </button> >>>>>> > <inputtext width="300" height="200" id="test" multiline="true" >>>>>> > oninit="this.setHTML(true)"/> >>>>>> > </canvas> >>>>>> > >>>>>> >>>>> -- Henry Minsky Software Architect [email protected] >>>>> <mailto:[email protected]> >>>> >>>> >>>> >>>> >>>> -- >>>> Henry Minsky >>>> Software Architect >>>> [email protected]<mailto:[email protected]> >>>> >>>> >> >>
