Re: SpellCheck API?
Greetings all, Thank you so much for all of your comments. Even though I cannot answer all of them, I have added my responses to some comments. On Mon, May 9, 2011 at 5:58 PM, Hironori Bono (坊野 博典) wrote: > function CheckText(text) { > var result = new Array; > var app = new ActiveXObject('Word.Application'); > var doc = app.Documents.Add(); > doc.Content = text; > for (var i = 1; i <= doc.SpellingErrors.Count; i++) { > var spellingError = doc.SpellingErrors.Item(i); > for (var j = 1; j <= spellingError.Words.Count; j++) { > var word = spellingError.Words.Item(j); > var error = {}; > error.word = word.Text; > error.start = word.Start; > error.length = word.Text.length; > error.suggestions = new Array; > var suggestions = word.GetSpellingSuggestions(); > for (var k = 1; k <= suggestions.Count; k++) { > error.suggestions.push(suggestions.Item(k).Name); > } > result.push(error); > } Sorry. I forgot adding app.Quit(false) here to terminate Microsoft Word. > } > return result; > } On Mon, May 9, 2011 at 7:41 PM, Olli Pettay wrote: > Providing scripting access to built-in spellchecker is a privacy > violation (this has been discussed in @whatwg mailing list) - > web page could know which language users uses/has for spellchecking > and if user has added new word to the known-words list. Thank you for noticing it. I remembered this discussion. Even though I do not have clear solutions for this privacy violation now, it may be a good idea to focus on methods that help implementing custom spellcheckers until we find one. (That is, I will remove methods that have privacy concerns until we find solutions for them.) On Tue, May 10, 2011 at 4:39 AM, Aryeh Gregor wrote: > It would be much simpler for authors if the UA just fired an event > every time it did a spellcheck. The event might work like this: Thank you for your comment. Even though I initially thought of this option, I abandoned it because I did not find good ideas that satisfied all the requests from web-application developers with this event. > * Every time the UA would normally invoke its spellchecker on a word, > it fires a spellcheck event at the element in question, which bubbles > (so authors can set a handler on the body if they like). This has to > occur when a spellcheckable element first loads, if an element becomes > spellcheckable when it wasn't before, or whenever the user modifies a > spellcheckable element such that the spellchecker would normally fire > (e.g., when they finish typing a word). When I talked with web-application developers, some of them liked to check spellings of words not only when a user types words but also when JavaScript code creates an editable element with prepopulated text. For example, a web application checks text in a To: field with its custom spellchecker and adds misspelled underlines under "invalid" e-mail addresses. (This example is mainly for notifying users that they may be replying phishing e-mails.) Some other web-application developers also like to check spelling of words in an editable element before sending text to a server. To satisfy these requests, a user agent may need to send spellcheck events also when JavaScript code creates an editable node or changes text in an editable node. (Even though I have not measured how much time it takes to send these events without JavaScript execution, it may hurt the speed of JavaScript code.) > * The event object should provide the text of the word whose spelling > needs to be checked. It should give the node and start/end offsets, > either of the input/textarea or the text node. (Not sure what should > happen for a misspelled word that's not all in one text node.) When I talked with web-application developers, some of them liked to integrate n-gram spellcheckers so they can correct simple grammatical errors, such as article-noun mismatches ("a apple" -> "an apple") and subject-verb mismatches ("he have" -> "he has"). To satisfy their requests, a user agent may need to send two words or more (up to all words in an editable element). > This means authors wouldn't have to do word-breaking themselves, which > is a big advantage, since word-breaking can be very complicated. I agree a word-breaking algorithm is complicated, especially languages that do not insert space characters between words (e.g. Chinese, Japanese, Thai, etc.) The word-breaking algorithm becomes more complicated if it includes breaking a compound word (used by German, Hungarian, Turkish, etc.) into words. Some web-application developers like a user agent to do it. (Maybe a user agent needs to provide another method that breaks text into words?) On the other hand, other web-application developers would like to split text into words by themselves. As noted above, some developers like to integrate n-gram spellcheckers and they do not like for a user agent to split text into words. > It w
Re: SpellCheck API?
On 05/10/2011 08:33 PM, Adam Shannon wrote: On Tue, May 10, 2011 at 06:49, Olli Pettay wrote: On 05/10/2011 01:44 AM, Aryeh Gregor wrote: On Mon, May 9, 2011 at 3:49 PM, Boris Zbarskywrote: This does mean firing tens of thousands of events during load on some pages (e.g. wikipedia article edit pages) Maybe that's not a big deal. If that's too many events, couldn't the browser optimize by not spellchecking words until they scroll into view? I imagine that might not be terribly simple, depending on how the browser is designed, but maybe tens of thousands of events aren't too expensive anyway. I don't know, up to implementers whether it's doable. I'm assuming here that there's effectively no cost if no one's registered a spellcheck handler, so it won't penalize authors who don't use the feature. Just a quick test on Nokia N900 (which is already a bit old mobile phone) using a recent browser: dispatching 1 events to a deep (depth 100) DOM (without listeners for the event - for testing purposes) takes about 3 seconds. If there is a listener, the test takes 4-5s per 1 events. If the DOM is shallow, the test without listeners takes about 1s, and with a listener about 2-3s. This is just one browser engine, but based on my testing on desktop, the differences between browser engines aren't in order of magnitude in this case. On a fast desktop those tests take 50-200ms. So, tens of thousands events doesn't sounds like a fast enough solution for mobile devices, but would be ok for desktop, I think. -Olli On the desktop I wouldn't call that an "acceptable" solution; requiring 200ms+ just to spell check words on a page? That 200ms+ is only for the case when web page wants to do its own spellchecking and has reasonable large block of text to check. In the common case when the web page relies fully on the browser's native spellchecking, no events would be fired. But yeah, 200ms is quite a lot anyway. -Olli
Re: SpellCheck API?
On Tue, May 10, 2011 at 7:49 AM, Olli Pettay wrote: > Just a quick test on Nokia N900 (which is already a bit old mobile > phone) using a recent browser: > dispatching 1 events to a deep (depth 100) DOM (without > listeners for the event - for testing purposes) takes about 3 seconds. How did you test this? Specifically, couldn't a real-world browser optimize by not dispatching the events at all unless there's a listener? > If there is a listener, the test takes 4-5s per 1 events. > > If the DOM is shallow, the test without listeners takes about 1s, > and with a listener about 2-3s. > > This is just one browser engine, but based on my testing on desktop, the > differences between browser engines aren't in order of > magnitude in this case. > On a fast desktop those tests take 50-200ms. > > So, tens of thousands events doesn't sounds like a fast enough > solution for mobile devices, but would be ok for desktop, I think. For a worst case this might be okay, if everyone agrees with me that an event-based API would be vastly better for authors. Particularly if browsers only dispatch the event when the words are visible. Alternatively, the API could be changed so that the browser is allowed to dispatch one spellcheck event for as many words as it likes, and the event object would just have arrays where I had scalar values: it would pass in an array of words, and expect an array of arrays of suggestions in return. How does that sound?
Re: SpellCheck API?
On 05/10/2011 08:33 PM, Aryeh Gregor wrote: On Tue, May 10, 2011 at 7:49 AM, Olli Pettay wrote: Just a quick test on Nokia N900 (which is already a bit old mobile phone) using a recent browser: dispatching 1 events to a deep (depth 100) DOM (without listeners for the event - for testing purposes) takes about 3 seconds. How did you test this? Specifically, couldn't a real-world browser optimize by not dispatching the events at all unless there's a listener? Sure. If there are no listeners for spellcheck event, browser could optimize it out. But if there is the listener, event needs to be fired. And note, the test where there was a listener is trivial (just doing ++foo; ), so in real world web apps the listener would take more time. If there is a listener, the test takes 4-5s per 1 events. If the DOM is shallow, the test without listeners takes about 1s, and with a listener about 2-3s. This is just one browser engine, but based on my testing on desktop, the differences between browser engines aren't in order of magnitude in this case. On a fast desktop those tests take 50-200ms. So, tens of thousands events doesn't sounds like a fast enough solution for mobile devices, but would be ok for desktop, I think. For a worst case this might be okay, if everyone agrees with me that an event-based API would be vastly better for authors. Particularly if browsers only dispatch the event when the words are visible. That is tricky. What is being "visible"? The whole page might be painted in Panorama-like thingie for example. Alternatively, the API could be changed so that the browser is allowed to dispatch one spellcheck event for as many words as it likes, and the event object would just have arrays where I had scalar values: it would pass in an array of words, and expect an array of arrays of suggestions in return. How does that sound? Something like that might be better. Do you have the exact API in mind? -Olli
Re: Model-driven Views
From: Rafael Weinsteinmailto:rafa...@google.com?Subject=Re%3A%20Model-driven%20Views&In-Reply-To=%253CBANLkTimZcXiO8U8xHg2Y6eT4igixkCiF7w%40mail.gmail.com%253E&References=%253CBANLkTimZcXiO8U8xHg2Y6eT4igixkCiF7w%40mail.gmail.com%253E>> It sounds like the group wants to proceed by looking first at missing primitives. Maciej is right that one of them is the ability to declare inert DOM structures, In XForms we use the /instance/ element to do this. but my feeling is that it's probably best to start with the central problem: -There's no way to observe mutations to JS objects. I'll give some comments on this second question, but first I'll go through how we do "inert DOM structures" using the instance element. Of course, in spec-land we do it by describing the /instance element /and its interactions with expressions referring to it, and with DOM events, but in the context of the current discussion about adding new webapps support, it's important to take a look at how it's achieved in today's client-side implementations of XForms in common desktop browsers. There are two main approaches: The AgenceXML implementation uses an XSLT PI at the top to parse out the XForms namespaced elements, and when xhtml:head/xforms:model/xforms:instance with element content is seen, it's converted into a DOM object. The Ubiquity XForms implementation uses a purely Javascript-based approach to this transformation, without using the XSLT PI, but it suffers the treatment non-HTML elements receive when appearing lexically in the host document DOM. As far as feature definition of the "inert DOM structure" goes, here's a brief overview of how we use instance in XForms, and then I'll segue into how separating data and presentation makes the mutation observation question solvable. Additionally, note that XForms allows for an @src attribute on instance which specifies a resource to be loaded; there's a DOM event which signals that it's time to do this, and the XForms processor responds to that event. Finally, XForms offers a /submission/ element which can submit data from an ID'd instance, and send data from responses back to instances or parts thereof. For example, red 3 Color: Size: Your price: Buy When the page is loaded, the instance XML will get initialized with the data. When the user interacts with the form controls, changes will be commited to the instance data. When the user presses the submit button labeled Buy, the submission will POST the instance data. Since the submission says replace instance, the submitted instance will be replaced. Note that the initial data contains no price, so the output bound to "price" will not display at all; it's considered /irrelevant/. When the response comes back, if it has a price, it will then display, along with its label. Let's say you wanted to split the request and response into two different pieces of XML and not share them in the page. Just add a second instance, and now put ID attributes on the two: red 3 ref="instance('rfq') replace="instance" target="quote" /> Color: Size: Your price: Buy Note the changes in the submission to show that the data from the "rfq" instance and the response goes to "quote." If some sub-part of the instance were to be submitted, it would be done inside that expressions. Now, let's assume that performing a request for a quote is idempotent and has no side effects. REST web architecture would have us use a GET instead of a POST. XForms uses sensible defaults, so the GET will serialize leaf-node data as application/x-www-url-formencoded, so all we need to do is change the method on the submission from POST to GET: red 3 Color: Size: Your price: Buy Let's move the initial order out of the form and into a resource on the server by changing instance to have a src attribute: Color: Size: Your price: Buy where initial-quote.xml has the obvious content, and is served up with an HTTP GET. Let's flesh out the data layer a bit with some datatypes and constraints. Let's say size is an integer and it's constrained to be 0 to 14. We do this declaratively by binding a datatype and a constraint to the size node. Furthermore, let's make sure that both color and size aren't empty with required="true()": required="true()" /> Color: Size: Your price: Buy Now the form won't submit (and if you try will raise an xforms-submit-error DOM event with the context information), and any form controls bound to the invalid nodes will receive xforms-invalid events when the user interacts with them. Furthermore, those controls will also get CSS pseudo-property :invalid. (They're also similarly have :required and xforms-required events). So this interestingly answers Rafael's questions below about mutations. In XForms, the mutations happen to the data model, but the obser
Re: SpellCheck API?
On 05/10/2011 01:44 AM, Aryeh Gregor wrote: On Mon, May 9, 2011 at 3:49 PM, Boris Zbarsky wrote: This does mean firing tens of thousands of events during load on some pages (e.g. wikipedia article edit pages) Maybe that's not a big deal. If that's too many events, couldn't the browser optimize by not spellchecking words until they scroll into view? I imagine that might not be terribly simple, depending on how the browser is designed, but maybe tens of thousands of events aren't too expensive anyway. I don't know, up to implementers whether it's doable. I'm assuming here that there's effectively no cost if no one's registered a spellcheck handler, so it won't penalize authors who don't use the feature. Just a quick test on Nokia N900 (which is already a bit old mobile phone) using a recent browser: dispatching 1 events to a deep (depth 100) DOM (without listeners for the event - for testing purposes) takes about 3 seconds. If there is a listener, the test takes 4-5s per 1 events. If the DOM is shallow, the test without listeners takes about 1s, and with a listener about 2-3s. This is just one browser engine, but based on my testing on desktop, the differences between browser engines aren't in order of magnitude in this case. On a fast desktop those tests take 50-200ms. So, tens of thousands events doesn't sounds like a fast enough solution for mobile devices, but would be ok for desktop, I think. -Olli
Re: clipboard events
On Tue, May 10, 2011 at 8:41 AM, timeless wrote: > I'm not really excited by the return of the attack on context menus. > Allowing web sites to hold user's browsers hostage is a bad starting > point. It might be ok if the user had to first opt into rich editing - > maybe. > > Note that we only recently added protection for users against 'what > you see is not what you copy' (serializers are now fairly css aware). > Neither do I but it's a user agent issue to provide ways to override sites using this feature in a way that affects user negatively, because the feature and the use case is legitimate. Anyway, it would not introduce a new problem given that overriding clipboard contents is done already, although by a select few, using plugins, or if copy events are supported, after the copy event, using setData. So ignoring the use case just gives a false sense of security.
Re: [WebIDL][Selectors-API] Stringifying null for DOMString attributes and properties
On 2011-05-09 22:31, Jonas Sicking wrote: On Mon, May 9, 2011 at 9:22 AM, Lachlan Hunt wrote: Every other tested property on HTML*Element interfaces stringified to "null". What about namespaceURI, in various APIs (DOM-Core, DOM-XPath). Node.namespaceURI is readonly according to DOM3 Core, so setting it to null has no effect. But I just tested createElementNS() and got the following results: var el = document.createElementNS(null, "foo"); Firefox, WebKit, Opera, IE: el.namespaceURI returns null el.prefix returns null el.localName returns "foo"; returns "FOO" in Opera Same result as invoking createElementNS("", "foo"); var el = document.createElementNS(null, null); Firefox, WebKit, Opera (internal) throw INVALID_CHARACTER_ERR Same result as invoking createElementNS("", ""); Opera 11, IE 9: el.namespaceURI returns null el.prefix returns null el.localName returns "null" in IE; returns "NULL" in Opera Same result as invoking createElementNS("", "null"); In general, my main priority is that we make things as consistent as possible. My second priority is that we make things follow JS behavior. So I'd be very happy if we can get away with making the just the above list stringify to "", and the rest of the DOM stringify to "null". We had a site compatibility bug with at least one property recently, (input.max = null), that we were stringifying to "null", but where the site is expecting WebKit-compatible behaviour. We've also had similar compat problems in the past with some CSSOM properties, although they have since been defined as nullable types in that spec. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: clipboard events
Can you expand on what kind of protection this was? Isn't it simply the same as a "copy static content", "copy text", or "really copy" kind of command? paul Le 10 mai 2011 à 09:41, timeless a écrit : > Note that we only recently added protection for users against 'what > you see is not what you copy' (serializers are now fairly css aware).
Re: clipboard events
The alternative is sites that attempt to implement this functionality by preventing the default and clearing all the data on the clipboard instead. I'm not really sure that's any better. Daniel On Tue, May 10, 2011 at 00:41, timeless wrote: > I'm not really excited by the return of the attack on context menus. > Allowing web sites to hold user's browsers hostage is a bad starting > point. It might be ok if the user had to first opt into rich editing - > maybe. > > Note that we only recently added protection for users against 'what > you see is not what you copy' (serializers are now fairly css aware). > > On 5/10/11, Daniel Cheng wrote: > > On Mon, May 9, 2011 at 23:31, Paul Libbrecht wrote: > > > >> > >> Le 10 mai 2011 à 00:18, João Eiras a écrit : > >> > >> >> I would just model the 'copy' (and 'cut') events exactly as a > >> 'dragstart' > >> >> event, ideally so much so that you can literally use the same > function > >> for > >> >> both. (Canceling 'cut' would prevent the default deletion of the > >> >> selection, canceling 'copy' has no effect.) > >> > > >> > Shouldn't canceling 'copy' prevent the data from being placed in the > >> clipboard ? > >> > >> I am not sure of the above. I feel it should either be: > >> A- this (stop the copy, triggering an error) > >> B- or remove all of the script's modifications of the clipboard data and > >> leaves it to the "native copy" > >> > >> The advantage with B is that it prevents scripts that would try to > prevent > >> a copy which is important I feel. > >> > >> > That way a script can instead explicitly set the contents of the > >> clipboard, if some sanitization needs to be done. > >> > >> I do not think this should be possible since writing to clipboard should > >> only be doable with a copy event triggered by the environment (typically > >> at > >> the invocation of the standard gesture). > >> > >> paul > >> > > > > I would expect scripts to want one of two things when they're preventing > the > > default action: > > 1. They want to set their own data in the clipboard instead of what the > > browser would normally provide by default--for example, a document editor > > that does its own layout instead of using contenteditable. > > 2. They don't want to allow someone to copy data--perhaps it's data on a > > sensitive page. > > > > I think it's important to enable both. > > > > Originally, I wanted to rewrite the copy/cut events to work like this in > > WebKit: > > 1. Fire a copy event at the DOM. > > 2. If the default action was cancelled and event.clipboardData was not > > mutated, simply return without doing anything. > > 3. If the default action was cancelled and event.clipboardData was > mutated, > > replace the contents of the system clipboard with the contents of > > event.clipboardData. > > 4. Otherwise, if the default action is not cancelled, proceed with the > > default clipboard population behavior. > > > > I'm not sure if a 'dirty' bit on clipboardData is a great signal to use > > though. > > > > Daniel > > > > -- > Sent from my mobile device >
Re: clipboard events
I'm not really excited by the return of the attack on context menus. Allowing web sites to hold user's browsers hostage is a bad starting point. It might be ok if the user had to first opt into rich editing - maybe. Note that we only recently added protection for users against 'what you see is not what you copy' (serializers are now fairly css aware). On 5/10/11, Daniel Cheng wrote: > On Mon, May 9, 2011 at 23:31, Paul Libbrecht wrote: > >> >> Le 10 mai 2011 à 00:18, João Eiras a écrit : >> >> >> I would just model the 'copy' (and 'cut') events exactly as a >> 'dragstart' >> >> event, ideally so much so that you can literally use the same function >> for >> >> both. (Canceling 'cut' would prevent the default deletion of the >> >> selection, canceling 'copy' has no effect.) >> > >> > Shouldn't canceling 'copy' prevent the data from being placed in the >> clipboard ? >> >> I am not sure of the above. I feel it should either be: >> A- this (stop the copy, triggering an error) >> B- or remove all of the script's modifications of the clipboard data and >> leaves it to the "native copy" >> >> The advantage with B is that it prevents scripts that would try to prevent >> a copy which is important I feel. >> >> > That way a script can instead explicitly set the contents of the >> clipboard, if some sanitization needs to be done. >> >> I do not think this should be possible since writing to clipboard should >> only be doable with a copy event triggered by the environment (typically >> at >> the invocation of the standard gesture). >> >> paul >> > > I would expect scripts to want one of two things when they're preventing the > default action: > 1. They want to set their own data in the clipboard instead of what the > browser would normally provide by default--for example, a document editor > that does its own layout instead of using contenteditable. > 2. They don't want to allow someone to copy data--perhaps it's data on a > sensitive page. > > I think it's important to enable both. > > Originally, I wanted to rewrite the copy/cut events to work like this in > WebKit: > 1. Fire a copy event at the DOM. > 2. If the default action was cancelled and event.clipboardData was not > mutated, simply return without doing anything. > 3. If the default action was cancelled and event.clipboardData was mutated, > replace the contents of the system clipboard with the contents of > event.clipboardData. > 4. Otherwise, if the default action is not cancelled, proceed with the > default clipboard population behavior. > > I'm not sure if a 'dirty' bit on clipboardData is a great signal to use > though. > > Daniel > -- Sent from my mobile device
Re: clipboard events
Le 10 mai 2011 à 09:13, Daniel Cheng a écrit : > I would expect scripts to want one of two things when they're preventing the > default action: > 1. They want to set their own data in the clipboard instead of what the > browser would normally provide by default--for example, a document editor > that does its own layout instead of using contenteditable. That sure is desirable. I am not clear between "instead" or "on top of" (or both). > 2. They don't want to allow someone to copy data--perhaps it's data on a > sensitive page. > I think it's important to enable both. I would be fierciely opposed to allow this and I remember Jonas Sicking was so as well. This would certainly be a loss of freedom from users which I believe is not really nice. But I realize that allowing 1 simply allows 2 as a special case. We should make it more clear that sites that do that should ponder twice the loss of freedom thus removed. paul
Re: clipboard events
On Mon, May 9, 2011 at 23:31, Paul Libbrecht wrote: > > Le 10 mai 2011 à 00:18, João Eiras a écrit : > > >> I would just model the 'copy' (and 'cut') events exactly as a > 'dragstart' > >> event, ideally so much so that you can literally use the same function > for > >> both. (Canceling 'cut' would prevent the default deletion of the > >> selection, canceling 'copy' has no effect.) > > > > Shouldn't canceling 'copy' prevent the data from being placed in the > clipboard ? > > I am not sure of the above. I feel it should either be: > A- this (stop the copy, triggering an error) > B- or remove all of the script's modifications of the clipboard data and > leaves it to the "native copy" > > The advantage with B is that it prevents scripts that would try to prevent > a copy which is important I feel. > > > That way a script can instead explicitly set the contents of the > clipboard, if some sanitization needs to be done. > > I do not think this should be possible since writing to clipboard should > only be doable with a copy event triggered by the environment (typically at > the invocation of the standard gesture). > > paul > I would expect scripts to want one of two things when they're preventing the default action: 1. They want to set their own data in the clipboard instead of what the browser would normally provide by default--for example, a document editor that does its own layout instead of using contenteditable. 2. They don't want to allow someone to copy data--perhaps it's data on a sensitive page. I think it's important to enable both. Originally, I wanted to rewrite the copy/cut events to work like this in WebKit: 1. Fire a copy event at the DOM. 2. If the default action was cancelled and event.clipboardData was not mutated, simply return without doing anything. 3. If the default action was cancelled and event.clipboardData was mutated, replace the contents of the system clipboard with the contents of event.clipboardData. 4. Otherwise, if the default action is not cancelled, proceed with the default clipboard population behavior. I'm not sure if a 'dirty' bit on clipboardData is a great signal to use though. Daniel