Alex, I appreciate the work that you have done. I appreciate it even more because I think that the HtmlArea is a special case and a difficult special case at that. I do not envy you what you have to start with (the iframe) and the way that the different browsers seem to support it. Also I do not envy you the fact that you have to work with all kinds of html - including the infinite ways that html is written. It is a broad subject.
However, I do not think that you can assume that all html is well formed. People will get ill formed html into the HtmlArea one way or the other. In my case I allow them to upload their html into the browser from their filesystem, which to me seems to be a normal thing to do. And if they do not load ill formed html into it, then they will enter it or cut and paste into it. My point is that the HtmlArea must be robust enough to deal with ill formed html. And the HtmlArea is the proper place to deal with it. It seems that there are so many different html standards and doctypes that it is almost impossible to validate them without a major effort. It is unrealistic to put the burden of producing well formed html on the end user or on the programmer using the HtmlArea widget. It is just too complicated. If one of the requirements is that the HtmlArea must deal only with well formed html at all times, then I think that the HtmlArea will be and will continue to be relegated to the most simple and controlled uses, and not very much use in most applications. At least in the way that I want to use it. Please don't take this as criticism. It is a very difficult problem. One that the desktop html editors, or as far as I can see, nobody has solved anywhere - or at least satisfactorily. I am not talking about html publishing software such as dreamweaver, amaya, frontpage and such. They are not the same animal and they do not provide the functionality that we are looking for here. The bottom line, at least for me personally, is that the HtmlArea will have to gracefully deal with ill formed html. And I do not know how that will be accomplished. I will look at the fix that you did for the bug that I had brought to your attention. thanks, tom Alexander Steitz wrote: > > Hi Tom, > > On Monday 19 October 2009 tsmiller wrote: >> In my application, I was allowing the user to upload an html file from >> his >> local disk to be edited in the HtmlArea. But there are so many ways that >> the end user has created html over the last 15 years or so, that I >> believe >> there is no possible way to keep the html files intact and edit them >> properly in the limited scope of the qooxdoo HtmlArea. > This is a main problem of all WYSIWYG editors out there. They work best > when > the user starts from scratch and the more not-well formed HTML is handed > into > the editor the worse is the editing. > The HtmlArea is relying on the fact that the HTML which is set as content > is > well-formed. This is a main assumption which is - in my opinion - > necessary to > make. The HtmlArea should provide the pure editing of HTML and nothing > more. > If it's necessary to clean up HTML then this should be done outside before > handing in the HTML. Otherwise you would blow up the implementation which > is > not a good choice in my opinion. > >> I too would like an html editor that just does basic editing. It seems >> that an html editor should be a very high priority widget, but apparently >> it is not. > The bug you reported gained a high priority and I managed to fix it today > :) > >> Other people may be using it and they may be getting better >> mileage than me, but as far as I can see the qooxdoo developers need to >> fix it, redesign it from start as you suggested, or remove it. It is a >> nuisance when most widgets behave a little strange, but it is a show >> stopper when this particular widget does. > If it has issues the best to support is to report them, so as you did. > I'll > personally work hard to fix them, but as anyone I only have limited time > and > also some other tasks. So please be a little patient, if some issue are > not > fixed right away. > > cheers, > Alex > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > qooxdoo-devel mailing list > qooxdoo-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > -- View this message in context: http://www.nabble.com/HtmlArea-and-users-tp25960777p26030565.html Sent from the qooxdoo-devel mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
