Fritz, I think that moving the validation further up the line from the HtmlArea itself, possibly using something like Tidy may very well be the only realistic solution. However, I dislike this for four reasons.
First, it forces you as a developer to always know where the information is coming from that you load into the HtmlArea and have access to it. There may or may not be good reasons to do so, but I do not like a solution that limits this from the start. Secondly, if you create an object with properties and methods that take input data, theoretically at least, it is that widget's responsibility to protect itself from bad data. The widget needs to deal with bad input data, not just ignore it and hope for the best. I think the latter is asking for trouble somewhere along the line. Thirdly, you are only protecting against data from the server. Again it is a personal preference, but I will not force someone to use an html editor without giving him access to the source so that he can tweak it or change some of the crazy code that the html editor automatically produces. Fourthly, by validating the code on the server you are leaving it open to use any validation process that you want. There is still no guarantee that the HtmlArea is going to think that it is valid code. When I first came across the HtmlArea widget I remember the documentation referring to it as a Simple Html Editor (or words very similar). Maybe it is not possible to make it more that that. I have experienced the HtmlArea destroying a great deal of a document's formatting (probably by mismatching a div or span) and not being able to undo the changes. You cannot do that to users and call it a professional tool. So it is going to have to stay a Simple Html Editor or some very serious thought is going to have to be put into making it reliable and safe with all files. I am not making any bad comments about any of the people associated with the HtmlArea. This is just a statement of what my needs are and a comment about the state of html in general. I have historically avoided html in the past because there are no good tools for the average person to work with it. tom Fritz Zaucker-3 wrote: > > Wouldn't it make sense to clean-up the HTML upload file on the server side > e.g. with Tidy (http://tidy.sourceforge.net)? > > That seems a lot more doable starting point than trying to do that inside > a > JS widget (especially, if the HTML-file is of any substantial size)? > > Cheers, > Fritz > > On Fri, 23 Oct 2009, tsmiller wrote: > >> 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 >>> >>> >> >> > > -- > Oetiker+Partner AG tel: +41 62 775 99 03 (direct) > Fritz Zaucker +41 62 775 99 00 (switch board) > Aarweg 15 +41 79 675 06 30 (mobile) > CH-4600 Olten fax: +41 62 775 99 05 > Schweiz web: www.oetiker.ch > > ------------------------------------------------------------------------------ > 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-tp25960777p26033182.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
