Re: [whatwg] salvaging work while navigating away from a web app -- onunload=confirm('save before quitting?')
On Fri, Dec 12, 2008 at 10:01 PM, Martin Atkins m...@degeneration.co.uk wrote: I think this makes a good case for not allowing any site to create browser-modal UI. Could browsers handle confirm() and friends in such a way that they only block the contents of the tab, not the whole browser? sure given many years and lots of rearchitecture. i suspect chrome and ie8 are closest. anyone else who runs javascript in process is almost certainly stuck. In particular, the close tab and close window features, ideally along with things such as Back, Forward and Home should still be available. this is only half doable. and i really shouldn't have to repeat myself, people who don't understand this shouldn't be asking about it. if you do the following: 1. run to completion 2. you don't use multiple processes 3. you run javascript using a typical C based stack/state machine 4. let javascript call to native code then you have this problem: javascript calls native code (e.g. confirm()), and can't finalize its stacks until the dialog is finished. so instead, you push an event loop. now, if you let this happen in two windows, you get: [top] [currentEventLoop] [window-2-confirm] [pushedEventLoop] [window-1-confirm] [normalEventLoop] [appStart] at this point, you can't dismiss the window-1-confirm until the window-2-confirm goes away. It is possible to try to hide pieces of things, including trying to close the window, however you're going to end up violating run to completion, which has traditionally been considered holy. It's not entirely impossible to try to arrange to close the window or handle stopping scripts for the page, or renavigate the page, but you're breaking a number of principles and risk hitting various security cases which were not at risk before. there are basically two approaches for solving this, one involves running JS off the main thread, and the other involves running apps in multiple processes. Google Chrome and IE8 do the latter. No one likes the former. The complexity is similar for both approaches (lots of work), but the risks of the former don't offer much in payoff which is probably why the groups who've worked on it have all chosen the latter. (AFAIU, mozilla is looking to follow suit.) The reason that alert dialogs are modal is because they're critical to the stability of the browser. The user needs to interact with them very soon, otherwise any other site/page/window/tab that interacts with that window should be hung by the run to completion promise from the beginning of javascript. Now, it's true that the dialog isn't app modal, but that's a compromise that added complexity. Here's a strawman (which I'm sure has some subtleties I've not considered): write a browser impl first and get back to us.
Re: [whatwg] salvaging work while navigating away from a web app -- onunload=confirm('save before quitting?')
timeless wrote: On Fri, Dec 12, 2008 at 10:01 PM, Martin Atkins m...@degeneration.co.uk wrote: I think this makes a good case for not allowing any site to create browser-modal UI. Could browsers handle confirm() and friends in such a way that they only block the contents of the tab, not the whole browser? sure given many years and lots of rearchitecture. i suspect chrome and ie8 are closest. anyone else who runs javascript in process is almost certainly stuck. An alternative from Opera: The confirm dialog is whole-browser-modal, but it has a checkbox captioned Stop executing scripts on this page which allows you to forcefully kill off a script that's repeatedly displaying dialogs as in the example that prompted this message.
Re: [whatwg] salvaging work while navigating away from a web app -- onunload=confirm('save before quitting?')
On Sun, Dec 14, 2008 at 10:30 PM, Martin Atkins m...@degeneration.co.uk wrote: An alternative from Opera: The confirm dialog is whole-browser-modal, but it has a checkbox captioned Stop executing scripts on this page which allows you to forcefully kill off a script that's repeatedly displaying dialogs as in the example that prompted this message. neither of these bother me. and i'm certainly in favor of adding a stop option to the dialogs for firefox. it's definitely managable. today some of our dialogs get an extra 'debug script' button under certain conditions. The only concern I have is that someone from UE/UI will complain that such a button will confuse people, as it becomes trivial for a user to break any web site and not necessarily understand that what they did was the cause. However, that's a bridge I'm willing to try to cross.
[whatwg] Stability of tokenizing/dom algorithms
Hello all, I was curious to know how stable/complete HTML 5's tokenizing and DOM algorithms are (specifically section 8). A cursory glance through the section reveals a few red warning boxes, but these are largely issues of whether or not the specification should follow browser implementations, and not actual errors in the specification. The reason I'd like to know this is because I am the author of a tool named HTML Purifier, which takes user-input HTML and cleans it for standards-compliance as well as XSS. We insist on output being standards compliant, because the result is unambiguous. As far as I can tell, this is quite unlike the tools that HTML5 is tooled towards; compliance checkers, user agents and data miners. There certainly is overlap: we have our own parsing and DOM-building algorithms which work decently well, although they do trip up on a number of edge-cases (active formatting elements being one notable example). However, using the HTML5 algorithm wholesale is not possible for several reasons: 1. Users input HTML fragments, not actual HTML documents. A parser I would use needs to be able to enter parsing in a specific state, and has to ignore any requests by the user to exit that state (i.e. a /body tag) 2. No one actually codes their HTML in HTML5 (yet), so the only parts of the algorithm I want to use are the ones that are emulating browser behavior with HTML4. However, HTML5 interweaves it's additions with the browser research it has done. I'd be really interested to hear what you all have to say about this matter. Thanks! Cheers, Edward
Re: [whatwg] Stability of tokenizing/dom algorithms
On Sun, 14 Dec 2008 22:37:40 +0100, Edward Z. Yang edwardzy...@thewritingpot.com wrote: 1. Users input HTML fragments, not actual HTML documents. A parser I would use needs to be able to enter parsing in a specific state, and has to ignore any requests by the user to exit that state (i.e. a /body tag) Could you explain what is not sufficient about the the Parsing HTML fragments section: http://www.whatwg.org/specs/web-apps/current-work/multipage/serializing-html-fragments.html#parsing-html-fragments ? 2. No one actually codes their HTML in HTML5 (yet), so the only parts of the algorithm I want to use are the ones that are emulating browser behavior with HTML4. However, HTML5 interweaves it's additions with the browser research it has done. Are there any specific differences that pose problems? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Stability of tokenizing/dom algorithms
Anne van Kesteren wrote: Could you explain what is not sufficient about the the Parsing HTML fragments section: I must admit, I had not seen that section! That seems to be quite sufficient. My bad. :o) Are there any specific differences that pose problems? Not that I know of yet, since I haven't started on an implementation yet. Which brings me back to my original question: how stable is section 8? I would rather not be chasing a moving target. Cheers, Edward
Re: [whatwg] salvaging work while navigating away from a web app -- onunload=confirm('save before quitting?')
On Sun, Dec 14, 2008 at 10:30 PM, Martin Atkins m...@degeneration.co.uk wrote: An alternative from Opera: The confirm dialog is whole-browser-modal, but it has a checkbox captioned Stop executing scripts on this page which allows you to forcefully kill off a script that's repeatedly displaying dialogs as in the example that prompted this message. neither of these bother me. and i'm certainly in favor of adding a stop option to the dialogs for firefox. it's definitely managable. today some of our dialogs get an extra 'debug script' button under certain conditions. The only concern I have is that someone from UE/UI will complain that such a button will confuse people, as it becomes trivial for a user to break any web site and not necessarily understand that what they did was the cause. However, that's a bridge I'm willing to try to cross. I think enabling the button only after multiple repeated dialogs would be a reasonable compromise, perhaps with an Are you sure? confirmation. -- Andy Lyttle wha...@phroggy.com
Re: [whatwg] Stability of tokenizing/dom algorithms
On 14 Dec 2008, at 21:55, Edward Z. Yang wrote: Are there any specific differences that pose problems? Not that I know of yet, since I haven't started on an implementation yet. Which brings me back to my original question: how stable is section 8? I would rather not be chasing a moving target. It's not really a moving target — what it is is largely constrained by the requirement to parse pre-existing documents (which rely on almost every possible bit of behaviour). If you do start work on a PHP implementation, please do seriously consider adding it to the html5lib project (which currently contains Python and Ruby implementations) as MIT licensed — there are also a fair number of test cases there. -- Geoffrey Sneddon http://gsnedders.com/
Re: [whatwg] Stability of tokenizing/dom algorithms
On Sun, 14 Dec 2008, Edward Z. Yang wrote: I was curious to know how stable/complete HTML 5's tokenizing and DOM algorithms are (specifically section 8). Pretty stable. There are some known issues [1], and more issues will surely be found as implementations grow in usage, but the basic architecture is unlikely to change and the specifics are unlikely to change much. The only major pending change is adding SVG, but that will likely be done in a way similar to what is currently specified but commented out. [1] Mostly listed here: http://www.whatwg.org/issues/#parsing The reason I'd like to know this is because I am the author of a tool named HTML Purifier, which takes user-input HTML and cleans it for standards-compliance as well as XSS. We insist on output being standards compliant, because the result is unambiguous. As far as I can tell, this is quite unlike the tools that HTML5 is tooled towards; compliance checkers, user agents and data miners. There certainly is overlap: we have our own parsing and DOM-building algorithms which work decently well, although they do trip up on a number of edge-cases (active formatting elements being one notable example). However, using the HTML5 algorithm wholesale is not possible for several reasons: 1. Users input HTML fragments, not actual HTML documents. A parser I would use needs to be able to enter parsing in a specific state, and has to ignore any requests by the user to exit that state (i.e. a /body tag) As Anne pointed out, we do have a section to handle that case (it's similar to innerHTML in browsers); if there's anything I can do to make those sections more helpful to you, please let me know. 2. No one actually codes their HTML in HTML5 (yet), so the only parts of the algorithm I want to use are the ones that are emulating browser behavior with HTML4. However, HTML5 interweaves it's additions with the browser research it has done. In general you should be able to just implement what the spec says and then either leave the HTML5 support in (it's unlikely to cause any harm) or just comment out the support for the new elements, that should be relatively easy. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
