Re: clipboard events
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
Re: clipboard events
On Mon, May 9, 2011 at 23:31, Paul Libbrecht p...@hoplahup.net 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
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
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 dch...@chromium.org wrote: On Mon, May 9, 2011 at 23:31, Paul Libbrecht p...@hoplahup.net 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
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 timel...@gmail.com 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 dch...@chromium.org wrote: On Mon, May 9, 2011 at 23:31, Paul Libbrecht p...@hoplahup.net 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
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: [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 Huntlachlan.h...@lachy.id.au 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
On Tue, May 10, 2011 at 8:41 AM, timeless timel...@gmail.com 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: SpellCheck API?
On 05/10/2011 01:44 AM, Aryeh Gregor wrote: On Mon, May 9, 2011 at 3:49 PM, Boris Zbarskybzbar...@mit.edu 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: Model-driven Views
From: Rafael Weinsteinrafa...@google.com mailto:rafa...@google.com?Subject=Re%3A%20Model-driven%20ViewsIn-Reply-To=%253CBANLkTimZcXiO8U8xHg2Y6eT4igixkCiF7w%40mail.gmail.com%253EReferences=%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,
html
head
model
instance
quote
colorred/color
size3/size
quote
/instance
submission id=price resource=/rfq method=post replace=instance /
/model
/head
body
input ref=color
labelColor: /color
/input
input ref=size
labelSize: /label
/input
output ref=price
labelYour price: /label
/output
submit submission=buy
labelBuy/label
/submit
/body
/html
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:
html
head
model
instance id=rfq
quote
colorred/color
size3/size
quote
/instance
instance id=quoteempty //instance
submission id=price resource=/rfq method=post
ref=instance('rfq') replace=instance target=quote /
/model
/head
body
/body
input ref=color
labelColor: /color
/input
input ref=size
labelSize: /label
/input
output ref=instance('quote')/price
labelYour price: /label
/output
submit submission=buy
labelBuy/label
/submit
/body
/html
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:
html
head
model
instance id=rfq
quote
colorred/color
size3/size
quote
/instance
instance id=quoteempty //instance
submission id=price resource=/rfq method=get ref=instance('rfq')
replace=instance target=quote /
/model
/head
body
/body
input ref=color
labelColor: /color
/input
input ref=size
labelSize: /label
/input
output ref=instance('quote')/price
labelYour price: /label
/output
submit submission=buy
labelBuy/label
/submit
/body
/html
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:
html
head
model
instance id=rfq src=initial-quote.xml /
instance
Re: SpellCheck API?
On 05/10/2011 08:33 PM, Aryeh Gregor wrote: On Tue, May 10, 2011 at 7:49 AM, Olli Pettayolli.pet...@helsinki.fi 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: SpellCheck API?
On Tue, May 10, 2011 at 7:49 AM, Olli Pettay olli.pet...@helsinki.fi 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, Adam Shannon wrote: On Tue, May 10, 2011 at 06:49, Olli Pettayolli.pet...@helsinki.fi wrote: On 05/10/2011 01:44 AM, Aryeh Gregor wrote: On Mon, May 9, 2011 at 3:49 PM, Boris Zbarskybzbar...@mit.eduwrote: 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?
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 (坊野 博典) hb...@google.com 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 olli.pet...@helsinki.fi 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 simetrical+...@gmail.com 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.
