clipboard data types registry?
Hi, some thoughts regarding the CCnP (Cut, Copy and Paste) events spec and custom/arbitrary data types. Ideally, the computer should do what the user intends. When pasting data, we should aim to share the data the user intends to share. Hence, if the raw clipboard data contains information the user likely isn't aware of being there - such as file system paths, software identifying markers, session IDs and tokens from other web sites - we should to some extent aim to filter out such information. My understanding - because of feedback like the quote from Daniel Cheng below [1] - is that this can really only be done on a per-data-type basis. (For example, while we should try to filter out file system paths from many types of data, if I place a file system path on the clipboard as plain text and paste it into a web service, the filtering should obviously not be applied). The logical conclusion is that to write a really implementable spec with complete information, we need some kind of registry, mapping MIME/clipboard types to filtering algorithms.. This registry might be as simple as a TABLE inside the spec itself, or it might be something maintained outside of it. I guess it will be considered too application-specific for the common MIME type registry, though? Thoughts and views? Is a registry overkill, or useful? Should it be in-spec or a separate entity with individual updates? If separate, does the W3C have infrastructure for such stuff or do we put the information somewhere else? [1] I changed the Clipboard implementation in WebKit to directly mirror the contents of the native clipboard. As a result though, pages could access a bunch of random types that included full filesystem paths as part of their data when dragging a file. I suspect that the list of types that happens to leak filesystem paths will vary based on the window manager in use. Because of this, I'm choosing to restrict the number of native types to a smaller, defined set that are visible to webpages. Any paths in this set can be filtered as necessary when a file drag is detected. (Daniel Cheng, http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0297.html ) -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
Re: API for matrix manipulation
Just wanted to throw in Sylvester, which is a fairly cool Math JS lib for generic Matrix and Vector computations (http://sylvester.jcoglan.com/). I especially like it as the API feels like it is designed for human beings. Having Matrix/Vector as generic interfaces sounds like a big win. Am 18.03.11 21:50 schrieb Chris Marrin unter cmar...@apple.com: On Mar 15, 2011, at 5:08 PM, Tab Atkins Jr. wrote: On Tue, Mar 15, 2011 at 5:00 PM, Chris Marrin cmar...@apple.com wrote: I think it would be nice to unify the classes somehow. But that might be difficult since SVG and CSS are (necessarily) separate specs. But maybe one of the API gurus has a solution? We just discussed this on Monday at the FXTF telcon. Sounds like people are, in general, okay with just using a 4x4 matrix, though there are some possible implementation issues with devices that can't do 3d at all. (It was suggested that they can simply do a 2d projection, which is simple.) I don't think there are implementation issues other than performance related ones. As you say, you can always flatten a 3D matrix for use in a purely 2D renderer. We do this in the WebKit implementation in some cases. But doing 4x4 matrix math can be expensive, especially on less capable hardware,. So it would probably be valuable to have a set of 2D affine calls on any future 4x4 class, so an implementation can easily optimize by knowing they can get away with doing a subset of the math if all the operands are 2D affine matrices. But that's just a bit of extra API. - ~Chris cmar...@apple.com
[widgets] New draft of PC
Hi, A new Last Call WD of PC went out today: http://www.w3.org/TR/widgets/ What's new? * defaultlocale attribute on widget object * bunch of editorial clarifications and cosmetic changes See all the details here: http://www.w3.org/TR/widgets/#changes Looking forward to any feedback by the 1st of May. -- Marcos Caceres Opera Software ASA, http://www.opera.com/ http://datadriven.com.au
[widget] Fixed some tests in Widget Interface test suite
The following tests have been fixed in the widget interface TS... and also in the PC test suite (indicated below). 1. i18nrlo02 Tests that RLO direction applies to the name element's short attribute. This test is test case for direction of short name. But there was no short name in the config.xml http://dev.w3.org/2006/waf/widgets-api/test-suite/test-cases/i18n-rlo/002/i18nrlo02.wgt 2. i18nltr37 (fixed for PC also) This test is test case for direction of email attribute. Config.xml : author email=The arrow should point right -- dir=ltr / but hook.js said propEquals(authorEmail, PASS); http://dev.w3.org/2006/waf/widgets-api/test-suite/test-cases/i18n-ltr/037/i18nltr37.wgt 3. i18nrlo44 (fixed for PC also) Config.xml : nameSSAP/name - apply by rlo : PASS Hook.js : propEquals(name, \u202EPASS\u202C); - \u202EPASS\u202C); is SSAP. This has now been corrected. http://dev.w3.org/2006/waf/widgets-api/test-suite/test-cases/i18n-rlo/044/i18nrlo44.wgt -- Marcos Caceres Opera Software
RE: [IndexedDB] Spec changes for international language support
From: keean.schu...@googlemail.com [mailto:keean.schu...@googlemail.com] On
Behalf Of Keean Schupke
Sent: Friday, March 18, 2011 8:17 PM
On 18 March 2011 19:29, Pablo Castro pablo.cas...@microsoft.com wrote:
From: keean.schu...@googlemail.com [mailto:keean.schu...@googlemail.com] On
Behalf Of Keean Schupke
Sent: Friday, March 18, 2011 1:53 AM
See my proposal in another thread. The basic idea is to copy BDB. Have a
primary index that is based on an integer, something primitive and fast.
Allow secondary indexes which use a callback to generate a binary index
key. IDB shifts the complexity out into a library. Common use cases can
be provided (a hash of all fields in the object, internationalised
bidirectional lexicographic etc...), but the user is free to write their
own for less usual cases (for example indexing by the last word in a name
string to order by surname).
I agree with Jeremy's comments on the other thread for this. Having the
callback mechanism definitely sounds interesting but there are a ton of common
cases that we can solve by just taking a language identifier, I'm not sure we
want to make people work hard to get something that's already supported in most
systems. The idea of having a callback to compute the index value feels
incremental to this, so we could take on it later on without disrupting the
explicit international collation stuff.
The idea would be to provide pre-defined implementations of the callback for
common use cases, then it is just as simple to register a callback as set
any other option. All this means to the API is you pass a function instead
of a string. It also is better for modularity as all the code relating to
the sort order is kept in the callback functions.
The difference comes down to something like:
index.set_order_lexicographic('us');
vs
index.set_order_method(order_lexicographic('us'));
So more than just setting a property like the first case, where presumably
all the ordering code is mixed in with the indexing code, the second case
encapsulates all the ordering code in the function returned from the
execution of order_lexicographic('us'). This function would represent a
mapping from the object being indexed to a binary blob that is the actual
stored index data.
So doing it this was does not necessarily make things harder, and it
improves encapsulation, the type-safety, and the flexibility of the API.
Yep, we talked about supporting callbacks already in the other threads and in
this one. As I mentioned before, I think this is an incremental to the basic
feature of taking a collation name. I do realize you can just pass a
pre-implemented function, but that opens the door to a bunch of things we'd
need to handle, including storing possibly storing code in the database (such
that proper updates don't depend on each page re-registering all the index
callbacks), handling scripts with the appropriate context to run during index
updates, etc. I would much rather have basic functionality in place and then
expand as needed once we have users using the API.
Thanks
-pablo
Re: [IndexedDB] Spec changes for international language support
On Tue, Mar 22, 2011 at 6:13 PM, Pablo Castro pablo.cas...@microsoft.com wrote: From: keean.schu...@googlemail.com [mailto:keean.schu...@googlemail.com] On Behalf Of Keean Schupke Sent: Tuesday, March 22, 2011 5:34 PM IMHO not the job of Idb to store the callbacks, so I don't see this complexity as a reason not to implement the API using callbacks. I think having one consistent API is more important. Specifying the collation 'name' has all the same problems as callbacks (needs to be re-done on every page, possibility of using different collations on different pages). Really a 'function' is just a symbol for a collation. A function name, is a better symbol for a collation than a string. Function's have a uniqueness property strings do not. So specifying a function as the collations instead of a string really is the same thing. Consider below: I don't think it's the same. If we don't store the callbacks in the database it means every page has to have full knowledge of the database schema (at least all the indexes) all the time, instead of just pulling that in on demand when needed. It also means we can never allow browser developer tools or generic dev-tool-webpages to modify the database because indexes would become invalid (not sure allowing tools to mess with the database in general is a good idea, but I thought it illustrated the point well). I wonder if the overall issue we're discussing has to do with how embedded the database is. In BDB scenarios where the database is completely invisible outside of an application many of these decisions make more sense. I don't think of web applications that way. I think of them more as a number of building blocks (pages, pieces within pages, tool pages added on the side) that are authored and sometimes even versioned independently, and the interface between those building blocks and the store is public and visible to tools and generic data browsers. All that changes the assumptions in the overall picture. Yup. I Agree with Pablo here. / Jonas
