Re: [charter] Request for Comments; deadline Sept 10
Art wrote: The proposal to merge the WebApps WG and the HTML WG has started a formal review period that ends September 10: http://w3c.github.io/charter-html/group-charter.html IRC: active participants, particularly editors, regularly use the #webapps W3C IRC channel is this channel intentionally inherited? I like it because it's shorter, but... If participants from less than three distinct browser-engine projects are participating in the group, its charter should be re-examined by the W3C. less = fewer personally, I'd prefer for this to be a link: Database and Offline Application APIs A set of objects and interfaces for client-side database functionality. will this link be updated: For more details, see the Web Platform WG Database API page. ... it's in /2008/webapps/, also, it'd be better if this link were on the section heading above The following Database APIs are deliverables under this charter: Indexed Database API (2nd Edition) missing period: An API for a database of records holding simple values and hierarchical objects Quota Management API An API for managing the amount of storage space (short- or long-term) available. Service Workers A new feature for the web platform that lets a script persistently cache resources and handle all resource requests for an application -- even when the network isn't available. Web Background Synchronization A specification describing a method that enables web applications to synchronize data when next online. Web Storage (2nd Edition) An API for persistent data storage of key-value pair data in Web clients. High level User Events it's odd that level isn't capitalized... (it isn't linked either) An API that enables web applications to select file objects and access their data. This replaces the File Upload specification. Could that specification be linked? (you can include a rel to avoid adding to its pagerank...) HTML it's odd that there's no link for this... The Group MAY define an API that provides access to a (native) input method editor application. an IME may not be an application, it's often just a component :) The Group MAY also define the mechanisms to fetch resources using the HTTP protocol and its extensions. drop `also` Packaging on the Web This document describes an approach for creating packages of files for use on the web. the style of this sentence doesn't match its cousins. Robust Anchoring API link to doc ? APIs for linking to a document selection, even when the document has changed. This is a joint deliverable with the Web Annotation WG. link to WG? Screen Orientation API A view orientation and locking API e.g. to enable reading the view's orientation state, locking view orientation, notification of view orientation state changes, etc. `,` before `e.g.` drop `etc.` Specifications that define mechanisms for adding custom elements to a document which allows them to have well-defined behaviour and rendering. behavior I'm not a fan of capitalizing `Web` alone, this document isn't particularly consistent, as noted by the excerpts below: This Group develops technologies that enhance accessibility of web content for people with disabilities, A new feature for the web platform that lets a script persistently cache resources A specification describing a method that enables web applications to synchronize data when next online. An API that allows Web application authors Each specification should contain a section detailing any known security implications for implementers, Web authors, I'd suggest you probably want to consistently capitalize `Web Platform` since that's the name of the group. The working group will maintain errata and new editions, as necessary, for the following Recommendation-status specifications: CORS DOM specifications while I'm sympathetic to not listing all DOM specs here, a link to an editable page listing all the specs would be appreciated. Web Storage (2nd edition): Recommendation expected in 2015 Web Workers: Recommendation expected in 2015 Web Sockets: Recommendation expected in 2015 XHR; Recommendation expected in early 2016 DOM Parsing and Serialization; Recommendation expected in early 2016 Web IDL; Recommendation expected in early 2016 s/;/:/g `the working group` isn't consistently capitalized: After a specification reaches Recommendation status the working group may begin work on, A number of specifications depend on the WebIDL specification, which is therefore a very high priority for the Working Group. The Web Sockets specification has an effective dependency on the protocol defined by the IETF's HyBi Working Group. Could the spec be linked? Given the large number of deliverables and therefore also dependencies between this working group and accessibility groups, the Web Platform team contact(s) will liaise with the team contact for Accessible Platform Architectures and Accessible
Re: CR: Web Storage (Second Edition)
http://www.w3.org/TR/2015/CR-webstorage-20150609/
Particpate: [sic]
the event must have its key attribute initialised to the name of the key in
question,
`initialized` [About 11,800,000 results] should be spelled as such for
w3c specs (w3c is en-us) instead of
`initialised` [About 553,000 results]
but require the user to authorise access to local storage areas.
`authorize` [About 80,100,000 results] should be spelled as such for
w3c specs (w3c is en-us) instead of `authorise` [About 6,960,000
results]
Alternatives that do not require a user-agent-wide per-origin script lock are
eagerly sought after.
sought-after [1]
Each site has its own separate storage area.
area = areas | storage = local storage
(must, should, may, etc)
etc.
If the given key does exist in the list, and its value is not equal to value,
then it must have its value updated to value. If its previous value is equal
to value, then the method must do nothing.
if the methods did not throw an exception or do nothing as defined above
it'd be nice if the above sections underlined/otherwise styled `do nothing`.
User agents should always avoid deleting data while a script that could
access that data is running.
consider a script which does:
var global_state = window.localStorage.getItem(value);
function uses_global_state() { if (global_state == 5) { }}
window.setTimeout(uses_global_state, 200);
between the script's initial execution, and the firing of the timeout,
is the script considered to be `running`?
[1] http://dictionary.reference.com/browse/sought-after
Re: PSA: publishing new WD of Service Workers on June 25
http://slightlyoff.github.io/ServiceWorker/publish/service_worker/WD-service-workers-20150625/ Invoke Run Service Worker algorithm with serviceWorker as the arguement [sic]. Fetch invokes Handle Fetch with request. As a result of performing Handle Fetch, the Service Woker [sic] returns a response to Fetch. If the client request is under the scope of a service worker registration, appplication [sic] cache is completely bypassed regardless of whether the client request uses the service worker registration. Events that correspond to network requests are dispatched to the worker and the responses generated by the worker may over-ride* default network stack behavior. override en-us: Let the origin attribute of e be initialized to the Unicode serialisation* of the origin specified by the incumbent settings object. Service workers define the following behaviours* for install event and activate event: When a service worker client is controlled by an active worker, it is considered the service worker client is using the active worker's containing service worker registration. this is awkward, you might add `that` after `it is` This is conceptually the same operation that UA does maximum once per every 24 hours. this is awkward, you might add `the` before `UA`, `a` after `does` and `of` before `once`. Run the following substeps in parallel: 1. CheckRegistration: If the result of running Match Service Worker Registration algorithm, or its equivalent, with clientURL as its argument is not null, then: 1.1. Set registration to the result value. 2. Else: Else seems odd for `run...in parallel` 2.1. Wait until scope to registration map has a new entry. 2.2. Jump to the step labeled CheckRegistration. cat spec|grep 'in parallel' | perl -pne 's/\s*,.*,\s*/ ... /;s/.*( run)/$1/;s/(the ).*( handler)/$1...$2/;s/^\s*/ /'|sort|uniq -c|sort -n|perl -pne 's/(?:\s*)(\d*)\s*(.*)\n/$2 [$1]\n/' Return the ... handler ... performs the following substeps in parallel: [1] Return the ... handler that performs the following substeps in parallel: [1] Run the following in parallel: [1] Set p to the ... handler that ... performs the following substeps in parallel: [1] run the following substeps in parallel: [1] Return the ... handler that ... performs the following substeps in parallel: [4] run the following substeps in parallel. [4] Run these steps in parallel: [7] Run the following substeps in parallel: [10] * you use steps|substeps interchangeably afaict; you sometimes don't use *steps... * you use .|: interchangeably * various other inconsistent stylistic elements can be seen from the above list... * in parallel isn't defined, but it sounds like you mean in parallel to the main sequence not in parallel to themselves, I'd strongly encourage a definition. The following are the event handlers (and its corresponding event handler event types) that must be supported, pattern: event handlers [plural!] (and its ...) its = their The service worker registration's installing worker changes. (See step 8 of the Install algorithm). A WindowClient object has an associated focus state, which is either true or false. (Initially false). pattern: misplaced `.` When event.respondWith(r) method is invoked, the argument, r, must resolve with a Response, else a network error is returned to Fetch. `must .. else` is an odd construct. normally `or` is appropriate... The Cache objects do not expire unless authors delete the entries. `objects ... the entries` is odd the entries = them | objects = object entries ?? This implies that authors should version their caches by name and make sure to **use the caches only from the version of the service worker that can safely operate on**. ... = to only use caches that can be safely operated by the current version of the service worker. Cache objects are always enumerable via self.caches in insertion order (per ECMAScript 6 Map objects.) Resolve p with the result of running the algorithm specified in match(request, options) method of Cache interface with request and options as the arguments (providing entry.[[value]] as thisArgument to the [[Call]] internal method of match(request, options).) pattern: misplaced `.` (the other way...) If r's method is neither `GET` nor `HEAD` and options.ignoreMethod is false, resolve promise with an empty array. If options.ignoreMethod is false and request.method is neither GET nor HEAD, then: you usually use ``s instead of s around GET/HEAD, which I found weird, but here you didn't do that, which I find even weirder...
[Pointer Lock] Comments
1. w3c is en-us
https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#abstract
modelling - modeling
2. Xlib
https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#h3_why-bundle-all-functionality-hiding-cursor-providing-mouse-deltas-instead-of-using-css-to-hide-the-cursor-always-providing-delta-values-and-offering-an-api-to-restrict-the-cursor-movement-to-a-portion-of-the-web-page
Direct APIs do not exist on all platforms (Win, Mac, Linux) to bound the
cursor to a specific rectangle, and prototypes have not yet been developed
to demonstrate building that behavior by e.g. invisible windows with xlib
or manual cursor movement on Mac.
Xlib - Wikipedia, the free encyclopedia --
http://en.wikipedia.org/wiki/Xlib
Also note that Mac is not a proper term, it could be Mac OS (X),
Macintosh ... or macs.
3. Mouse capture
https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#introduction
Pointer Lock is related to Mouse Capture [MDN-SETCAPTURE].
should https://www.w3.org/Bugs/Public/show_bug.cgi?id=14600 be noted?
MS should probably be referenced:
http://msdn.microsoft.com/en-us/library/ie/ms536742%28v=vs.85%29.aspx since
it's their fault...
4. a11y/i18n
https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#dfn-engagement-gesture
An event generated by the user agent as a result of user interaction
intended to interact with the page. e.g. click, but not mousemove.
Engagement gestures are any events included in the definition of being
allowed to show a popup with the addition of keypress and keyup.
shift, or control+shift and similar things are often used to trigger an
assistive technology, or an IME / language switch.
https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/access_stickykeys_settings.mspx?mfr=true
turn StickyKeys on or off by by pressing the SHIFT key five times
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/langbar_keystroke_shortcuts.mspx?mfr=true
Switch between languages or keyboard layouts CTRL+SHIFT or left ALT+SHIFT
http://support.microsoft.com/kb/97738
When you press the APOSTROPHE (') key, QUOTATION MARK () key, ACCENT
GRAVE (`) key, TILDE (~) key, ACCENT CIRCUMFLEX key, or CARET (^) key,
nothing appears on the screen until you press the a second key. If you
press one of the letters designated as eligible to receive an accent mark,
the accented version of the letter appears. If you press an ineligible key,
two separate characters appear. In other words, the US-International
keyboard layout dynamic-link library (DLL) automatically accents letters
that customarily receive an accent but does not automatically accent
letters that do not customarily receive an accent.
While it's nice to allow for keys to trigger a lock, keys that may
eventually be handled by something outside the UA should probably not be
eligible for this.
5. must
https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#pointerlockchange-and-pointerlockerror-events
Two events are used to communicate pointer lock state change or an error
in changing state. They are named pointerlockchange and pointerlockerror.
If pointer lock is entered or exited for any reason a pointerlockchange
event must be sent.
If I press ctrl-w/cmd-w (close window/tab), is the UA required to send
these events?
If an iframe has pointerlock, and its parent removes the iframe from the
dom, is the UA required to send these events?
If an iframe has pointerlock, and its parent changes the iframe's document
url to another page, is the UA required to send these events?
6. and
https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#widl-Element-requestPointerLock-void
(for example: mousemove, mousedown, mouseup, click, wheel)
(for example: mouseover, mouseout, drag, drop).
Please use and -- you do elsewhere:
clientX, clientY, screenX, and screenY
7. movement/focus
https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#widl-Element-requestPointerLock-void
Movement and button presses of the mouse must not cause the window to
lose focus.
Suppose I'm using Windows w/ a standard 104 key keyboard:
http://en.wikipedia.org/wiki/Computer_keyboard#mediaviewer/File:Qwerty.svg
If I press a system key (the Windows key), or a system key equivalent
stroke (ctrl+esc), I expect the application to lose focus.
http://developer.android.com/design/media/whats_new_nav_bar.png
If I press the home key on an Android device, I expect the window to lose
focus.
If a user is on a system where there is no hardware home button, but there
is a gesture which enables interacting with the system, the UA shouldn't be
out of compliance.
see Fast Quick Settings Access --
http://blogs.blackberry.com/2014/05/planned-new-features/
8. comma comma
https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#attributes
onpointerlockchange of type EventHandler, , nullable
the extra comma here is not
Re: April face-to-face meetings for HTML and WebApps
It's Passover [1]. Passover begins in the evening of Friday, April 6, 2012, and ends in the evening of Saturday, April 14, 2012. As it happens, your calendar hits the *end* of Passover which is just as major of a holiday as the beginning (the middle is somewhat minor). At the risk of being seen as supporting an information source [2]. The last silicon valley item was an offline webapps thing on a Saturday. That wasn't well considered and I have yet to see minutes from it. But seriously: Please NO. While I love my friends in the bay area and wouldn't mind visiting them for the holiday, it'd pretty much suck. Dear chairs, could you please create a basic meeting scheduling check-list: 1. Does it hit a Christian holiday? (I'm not sure what these are, perhaps Good Friday?) 2. Does it hit a Jewish holiday? (google or wikipedia, or timeanddate [3]) 3. Does it hit a Muslim holiday? (Ramadan) 4. Is it a Saturday? Bad (see 2) To help you out on that last one: Ramadan begins in the evening of Friday, July 20, 2012, and ends in the evening of Monday, August 20, 2012. Thank you for asking in advance so that we can *not* do it at this time. [1] http://www.google.com/search?client=ms-rimhl=enq=passover%202012ie=UTF-8oe=UTF-8channel=browser [2] http://mobile.askmoses.com/article/207,195848/What-is-Chol-Hamoed.html [3] http://www.timeanddate.com/holidays/us/ On 2/6/12, Philippe Le Hegaret p...@w3.org wrote: Folks, in order to facilitate the work of the WebApps and HTML Working Groups, I've been discussing with the Chairs the idea of having a face-to-face in the silicon valley in April. Due to various constraints (WWW2012 and Google I/O most notably), I ended up with the second week of April: - WebApps WG: April 10/11 (Tuesday/Wednesday) - HTML WG: April 12/13 (Thursday/Friday) - WebAppSec: April 11/12 (Wednesday/Thursday) Is anybody else aware of other potential conflicts? The WebKit contributor meeting dates are not set yet but may overlap with webapps for one day (April 10)... I asked the Chairs to ask for objections to those dates as well, Note that this meeting would be in addition to the TPAC 2012 in November (Lyon, France). Thank you, Philippe -- Sent from my mobile device
Fwd: Data compression APIs?
Since webapps is currently rechartering, is this something it wants to consider? Note that I'm not a member of webapps at this time. There have been some requests for zip support [1], and probably less relevant for xhr [2]. Note that the use case I'm forwarding [3] requires support for both compression and decompression. [1] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0567.html [2] http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0595.html [3] http://lists.w3.org/Archives/Public/public-identity/2012Jan/0002.html -- Forwarded message -- From: Mitch Zollinger mzollin...@netflix.com Date: Wed, 25 Jan 2012 17:11:57 -0800 Subject: Data compression APIs? To: public-ident...@w3.org public-ident...@w3.org In designing the technology that satisfies the use case doc posted previously (http://www.w3.org/wiki/NetflixWebCryptoUseCase) it would appear that we need to support compression / decompression APIs. The reason is that for our MsgSec protocol, we encrypt every message going over the wire and since encrypted data cannot be compressed, the compression has to happen before encryption. Therefore standard things like HTTP gzip compression will not work. What we're looking for is something along the lines of: function compress(data, algorithm) function uncompress(data, algorithm) where algorithm is one of the standard ones (gzip, bzip2, etc.) Is this the right forum for looking at this type of functionality? Mitch -- Sent from my mobile device
Re: [editing] tab in an editable area WAS: [whatwg] behavior when typing in contentEditable elements
Ojan Vafai o...@chromium.org wrote: We should make this configurable via execCommand: document.execCommand(TabBehavior, false, bitmask); The bitmask is because you might want a different set of behaviors: -Tabbing in lists -Tabbing in table cells -Tabbing blockquotes -Tab in none of the above insert a tab -Tab in none of the above insert X spaces (X is controlled by the CSS tab-size property?) We're trying to avoid introducing additional bitmasks into the web platform. Can we use a dictionary or string?
Re: Enable Compression Of A Blob To .zip File
I think crypto is supposed to be in scope of another WG that was being chartered nowish On 11/30/11, Joran Greef jo...@ronomon.com wrote: It would be great to have a native binding to Zlib and Snappy exposed to Javascript in the browser. Zlib covers the expensive disk use-cases, Snappy covers the expensive CPU use-cases. Also a native binding to basic crypto primitives, even if that means just SHA1 to start, and even if the Node.js crypto api is copied verbatim. TypedArrays are in current implementations are too slow to help with these, as far as I have tried. -- Sent from my mobile device
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
I'd like to request that people stop sending posts about web intents to public-webapps@w3.org and public-device-a...@w3.org The new list exists and should be used: http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/ On 11/18/11, Charles Pritchard ch...@jumis.com wrote: On 11/18/11 10:29 AM, Paul Kinlan wrote: On Fri, Nov 18, 2011 at 7:23 PM, Charles Pritchard ch...@jumis.com mailto:ch...@jumis.com wrote: On 11/18/11 1:40 AM, Paul Kinlan wrote: On Fri, Nov 18, 2011 at 2:15 AM, Greg Billock gbill...@google.com mailto:gbill...@google.com wrote: On Mon, Nov 14, 2011 at 7:24 PM, Charles Pritchard ch...@jumis.com mailto:ch...@jumis.com wrote: As far as I can tell, the model doesn't prohibit, nor does it encourage, the passing of MessageChannel. It's very much made for an RPC style of communication, but if the message being passed back is a channel, well that's just fine. Am I mistaken? What I'm seeing is that we get MessageChannel for free, and there's no need to specify further. Individual Intent authors can do that themselves. Yes. We envision RPC-style request/response as the sweet spot for intents. We've definitely considered use cases which are better served by opening a persistent On the subject of MessageChannels, my thoughts have been that you don't pass the data across it, as you would for say share image/*, but rather it is the initiation of a protocol - whose mime-type is yet to be determined; something like application/x-protocol-uucp My concern is the plumbing of Transferable. Sending Array Buffers across channels is great for short apps. Here's the webkit meta-bug as they work on postMessage semantics. https://bugs.webkit.org/show_bug.cgi?id=64629 It's a transfer intent. I'm transferring ownership of a buffer or a stream. It's still appropriate that mime types be specified. Many protocols have them. -Charles Sure, you can defiantly pass data across them, what I was referring to (if I understand your point) is that the MessageChannel is used for protocols that are more complex that the request/response that webintents has now. And to ensure that both client and service are talking the same protocol then the mime type is for the protocol and not the data going across it. Yes, I understand the reference. It's important that services are register themselves to appropriate mime types and intents. The intent field is a simple DOMString, and it's reasonably wide-open for use. Should we treat the mime type field in similar manner? Web messaging is so-easy to use, I'd expect a flood of micro-protocols. What's our plumbing to effectively work with the postMessage transfer semantic? It seems like transfer might be a special case intent. Everything else does a data copy. Transferring an array buffer means the current thread can no longer access that buffer. This is, approximately, what I'm thinking about: var intent = new Intent(http://webintents.org/transfer;, application/octet-stream+myprotocol, [messagePort, arrayBuffer]); The transfer intent signals that postMessage transfer semantics are going to be used. -Charles -- Sent from my mobile device
Re: WebTV Use Cases (was Re: [DRAFT] Web Intents Task Force Charter)
As sa note, that document is in violation of http://www.w3.org/Consortium/Translation/ The working language of the W3C is US English. The official version of a W3C document is the US English language version at the W3C site. So I fully expect it to change. On 11/14/11, Giuseppe Pascale giusep...@opera.com wrote: On Thu, 10 Nov 2011 17:01:51 +0100, Robin Berjon ro...@berjon.com wrote: Hi Rich, On Nov 10, 2011, at 16:27 , Rich Tibbett wrote: Opera would like to explore Local Device and Local Network Discovery as a subset of Web Intents. Yes, and that desire has been heard. As discussed last week, people interested in discovery need to bring their use cases to the intents TF so that we can figure out which just work, and for those that don't look at which of modifying intents or spawning a separate specification makes most sense. Let me add one thing on this point: if it wasn't clear from the joint F2F, the webtv IG have been discussing use cases for few months and collected them in a document that will be soon published as IG note. This document collects major use cases we are looking into. http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Requirements I'll send around the link to the final document once published, but note that NO changes are expected. /g -- Giuseppe Pascale TV Connected Devices Opera Software -- Sent from my mobile device
Re: [DRAFT] Web Intents Task Force Charter
Some of this really should wait until there's a list. I believe that generally one wants to adjust audio as close to the source as possible, in which case the TV doesn't know anything. Some parallels: A. If you have a cable box = vcr = tv in old serial fashion and use old fashion remotes, changing the audio w/ the cable box remote adjusts the audio sent by that box to the vcr, the tv's audio level isn't affected (but the cable box can insert an overlay indicating level and hide it after some interval). B. If you use digital audio out on your Mac to an external device, volume controls disappear from the mac (it expects you to use your stereo's mixer instead). - here if an intent user decides you're using a tv, it could choose to hide audio controls (deferring to the tv). Note that I consider this more of a bug than a feature, but... Anyway, to your underlying question: Android Intents and I believe some of the web Intents proposals have two forms: 1. Fire and forget (mailto:, outbound video/audio/document) 2. Establish bidirectional communications link Defining how to make #2 work should be in scope for the TF and Out Of Scope while defining its Charter. #2 is obviously more exciting for vendors trying to proxy to non web things, but IMO that's an implementation detail or potentially a supplemental Note/Specification. On 11/10/11, Marcos Caceres w...@marcosc.com wrote: -- Marcos Caceres On Thursday, November 10, 2011 at 7:56 PM, Rich Tibbett wrote: Marcos Caceres wrote: On Thursday, November 10, 2011 at 5:01 PM, Robin Berjon wrote: It's important to separate Intents as currently proposed and what we collectively want out of them. In order to move fast we probably don't want to pile up a zillion features there, but we equally certainly don't want this to turn into a rubber-stamping exercise. So bring the UCs on! - Hide quoted message - Perhaps someone could take the time to describe exactly how a user could communicate with an existing TV device in their home from a web browser supporting web intents based on the above requirements? We actually agreed that folks in the Discovery/Home Networking gang would do just that, to see if it flies. Also, a prototype might help here …. i.e., it's not up to the WG to explain how it does what you want, but up to you to show that it doesn't do something you want through a prototype (or similar) to do. If your prototype breaks down because the intents system doesn't work without extensions, then we have something to work from. Agree? Yes. I don't doubt this logic :) A use case I keep thinking about is: 1. I'm at Youtube.com, and I want to watch a video on my tv. 2. I tell youtube, hey, sent this to my TV. 3. Video starts playing on my TV. 4. I turn the audio up/down on the youtube video (or I scrub the timeline). How does that work? Is that all still done over HTTP and the intent (i.e., the audio control)? I guess it's like the intent is ongoing while some activity is happening (watching the video on my tv). I don't know if the current proposal supports such a thing or if it's more fire and forget. Anyway, just thinking out loud… guess we can pick this up in the new list. -- Sent from my mobile device
Re: [DRAFT] Web Intents Task Force Charter
That sounds like a different intent. And really UC gathering should be done on the TF list not here. But since people are ignoring that... Let's look at my Apartment as configured in Finland: A. Classic Speakers with copper input B. Desktop speakers with power, audio adjust using 3.5 input C. Digital mixer with optical, rca, other inputs, source selector and copper output D. DVD player w/ scart in+out, optical audio output E. Digital Cable w/ scart out, optical audio output F. PC with usb (tv converter in), mic in, line in; vga, 3.5 output G. G5 with usb, firewire, line in; two dvi outs, 3.5 and optical audio output (Hand waving about dvi/displayport) H. Cinema display with dvi in (carries audio) I. LCD TV with dvi in, scart in (carries audio) B1. Analog adjust C1. Analog adjust C2. Remote control D1. Remote control E1. Remote control F1. Usb Keyboard+mouse G1. Usb Keyboard+mouse I1. Buttons adjust E scart = D D scart = I E opt = C D opt = C G opt = C G 3.5 = B G dvi = H G dvi = I F vga = I F 3.5 = B This is a rough graph. Some things act as dumb pass-throughs (especially D in my graph). Let's take a simple case: 0. Imagine there was a UPnP/DLNA control path from my G to C. 1. Set the source input on C to E. 2. Set the source input on I to E. Now I have a picture and sound - for E. 3. As a bookmark, sample the sound level from A for source E. 4. Set the source input on C to D. 5. Set the source input on I to D. Now I have a picture and sound - for D. 6. As a bookmark, sample the sound level from A for source D. 7. Adjust the audio level of C using G. 8. As a bookmark, sample the sound level from A for source D. 9. Set the source input on C to E. 10. Set the source input on I to E. Now I have a picture and sound - for E. 11. As a bookmark, sample the sound level from A for source E. Did the act at step 7 change the values between steps 3 and 11? Using D1 or E1 would not affect the output at A of E/D respectively. If the adjustment by 7 is global, then the intent is like a bad remote C2 and thus should be an independent intent from an intent to play video D for which an acceptable behavior is a D1 remote. This doesn't remotely cover the problem space, but it's a start. Generally, a volume adjust on NetFlix shouldn't affect my next visit to YouTube. On 11/10/11, Clarke Stevens c.stev...@cablelabs.com wrote: Ah, but the difference here is that the web page actually does change the volume on the viewing device. That's the beauty of these home networking protocols. -Clarke On 11/10/11 2:53 PM, timeless timel...@gmail.com wrote: Some of this really should wait until there's a list. I believe that generally one wants to adjust audio as close to the source as possible, in which case the TV doesn't know anything. Some parallels: A. If you have a cable box = vcr = tv in old serial fashion and use old fashion remotes, changing the audio w/ the cable box remote adjusts the audio sent by that box to the vcr, the tv's audio level isn't affected (but the cable box can insert an overlay indicating level and hide it after some interval). B. If you use digital audio out on your Mac to an external device, volume controls disappear from the mac (it expects you to use your stereo's mixer instead). - here if an intent user decides you're using a tv, it could choose to hide audio controls (deferring to the tv). Note that I consider this more of a bug than a feature, but... -- Sent from my mobile device
Re: Draft Minutes: 31 October 2011 f2f meeting
There are a couple of instances where the scribe.pl script broke and s///'s appear. Also because of that, there are a number of times when 'scribe:' appears as a speaker, with the former resolved, most of these should disappear. Lastly, due to autocompletion, there's a third scribe listed (JonathanJ), please redact as it was an error -- sorry.
Re: Re: CfC: new WD of Clipboard API and Events; deadline April 5
We've seen people who abused hidden style to smuggle evil shell commands into seemingly innocuous shell instructions. When pasting text into a word processor, one generally gets a functional preview of the results. When pasting into a shell, things are typically executed immediately sans preview. Now, there are solutions, kinda. Instead of copying directly to the clipboard, you can provide a number of flavors on the clipboard, with the default being WYSIWYG and another being what the tool offered. Office apps and web browsers could let users select the alternate flavor. Simple apps should get the WYSIWYG flavor. We only recently fixed the css hidden clipboard bugs. On 9/5/11, Glenn Maynard gl...@zewt.org wrote: On Mon, Sep 5, 2011 at 11:41 AM, Paul Libbrecht p...@hoplahup.net wrote: Slowly, users start to see the disadvantages of a dirty web-page (e.g. flash advertisement 100% cpu) and I am confident they will not that some pages mingle with their copy ability or actually provide a service to do so. Sorry, I'm having trouble parsing this. My experience so far is that people are aggravated by pages that insert ads into copied text, but not quite enough to stop them from using a page. They grumble and delete the ad. That's the most annoying category of abuse, in my opinion: not bad enough to strongly discourage its use, causing it to spread, but bad enough to continuously annoy users. I'd love to hear your feedback but that's how I feel things and I think we just have to accept it: new technology, new risks, positive and negative. It's acceptable for new technologies to have negatives, of course; the positives need to balance the negatives. To be clear, I don't mean that this abuse is newly exposed by this API. It's an abuse that's been spreading lately, using hacks with existing APIs. I meant that it shows that people will broadly abuse anything that lets them fiddle with the clipboard; in other words, this isn't a theoretical problem. I'd hoped to see browsers adjust behavior so clipboard copying happens before anything else (before firing DOM events at all), making it more difficult for pages to fiddle with the selection before the copy occurs, but this API makes that approach useless; it officially blesses the entire category of messing-with-what-the-user-copies, so it'd never be fixable. That's frustrating. (As an aside, it would still be possible to do this sort of clipboard hijacking even if that was done, by fiddling with the selection when the selection change happens instead of waiting for the copy. From my experiments, though, that approach is much more brittle, which is a deterrent in and of itself.) We can't stop pages from being annoying, but we should definitely keep in mind the annoying things that are actually being done in the wild today, and be aware of the things a new API might exacerbate. -- Glenn Maynard -- Sent from my mobile device
Re: CfC: publish Last Call Working Draft of Web IDL; deadline July 7
On Sat, Jul 9, 2011 at 7:23 AM, Arthur Barstow art.bars...@nokia.com wrote: Although there are ongoing discussions regarding exceptions, there were no objections to this CfC. As such, I will request publication of a LC specification to encourage broader review and comments. Sorry, I'm in the midst of sending comments on WebIDL. I should be done by Tuesday...
Re: Mutation events replacement
On Thu, Jul 7, 2011 at 6:21 PM, John J Barton johnjbar...@johnjbarton.com wrote: 1. Graphical breakpoints. The user marks some DOM element or attribute to trigger break. The debugger inserts mutation listeners to watch for the event that causes that element/attribute to be created/modified. Then the debugger re-executes some code sequence and halts when the appropriate listener is entered. Placing the listeners high in the tree and analyzing all of the events is easier than trying to precisely add a listener since the tree will be modified during re-execution. 2. Graphical tracing. Recording all or part of the DOM creation. For visualization or analysis tools. See for example Firebug's HTML panel with options Highlight Changes, Expand Changes, or Scroll Changes into View. 3. Client side dynamic translation. Intercept mutations and replace or extend them. This could be for user tools like scriptish or stylish, dev tools to inject marks or code, or for re-engineering complex sites for newer browser features. Most if not all of your use cases can be done by hooking the functions you're worried about at the engine level. You can do any of the following: 1. replace functions on object prototypes 2. instrument the js code before it executes 3. single step the js code and then instrument it as it executes You could also just wait for this to be implemented and arrange for a *private* non DOM API which would allow you to get hooks which do things like any of the above. Note that JSD historically has had a before method call callback. And iirc someone was supposed to provide it again for the cases where the JIT broke this. A before method call callback easily enables you to check its name against a table and decide that you need to store values, there's also a paired after callback, during which you can do the rest of your work. If these don't work, you can file a bug against the API and hopefully someone will work on it. -- sadly, that won't be me.
Re: Mouse Lock
I recently saw what appeared to be the AG group complaining that the html WG didn't care to specify Accessibility bits even though W3 policy requires considering both internationalization and accessibility. I know that we like to innovate and let everyone else backfill the missing pieces later, but perhaps that isn't a wonderful approach. On the topic of devices without keyboards, I picked up a MeeGo 1.2 tablet in May. It has no keyboard, and no useful edges. It doesn't have a right click feature, and it's perfectly reasonable for a web application to demand to detect gestures and long presses. It has one real button: Power - which turns the device completely off, after which it takes an incredibly long time to boot. Not to mention that a user might not appreciate losing any other unsaved data. It does have rotation detection (which barely works), again, something which web applications are free to want to handle themselves. It also has single sensor which is incredibly quirky and easy to misplace or overlook which barely functions for task switching. You could claim that it's sufficient as a way out, but it makes me uncomfortable. Plus there's no way for a UI to explain to the user how to press it; it isn't usefully labeled. On 6/23/11, Charles Pritchard ch...@jumis.com wrote: timeless, I agree, it'd be nice to know. I'd really like to see this put toward the AG (Accessibility Guidelines) people, as they're the ones who follow this kind of things. It's absolutely the case that a user needs an ability to escape from the mouse lock context, and to have one which lies outside of any processing handled by the untrusted scripting environment. The *AG practices are always the first to document these needs. Requiring keyboard for something that locks a mouse is not acceptable; a user must be able to release their pointer device without requiring a keyboard. The same applies for keyboard locks. Assistive technologies (AT) have their place in this, and can give some leeway to the user agent (UA), as long as the UA provides enough semantics to allow the AT to handle this kind of work. Again, these issues are always brought up by AG documents. I'll give you two examples for pointer device escape: 1) Right click/context menu; always works. 2) Click and hold; X number of seconds could pop up a context menu. 3) extreme coordinate and hold; x seconds on an extreme coordinate pops up a menu. On the extreme-coordinate; an input device which may only signal changes in x/y positioning may still be used to activate UA menus. Developers are by all practical purposes, required by existing standards and technologies, to leave space on the edges of the screen. Though this is mostly related to safe areas on televisions, the principle applies beyond that, and is de facto required by existing full screen semantics [wherein the top extremes create a dialog to escape]. So, by luck of history; extreme coordinates are encouraged and in practice, required as a means of escaping mouse lock. There are certainly cases where extreme coordinates could be useful to an application. Those corner cases will have to be thought about, by those implementing such apps. All the best, -Charles On 6/23/2011 6:29 PM, timeless wrote: And what if the device in question is just a touchscreen with no keyboard, mouse or hardware buttons? On 6/20/11, Tab Atkins Jr.jackalm...@gmail.com wrote: On Mon, Jun 20, 2011 at 3:03 PM, Olli Pettayolli.pet...@helsinki.fi wrote: On 06/21/2011 12:25 AM, Tab Atkins Jr. wrote: The use-case is non-fullscreen games and similar, where you'd prefer to lock the mouse as soon as the user clicks into the game. Minecraft is the first example that pops into my head that works like this - it's windowed, and mouselocks you as soon as you click at it. And how would user unlock when some evil sites locks the mouse? Could you give some concrete example about It's probably also useful to instruct the user how to release the lock. I'm assuming that the browser reserves some logical key (like Esc) for releasing things like this, and communicates this in the overlay message. -- Sent from my mobile device
Re: Mouse Lock
And what if the device in question is just a touchscreen with no keyboard, mouse or hardware buttons? On 6/20/11, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Jun 20, 2011 at 3:03 PM, Olli Pettay olli.pet...@helsinki.fi wrote: On 06/21/2011 12:25 AM, Tab Atkins Jr. wrote: The use-case is non-fullscreen games and similar, where you'd prefer to lock the mouse as soon as the user clicks into the game. Minecraft is the first example that pops into my head that works like this - it's windowed, and mouselocks you as soon as you click at it. And how would user unlock when some evil sites locks the mouse? Could you give some concrete example about It's probably also useful to instruct the user how to release the lock. I'm assuming that the browser reserves some logical key (like Esc) for releasing things like this, and communicates this in the overlay message. ~TJ -- Sent from my mobile device
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
Cheers! On 6/23/11, Mark Pilgrim pilg...@google.com wrote: On Sun, Jun 19, 2011 at 2:35 AM, Adam Barth w...@adambarth.com wrote: On Mon, Jun 13, 2011 at 9:40 AM, Adam Barth w...@adambarth.com wrote: On Mon, Jun 13, 2011 at 1:31 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Jun 13, 2011 at 12:15 AM, Adam Barth w...@adambarth.com wrote: On Sun, Jun 12, 2011 at 11:19 PM, Jonas Sicking jo...@sicking.cc wrote: On Sun, Jun 12, 2011 at 8:35 PM, Cameron McCormack c...@mcc.id.au wrote: Adam Barth: WebKit is looser in this regard. We probably should change the default for new IDL, but it's a delicate task and I've been busy. :( What about for old IDL? Do you feel that you can make this change without breaking sites? One of the “advantages” of specifying the looser approach is that it’s further down the “race to the bottom” hill, so if we are going to tend towards it eventually we may as well jump there now. I can't remember getting a single bug filed on Geckos current behavior. There probably have been some which I've missed, but it's not a big enough problem that it's ever been discussed at mozilla as far as I can remember. Unfortunately, there's a bunch of WebKit-dominate content out there that folks are afraid to break. We discussed this topic on some bug (which I might be able to dig up). The consensus was that the value in tightening this for old APIs wasn't worth the compat risk (e.g., in mobile and in Mac applications such as Dashboard and Mail.app). For new APIs, of course, we can do the tighter things (which I agree is more aesthetic). It mostly requires someone to go into the code generator and make it the default (and then to special-case all the existing APIs). I'd like to do that, but it's a big job that needs to be done carefully and I've got other higher priority things to do, so it hasn't happened yet. If there is agreement that new APIs should throw for omitted non-optional parameters, then it seems clear that WebIDL should use that behavior. That leaves the work for safari (and possibly other webkit devs) to go through and mark parameters as [optional] in their IDL. Possibly also filing bugs for cases where you want the relevant spec to actually make the argument optional. I realize that this is a large amount of work, but this is exactly what we have asked in particular of microsoft in the past which has been in a similar situation of large divergence from the DOM specs, and large bodies of existing content which potentially can depend on IE specific behavior. Think folks are agreed that's the path we should follow. My only concern is that we don't have anyone signed up to do the work on the WebKit side. Just to update this thread, Mark Pilgrim has stepped forward to get the ball rolling on this work, so WebKit is making progress on this front. I'm happy to report that WebKit's implementation of IndexedDB now follows WebIDL and throws TypeError on all functions when called with missing required arguments. We have grandfathered in all existing IDL files to use the old, looser code generator, but we are actively working on migrating *all* 521 IDL files to use the new, stricter generator (with [Optional] flags in places where we can't break compatibility). IndexedDB is the first success in this process; as an experimental API, we feel no need to maintain compatibility and have opted for the stricter semantics everywhere, matching the WebIDL and IndexedDB specs exactly. Next will be other experimental APIs like the web audio API and the File API, where we hope to have similar levels of success. -Mark -- Sent from my mobile device
Re: [Bug 12965] New: Problem: I want to perform DNS queries from a HTML5 app, but the networking functions available are too restrictive to build a stub resolver. Why: DNS is not just for machines -
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12965 Summary: Problem: I want to perform DNS queries from a HTML5 app, but the networking functions available are too restrictive to build a stub resolver. Why: DNS is not just for machines - zones may contain extremely useful Comment: Problem: I want to perform DNS queries from a HTML5 app, but the networking functions available are too restrictive to build a stub resolver. Why: DNS is not just for machines - zones may contain extremely useful and rich information for humans too, e.g. the .tel TLD was provisioned specifically to publish contact information (i.e. URIs) as DNS records (i.e. NAPTR, TXT, LOC), there's also e164.arpa, and perhaps further innovation will happen at the DNS layer in the future. Solution: Define a DNS interface. Some computers live behind proxies which do not provide for client based dns lookups. instead a client tells the proxy i would like to talk to host or i would like to get url and the proxy says here's a connection for host or here's the data for url. An API for doing DNS work will not work in such situations. What you will probably have is something that usually works but fails on any interesting corporate network, which is unfortunate. This is the general reason that DNS APIs aren't exposed. The other reason is that DNS can easily include private information and browsers aren't particularly good at understanding what is private and shouldn't be exposed to web apps. I just finished reading https://bugzilla.mozilla.org/show_bug.cgi?id=354493 the bug report is 5 years old and unfinished, the problem is much older. Once fixed, I'm pretty sure it still won't handle the proxy cases. We really aren't in a position to add more attack surfaces until browser vendors manage to clean up the current surfaces (especially including that bug).
Re: [indexeddb] Using WebIDL Dictionary in IDBObjectStore.createIndex for optionalParameters
On Mon, Jun 13, 2011 at 4:00 PM, Israel Hilerio isra...@microsoft.com wrote: Is this what you were thinking? yes
Re: [indexeddb] Using WebIDL Dictionary in IDBObjectStore.createIndex for optionalParameters
On Tue, Jun 7, 2011 at 5:03 PM, Jonas Sicking jo...@sicking.cc wrote:
For example, say that we in version 2 of indexedDB add support for
foreign keys. So that you can say:
createObjectStore(car, { keyPath: id, foreignKeys: [{keyPath:
brand, objectStore: car-brands}]);
It seems bad that if a user thinking they are using a indexedDB
implementation which supports version 2 calls this function and expect
the foreignKey constraint enforced, but in reality they're calling it
on a v1 implementation which silently ignores it.
would having a field: mandatory which indicates which arguments (or
feature names) must be supported by the implementation assuage your
concern?
createObjectStore(car, { mandatory: [foreignKeys], keyPath: id,
foreignKeys: [{keyPath: brand, objectStore: car-brands}]);
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On Tue, May 17, 2011 at 7:23 AM, Hallvord R. M. Steen hallv...@opera.com wrote: to/from native clipboard types? Just off the top of your head? The typical Web MIME types would of course be something along the lines of text/plain text/html image/jpg image/gif image/png application/xhtml+xml image/svg+xml i'd suggest ATOM [application/atom+xml] as a type to support. Browsers generally support it. This is somewhat to the exclusion of RDF and RSS. This provides a way to serve listings and enclosures and things Should application/octet-stream be supported for cases when authors want to pass along binary data?
Re: [File API: FileSystem] Path restrictions and case-sensitivity
On Thu, May 12, 2011 at 3:02 AM, Eric U er...@google.com wrote: There are a few things going on here: yes 1) Does the filesystem preserve case? If it's case-sensitive, then yes. If it's case-insensitive, then maybe. 2) Is it case-sensitive? If not, you have to decide how to do case folding, and that's locale-specific. As I understand it, Unicode case-folding isn't locale specific, except when you choose to use the Turkish rules, which is exactly the problem we're talking about. 3) If you're case folding, are you going to go with a single locale everywhere, or are you going to use the locale of the user? 4) [I think this is what you're talking about w.r.t. not allowing both dotted and dotless i]: Should we attempt to detect filenames that are /too similar/ for some definition of /too similar/, ostensibly to avoid confusing the user. As I read what you wrote, you wanted: 1) yes correct 2) no correct 3) a new locale in which I, ı, I and i all fold to the same letter, everywhere I'm pretty sure Unicode's locale insensitive behavior is precisely what i want. I've included the section from Unicode 6 at the end. 4) yes, possibly only for the case of I, ı, I and i 4 is, in the general case, impossible. yes. It's not well-defined, and is just as likely to cause problems as solve them. There are some defined ways to solve them (accepting that perfect is the enemy of the good), - one is to take the definitions of too similar selected for idn registration... - another is to just accept the recommendation from unicode 6 text can be normalized to Normalization Form NFKC or NFKD after case folding If you *just* want to check for ı vs. i, it's possible, but it's still not clear to me that what you're doing will be the correct behavior in Turkish locales [are there any Turkish words, names abbreviations, etc. that only differ in that character?] Well, the classic example of this is sıkısınca / sikisince [1], but technically those differ in more than just the 'i' (they differ in the a/e at the end). My point is that if two things differ by such a small thing, it's better to force them to have visibly different names, this could be a '(2)' tacked onto the end of a file if the name is auto generated, or if the name is something a human is picking, it could be please pick another name, it looks too close to preview of other object object name. The other instances I've run into all seem to be cases where there's a canonical spelling and then a folded for Latin users writing. I certainly can't speak for all cases. and it doesn't matter elsewhere. Actually, i think we ended up trying to compile blacklists while developing punycode [2] for IDN [3]. I guess rfc 4290 [4], 4713 [5], 5564 [6], and 5992 [7], have tables which while not complete are certainly referencable, and given that UAs already have to deal with punycode, it's likely that they'd have access to those tables. I think the relevant section from unicode 6 [8] is probably 5.18 Case Mappings (page 171?) Where case distinctions are not important, other distinctions between Unicode characters (in particular, compatibility distinctions) are generally ignored as well. In such circumstances, text can be normalized to Normalization Form NFKC or NFKD after case folding, thereby producing a normalized form that erases both compatibility distinctions and case distinctions. I think this is probably what I want However, such normalization should generally be done only on a restricted repertoire, such as identifiers (alphanumerics). Yes, I'm hand waving at this requirement - filenames are in a way identifiers, you aren't supposed to encode an essay in a filename. See Unicode Standard Annex #15, “Unicode Normalization Forms,” and Unicode Standard Annex #31, “Unicode Identifier and Pattern Syntax,” for more information. For a summary, see “Equivalent Sequences” in Section 2.2, Unicode Design Principles. Caseless matching is only an approximation of the language-specific rules governing the strength of comparisons. Language-specific case matching can be derived from the collation data for the language, where only the first- and second-level differences are used. For more information, see Unicode Technical Standard #10, “Unicode Collation Algorithm.” Of note: In most environments, such as in file systems, text is not and cannot be tagged with language information. In such cases, the language-specific mappings must not be used. Otherwise, data structures such as B-trees might be built based on one set of case foldings and used based on a different set of case foldings. This discrepancy would cause those data structures to become corrupt. Of note: For such environments, a constant, language-independent, default case folding is required. On the subject of file names and encodings, I can't recall if you specified normalization equivalence. From memory OS X and Windows disagree on
Re: [widgets] WARP usability issue
2011/5/12 Scott Wilson scott.bradley.wil...@gmail.com: I'd be tempted to just strip off any trailing slashes on import. Actually I might do that for all path components in a WARP origin rather than throw an error. So. I was hoping it could be fixed by Stores when they import, but of course the signature would be voided if they did that. Since this is something which is part of the manifest and can be easily identified and reported, I think the right thing to do is for the Stores to reject uploads with a useful error and for the UAs to reject widgets with a useful error. It should be very easy to detect this error and very easy to write a good error message with a correction. And it should be possible to even spit out a diff or replacement file which people can use. So this should really be solved by tools.
Re: SpellCheck API?
2011/5/11 Aryeh Gregor simetrical+...@gmail.com:
Here's an alternative suggestion that addresses the issues I had
above, while (I think) still addressing all your use-cases. Create a
new interface:
interface SpellcheckRange {
readonly unsigned long start;
readonly unsigned long length;
readonly DOMStringList suggestions;
readonly unsigned short options = 0;
const unsigned short NO_ERROR = 1;
const unsigned short ADD_SUGGESTIONS = 2;
}
length could be end instead, whichever is more consistent.
options is a bitfield. NO_ERROR means that there is no error in this
range, and the UA should not mark any words there as being errors even
if the spellcheck attribute is enabled. (If the author wants to
completely disable built-in suggestions, they can set
spellcheck=false.) ADD_SUGGESTIONS means that the provided
suggestions should be given in addition to the UA's suggestions,
instead of replacing them -- by default, the UA's suggestions for that
range are replaced. (The default could be the other way around if
that's better.) These two features allow the author to control
default UA suggestions without being able to know what they are, so
there's no privacy violation.
With this model, i'd want the UA to provide instances for words which
are misspelled according to its standard dictionary but which are in
its user's custom dictionary. The web page can try to make
suggestions, but generally the UA will choose to ignore the words
because it knows that the user is happy with the current word.
Re: [File API: FileSystem] Path restrictions and case-sensitivity
On Thu, May 12, 2011 at 2:08 AM, Eric U er...@google.com wrote: Timeless replied: no, if the api is case insensitive, then it's case insensitive *everywhere*, both on Turkish and on English systems. Things could only be case sensitive when serialized to a real file system outside of the API. I'm not proposing a case insensitive system which is locale aware, i'm proposing one which always folds. You're proposing not just a case-insensitive system, but one that forces e.g. an English locale on all users, even those in a Turkish locale. I don't think that's an acceptable solution. No, I proposed case preserving. If the file is first created with a dotless i, that hint is preserved and a user agent could and should retain this (e.g. for when it serializes to a real file system). I'm just suggesting not allowing an application to ask for distinct dotted and dotless instances of the same approximate file name. There's a reasonable chance that case collisions will be disastrous when serialized, thus it's better to prevent case collisions when an application tries to create the file - the application can accept a suggested filename or generate a new one.
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: [File API: FileSystem] Path restrictions and case-sensitivity
On Sun, May 8, 2011 at 5:44 AM, Glenn Maynard gl...@zewt.org wrote: If *this API's* concept of filenames is case-insensitive, then IMAGE.JPG and image.jpg represent the same file on English systems and two different files on Turkish systems, which is an interop problem. no, if the api is case insensitive, then it's case insensitive *everywhere*, both on Turkish and on English systems. Things could only be case sensitive when serialized to a real file system outside of the API. I'm not proposing a case insensitive system which is locale aware, i'm proposing one which always folds. If you create IMAGE.JPG (dotless-I) in one part of your code and then refer to it elsewhere as image.jpg (dotted-i), it *does* work on an average (non-Turkish) system if filenames are case-insensitive. Only when someone tries to use this same code on a Turkish system will it fail, where I and i are different characters. No, the code would work on any conforming user agent. If someone were to *serialize* to an actual file system outside of the useragent, then things would be different, and again, that's where the serializer would need to deal with it. And it would need to deal with it anyway because not all paths will be valid or viable on the local file system (file names may be too long or have reserved characters), so any html (or similar content) would need to be modified by the serializer.
Re: [File API: FileSystem] Path restrictions and case-sensitivity
On Sun, May 8, 2011 at 11:04 PM, Charles Pritchard ch...@jumis.com wrote: The one take-away I have from that bug: it would have been nice to have a more descriptive error message. It took awhile to figure out that the path length was too long for the implementation. if the exception included a suggested legal / available filename, would that have helped? e.g. if i try to create a file whose name is 2345 characters long, and my exception suggests a file that's 255 characters long (probably via truncation, although possibly using some tilde stuff or whatever), i suspect i might be able to figure out that it's a 256 character limit. Similarly if i try to create a file w/ a : in it, and i get an exception with a file that doesn't have one, i might be able to understand what's going wrong and what to do.
Re: [File API: FileSystem] Path restrictions and case-sensitivity
On Fri, May 6, 2011 at 8:22 PM, Glenn Maynard gl...@zewt.org wrote: This can be solved at the application layer in applications that want it, without baking it into the filesystem API. I wasn't talking about baking it into the api, i meant that the application using it could write such code. I don't know what you're talking about. We're not talking about serializing to FAT, we're talking about case-sensitivity within virtualized filenames. you raised an issue involving if something were serialized, and i noted that the serialized case is already unhappy with eric's proposal. Again, if filenames are case-insensitive, then the API will work differently on a Turkish system than other systems, as I described, in a way that's guaranteed to cause interop failures. This point stands. someone generating the content is likely to generate the file name references directly too (as i noted), as such it's unlikely that problems will happen. case 1: file is 'dotless-i', file reference is 'dotted-i', the generated content does *not* work on your *average* system. someone notices relatively quickly. case 2: file is 'dotted-i', file reference is 'dotless-i', the generated content does *not* work on your *average* system. someone notices relatively quickly. case 3: file is 'dotted-i', file reference is 'dotted-i', the generated content should work everywhere. case 4: file is 'dotless-i', file reference is 'dotless-i', the generated content will work or not depending on the user agent's ability to safely serialize the content (file and referencing file) to the host platform. this case is no different than with any other rule set.
Re: [File API: FileSystem] Path restrictions and case-sensitivity
On Thu, May 5, 2011 at 3:16 PM, Glenn Maynard gl...@zewt.org wrote: On Thu, May 5, 2011 at 3:43 AM, timeless timel...@gmail.com wrote: My argument is that we should favor: 'case preserving' + 'case folding' + 'case insensitivity'. The virtual file system is going to be something which is mostly controlled by the web app, so there should be minimal harm in telling it that there's already a file with a given name -- it can load the file, review its contents, and try to decide that it should suggest the user use a more distinct name. You're thinking of this only in terms of one narrow, and in my opinion minor, use case: letting the user click save and enter a filename. I'm not actually very interested in that case. (It's minor because a user saving a file usually doesn't want to do so to a virtualized, sandboxed filesystem that he can't access directly. That's the non-sandboxed use case; we're talking about the sandboxed case here.) Much more important is bulk saving data, such as saving large amounts of downloaded data for a game. Consider the case where a user is trying to build a web site, where they might have resources which are accessible via another resource (e.g. a web page). I'd much rather that we not make it easy for users to have Hi, hi, Hï, Hı as distinct files, I don't think they're well served by doing this. If someone gets a collision then something should automatically pick or ask for a different name, this might in rare cases be the user, but on average it'll just be the code itself picking something like hi_1, which will be fine. The proposal is case preserving, so if the file starts as Hı, that's how it'd be returned via any enumeration or shown to the user. It just means that if someone tries to stick an English Hi file into the same place they'll be told to pick a new name. I do not think that short names with colliding cases are better than forcing something (probably a program) to pick better (yes, longer) names which do not collide. Yes, I'm asking to impose a constraint, it means that a game developer can't be annoying and use each of Hi, hi, Hï, and Hı as distinct file names. It's a design constraint, I do not think that a game developer will suffer because of this constraint. And before people complain that I've never had a use for dotless i and can't have sympathy for people who do I've been to İstanbul and have entire photo albums for it (including Topkapı Palace). I also used to work for Nokia (Nokia's history involves a phone which didn't support dotless i's, the result was a miscommunication and at least one stabbing). If file names are going to be generated programmatically, then a constraint that says case preserving, case folding, case insensitive should not be a significant hazard for anyone. It's a serious problem if this isn't interoperable. If filenames are case-insensitive and honor the locale, then people are going to save files as IMAGE.JPG and access them as image.jpg, and it'll work everywhere except on Turkish systems. This point has no merit. Eric's proposal says let's support things which won't work on FAT anyway. As such, anything which tries to serialize to fat and have the resulting content work would have to apply a filter -- just as save as web page complete munges things today.
Re: [IndexedDB] Closing on bug 9903 (collations)
On Fri, May 6, 2011 at 2:32 AM, Jonas Sicking jo...@sicking.cc wrote: I'm not worried about crashes or security issues, but I am worried about performance. Not only is it the overhead of crossing from C++ into JS, but also the fact that the C++ code has to go through extra pains to ensure that the world around it still makes sense by the time you come back from the JS callback. For example the callback could have deleted all IndexedDB databases and navigated to a new page. So every time you get back from JS you have to spend a bunch of time rechecking all the state that you were holding in your function implementation. I think that a stored procedure could be considered as a compiled version of a serialized function. i.e. something which loses its scope chain, and which loses access to its parent object. If it loses access to its scope chain which includes the interesting globals, it will no longer have access to fun things like DOM objects, roughly like DOMWorkers but with even less exciting objects available. I'd hope that a jit should be able to do a fairly reasonable job of optimizing such a function given these constraints. The resulting keys could be stored with the database, so you don't have to recalculate them while sorting, only during insertion or if the sort key function is changed. All of this is totally doable. It's not even particularly hard. But it costs performance.
Re: [File API: FileSystem] Path restrictions and case-sensitivity
On Wed, May 4, 2011 at 3:58 AM, Eric U er...@google.com wrote: Regarding case sensitivity: I originally specced it as case-insensitive-case-preserving to make it easier to support a passthrough implementation on Windows and Mac. However, as passthroughs have turned out to be unfeasible [see previous thread on path length problems], all case insensitivity really gets us is potential locale issues. I suggest we drop it and just go with a case-sensitive filesystem. I'm somewhat worried about the case where two files have nearly the same name and the user gets confused. It's bad enough that one of my phones doesn't show file extensions and its text editor generates files that are either HTML or Plain (actually, i can't remember the actual file extensions, but the point its it generates rich text and plain text - and can promote/demote). So I generally have a file notes and a file notes and I can't tell them apart and I can't remember which one I want (the edit date is often the same for both and one has the content I want and one is the accidental version from before I switched file formats). While case folding is expensive and painful, do we have any use cases for allowing similarly named files beyond enabling the user to conflate them? Consider the following two items: gооgle.com google.com - try loading them in a web browser -- oddly my web browser tells me that the second one is misspelled :) My argument is that we should favor: 'case preserving' + 'case folding' + 'case insensitivity'. The virtual file system is going to be something which is mostly controlled by the web app, so there should be minimal harm in telling it that there's already a file with a given name -- it can load the file, review its contents, and try to decide that it should suggest the user use a more distinct name. As we're proposing file names that are longer than most users are likely to use by default, we can include datestamps (timeless unless collisions happen) to disambiguate user generated collisions via a browser side import -- if such a feature is provided at all).
Re: [widgets] Dig Sig spec
It's pretty much impossible for me to figure out which things are new or which i've missed in previous rounds. (It's also possible that I didn't review this spec, in which case, I'm sorry.) I don't believe these comments significantly affect the document, i.e. they're mostly editorial, although some are technically errors which should definitely be fixed. http://dev.w3.org/2006/waf/widgets-digsig/ A widget package can be digitally signed by an author to produce a signature file that cryptographically includes all of the files of a widget package that are not i don't think includes is right, perhaps covers or attests. signature files (e.g., HTML files, CSS files, and JavaScript files). A user agent or other entity can use author signature to determine: use _an_ author As the following terms are used throughout this specification, they are gathered here for the readers convenience. reader's A file name is the name of a file contained in a widget package (excludes path information), as defined in the [Widgets Packaging] specification. probably s/excludes/excluding/ Set the a URI attribute for each ds:Reference to be the zip relative path that identifies a file inside the widget package. drop a Generate a identifier property in the manner specified in [Signature Properties]. an Serialized the signature as a [UTF-8] encoded [XML] document using the appropriate naming convention depending on its role: Serialize ? (present tense, action/command v. past tense) To validate the siganture files of a widget package, a validator MUST run the algorithm to validate digital signatures. signature is misspelled terminate this algorithm and treat as an unsigned widget package: treat _it_ as... Check that signature has a ds:Reference for every file that is not a signature file. If every non-signature file is not included, then signature is in error. s/every/any/ s/not included/not listed/ If the role property is missing or or invalid, then signature is in error. s/or or/or/ If all signatures validated successfully, treat this as a signed widget package. s/validated/validate/ Search the root of the widget package for any file name that case-sesitively sensitively is misspelled This implies that, in order to verify a signature file, a user agent need needs A signature .. does not limit .. decompression and unpacking code used during signature extraction and verification. This doesn't seem to be a complete thought. A signature file can also be renamed, which can affect the order in which distributor signatures are processed. This could have been addressed by embedding the signature file name into the file, oh well :) Mechanisms to install new root certificates in a user agent need to be subject to security critical mechanisms. 'security critical mechanisms' doesn't sound right
Re: [widgets] Proposal to update Dig Sig spec; deadline May 3
On Tue, Apr 26, 2011 at 8:50 AM, Arthur Barstow art.bars...@nokia.com wrote: Widget People - if you have any objections/concerns re Marcos' proposal below, please respond by May 3 at the latest. (For some additional context, the start of the thread is [1]). Marcos - if no major objections/concerns are raised by this deadline, please proceed as you propose below. i'm fine with it, but would like a direct cc to timel...@gmail.com, i'll try to read it promptly but can't make any guarantees.
Re: publish new Working Draft of Indexed Database API; deadline April 16
On Tue, Apr 19, 2011 at 6:41 PM, Eliot Graff eliot.gr...@microsoft.com wrote: Thanks for the feedback. Moving forward, I will track changes and resolution of these suggestions in bug 9379 [1]. ok Appreciate the time you've spent on this. here's next next part, note that i drafted it a while ago and am just sending it to flush my mailbox. http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html part two... The transaction mode determines both which operations are allowed to be performed during the transaction, as well whether two transactions can run concurrently or not. The transaction mode controls whether or not multiple transactions can run currently and which operations may be performed during the transaction. Which operations are allowed be be performed are The allowed operations are defined in detail below, but in general transactions opened in READ_ONLY mode are only allowed to perform reading operations which does not change data. s/reading // s/does/do/ -- this defines read, and operations are plural.. if you really want to define it perhaps stick some quotes around reading? READ_WRITE transactions are allowed to perform reading and writing transactions to existing object stores, s/perform reading and writing/read from and write/ where as VERSION_CHANGE transactions are allowed to perform any operations, including ones that delete and create object stores and indexes. As long as the VERSION_CHANGE transaction, the implementation s/transaction/transaction is pending/ ? MUST wait with starting any other transactions against the same s/with/before/ database until the VERSION_CHANGE transaction is finished. There are a number of ways that an implementation ensure this. s/ensure/ensures/ It can prevent READ_WRITE transactions whose scope overlap s/prevent/stall/ ? (you don't prevent them from ever existing, you at best prevent them from starting which seems more like stalling or delaying) s/overlap/overlaps/ the scope of the READ_ONLY transaction from starting until the READ_ONLY transaction is finished. s/is finished/finishes/ Or it can allow the READ_ONLY transaction to see a snapshot of the contents of the object stores which is taken when the READ_ONLY transaction is started. s/is // Similarly, implementations MUST ensure that a READ_WRITE transaction is only affected by changes to object stores that are made using the transaction itself. I.e. the implementation MUST ensure that another transaction does not modify the contents of object stores in the READ_WRITE transactions scope. I don't think starting a sentence with i.e. is a good idea... s/transactions/transaction's/ The implementation MUST also ensure that if the READ_WRITE transaction completes successfully, that the changes written to object stores using the s/, that / / transaction can be committed to the database without merge conflicts. i find can be here problematic, i know it's only meaningful with the next sentence, but i don't think it works well. An implementation MUST NOT abort a transaction due to merge conflicts. An implementation MUST NOT start any transaction until all other READ_WRITE transactions with overlapping scope have completed. doesn't this prevent merge conflicts? When multiple transactions are eligible to be started, older transactions should be started first. should 'should' be written as an RFC word? User agents MUST ensure a reasonable level of fairness across transactions to prevent starvation. For example if multiple READ_ONLY transaction are started one after another the implementation MUST ensure that that doesn't indefinitely prevent a pending READ_WRITE transaction from starting. This MUST doesn't seem testable, and sticking a MUST into an example seems wrong. Transaction objects implement Each transaction object will implement either the IDBTransaction or the IDBTransactionSync interfaces. interface. -- this is a style change and applies to other objects in this document. I'm assuming that an object only ever implements one of the two interfaces and thus interface should be singular and you should spell out that it's exclusive. If it isn't, I'd like to know how/why. Every request also has a result and an errorCode, neither of which are accessible until the done flag is set to true. does 'are accessible' mean will throw an exception if poked? Finally, requests have a request transaction. When a request is created, it is always placed against a transaction using either the steps to a asynchronously execute a request or the steps to a synchronously execute a request. It would be really helpful if things like steps to whatever were links This sets the request transaction to be that request. s/This sets/Those steps set/ The only exceptions to this are the request returned from a IDBFactory.open call and the request returned from a IDBDatabase.setVersion call, which create requests
Re: publish new Working Draft of Indexed Database API; deadline April 16
On Sat, Apr 9, 2011 at 2:22 PM, Arthur Barstow art.bars...@nokia.com wrote: http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html I expect this message to only have editorial comments. However, I'm not fond of April 16th, this month is tax month and I still need to file. Transaction A transaction is used to interact with the data in a database. Whenever data is read or written to the database this is done using a transaction. maybe s/this/it/ All transactions are created using a connection, I don't like using, perhaps from? -- I haven't gotten to the API yet. I'm also uncertain about 'a connection' vs. 'connections' which is the transactions connection. s/transactions/transaction's/ The transaction has a mode which determines which types of interactions can be performed using the transaction. s/using the transaction/upon it/ ? -- The transaction also started the sentence. The mode is set when the transaction is created and remains constant for the s/constant/fixed/ lifetime of the transaction. s/lifetime/life/ The transaction also has a scope which determines which object stores the transaction can interact with. s/which.*with/the object stores with which the transaction may interact/. Finally, transactions have a active flag, s/ a / an / s/Finally, t/T/ -- It isn't Finally -- Finally is used again in the next sentence. which determines if new requests can currently be placed against the transaction. The prose here implies that this is mutable, it's also awkward (probably he use of 'currently'). Finally, transactions also contain a request list of requests which have been placed against the transaction. It seems that placed is treated as technical language, I'd expect it to be defined somewhere (or globally replaced by 'made'). Transactions have a constant scope which is determined when the transaction is created and remains constant for the lifetime of the transaction. Each transaction has a fixed scope determined at creation time. Transactions offer some protection from application and system failures. A transaction represents an atomic and durable set of data access and mutation operations. I know that data can be uncountable or plural, but I'm unsure that 'access' fits with its use here -- should it be 'accesses'? This is encouraged using the automatically committing functionality described below. s/using the automatically/by the automatic/ Authors can still cause transactions to run for a long time, however this is generally not a usage pattern which is recommended s/usage pattern which is recommended/a recommended usage pattern/ and can lead to bad user experience in some implementations. possibly a bad user experience | bad user experiences ? A transaction is created using IDBDatabase.transaction. The arguments passed determine what the scope of the transaction is s/what//; s/is// and whether it's read only or not. whether or not it is read-only. When a transaction is created its active flag is initially set to true. The implementation MUST allow requests to be placed against the transaction whenever the active flag is true. This is the case even if the transaction has not yet been started. Until the transaction is started the implementation MUST NOT execute these requests, but the implementation MUST still keep track of the requests and their order. s/, but/;/ s/still// Requests may only be placed against the transaction s/the/a/ while the transaction is active. s/the transaction/it/ If a request is attempted to be placed against a transaction when I find request/attempted/placed awkward, possibly because it lacks an actor... it is not active, I believe not active is used here to be the technical state not active, perhaps it should be marked up. Otherwise as this is prose, I'd use inactive. the implementation MUST reject the attempt by throwing a TRANSACTION_INACTIVE_ERR exception. Inactive is used in the exception type, it's a valid English word Once an implementation is able to enforce the constraints defined for the mode of the transaction, transaction mode defined below, the implementation MUST asynchronously start the transaction. When this happens is affected by the mode in which the transaction is opened, and which object stores are included in scope of the transaction. s/which/the/ s/are// s/scope of the transaction/the transaction's scope/ Once the transaction has been started the implementation can start executing the requests placed against the transaction. Unless otherwise defined requests MUST be executed in the order they are placed against the transaction. s/they/in which they/ s/are/were/ I find placed against strange. made against seems to work Otherwise placed into Likewise, their result MUST be returned in the order the request was placed against a specific transaction. result appears to be used as a mass noun, but request is singular, I'm pretty
Re: How many ways to save store app data?
On Mon, Mar 28, 2011 at 4:21 PM, Arthur Barstow art.bars...@nokia.com wrote: Louis-rémi's thread [1] on AppCache led to discussions about other storage related APIs including DataCache, Google Gears, IDB and the File * APIs. Of note, Google Gears is basically gone (as of Google Chrome 12 and similar): http://gearsblog.blogspot.com/2011/03/stopping-gears.html
Re: CfC: new WD of Clipboard API and Events; deadline April 5
On Tue, Mar 29, 2011 at 2:37 PM, Arthur Barstow art.bars...@nokia.com wrote:
http://dev.w3.org/2006/webapi/clipops/clipops.html
If you have any comments or concerns about this proposal, please send them
to public-webapps by April 5 at the latest.
Sorry, i've been doing other stuff
[editorial]
Mathematical information
With content such as mathematics, simply copying rendered text and pasting it
into another application generally leads to most of the semantics being lost.
I think math is more appropriate here.
And probably leads to the loss of most of the semantics.
Also, the XML source could be placed in the clipboard with the appropriate
transformation occurring when pasting.
The XML source can also ...
I find when pasting problematic. At paste time might be better, or
some indication of which side is doing the transformation.
---
interface ClipboardEvent : Event {
void initClipboardEvent (in DOMString eventType, in boolean canBubble, in
boolean cancelable, in DOMString dataType, in DOMString data);
doesn't seem to allow for multiple flavors.
clipboardData of type DataTransfer, readonly
The clipboardData attribute is an instance of the DataTransfer interface
which lets a script read and manipulate values on the system clipboard during
user-initiated copy, cut and paste operations. The associated drag data store
is a live but filtered view of the system clipboard, exposing all data types
the implementation knows the script can safely access.
safely seems underspecified, you probably should clarify that this
includes not exposing anything for synthetic events.
5.3 Determining the target property for clipboard events
In an editable context, the event object's target property must refer to the
element that contains the start of the selection in document order, i.e. the
end that is closer to the beginning of the document.
iirc DOMRanges can have start after end to indicate that the user has
made a selection in reverse. Is there a reason to ignore that
information and give different targets each time the user extends the
selection?
Calling getData() too many or too few arguments should throw
calling foo() _with_
Calling clearData() empties the system clipboard, or removes the specified
type of data from the clipboard. See HTML5 for details [HTML5].
This has issues. If the user has inserted something the user cares
about into the system clipboard, then allowing a web page to stomp on
it is annoying. Something needs to protect the user from such web
apps.
Calling getData() from within a paste event handler will return the clipboard
data in the specified format. See HTML5 for details [HTML5].
doesn't explain what should happen when the web app tries to paste a
content type the user agent has decided it shouldn't have access to.
The event is asyncronous but must be dispatched before keyup events for the
relevant keys.
asynchronous
The user might paste hidden data which the user is not aware of.
.. not aware of is kinda messy. Also, perhaps hidden data already
indicates the user doesn't know about it?
The implementation must not download referenced online resources and expose
their contents in the FileList.
s/and/or/
Objects implementing the DataTransfer interface to return clipboard data
must not be available outside the ClipboardEvent event handler.
If a script stores a reference to an object implementing the DataTransfer
interface to use from outside the ClipboardEvent event handler, all methods
must be no-ops when called outside the expected context
Implementations must not let scripts create synthetic clipboard events to
get access to real clipboard data
the last two points are missing periods
Implementations must handle scripts that try to place excessive amounts of
data on the clipboard gracefully.
I hope gracefully is flexible. If my impl wants to terminate the
page, it should be able to do so. (I don't expect it to do so, but I
reserve the right)
Remove all of the following elements: SCRIPT, APPLET, OBJECT, FORM, INPUT,
BUTTON, TEXTAREA, SELECT, OPTION, OPTGROUP and comment nodes. For all
mentioned elements except FORM, also remove all child nodes.
I can imagine doing magical things with a style tag...
However, removing the active value from a select seems suboptimal.
If you see:
State: [ |v]
And use it to get:
State: [ Washington |v]
When you copy it, do you expect:
State: or State: Washington? I expect the latter, it's
considerably more useful.
Re: CfC: new WD of Clipboard API and Events; deadline April 5
On Sun, Apr 10, 2011 at 9:30 PM, Charles McCathieNevile cha...@opera.com wrote: Disagree. In explanatory text the more correct term is clearer. math is only american in usage, and avoiding the feeling that it is a typo would reduce congitive dissonance without being incorrect. ok not realising it is there? sounds good
Re: [widgets] Removed LocalizableString interface from Widgets API
On Fri, 21 Jan 2011 19:32:57 +0100, timeless timel...@gmail.com wrote: a nokia maps application uses json for localization and could be easily ported to the widget format. On Fri, Jan 21, 2011 at 9:09 PM, Charles McCathieNevile cha...@opera.com wrote: Could you automatically port it? The structure is: html/mapplets/component/i18n/locales ~8k per locale per component html/mapplets/stuff [2.5mb] html/medos/i18n/locales ~64k per locale, ~1mb for however many locales total html/medos/images/stuff ~680k html/index.html ~948k html/ [6.2mb inclusive] the index.html file uses relative refs, so yeah, it'd probably be possible for *someone* - *not* me to automatically port it. I really don't have time to do this. It should be possible for anyone w/ an n900 to look at /usr/share/nokia-maps and investigate it. the fact that each component is using its own subdirectory thing is moderately annoying, but fixing the include paths wouldn't be too painful for an automated tool. fwiw, my understanding is that nokia-maps works more or less the same way on maps.ovi.com, which means someone feeling adventurous could probably try to do it from there, but since i like my product, i'd request someone be nice and buy an n900 instead of slurping ovi maps ;-).
Re: [widgets] Removed LocalizableString interface from Widgets API
note that you don't *need* to duplicate html files. the format allows for one to have json based localizations. a nokia maps application uses json for localization and could be easily ported to the widget format. i can't do it publicly because i don't own/manage the code.
Re: [widgets] Storage keys and ECMAScript incompatibility?
On Wed, Dec 15, 2010 at 3:29 PM, Scott Wilson scott.bradley.wil...@gmail.com wrote: things like widgets.preferences.12345=xyz throw exceptions. widgets.preferences[12345]=xyz probably works...
Re: [widgets] Storage keys and ECMAScript incompatibility?
note that i should have said: widgets.preferences[12345]=xyz probably works... since other reserved words don't work well unquoted... and obviously if your identifier includes , ', or \, you may need to quote it or escape it appropriately...
Re: Widget packaging spec: make it clear in the Abstract or Intro that PC widgets != UI controls
This specification standardizes a packaging format and metadata for a class of software known as widgets. Unlike traditional user interface widgets (e.g., buttons, input boxes, toolbars, etc.), widgets as specified in this document are full-fledged client-side applications that are authored using Web standards such as HTML5 and then packaged for distributions. Minor complaint. I think it's possible to author a widget using things which are not web standards :). I don't of course endorse such activity, but i think it is possible.
Re: [Widgets] Mozilla open apps
On Wed, Oct 20, 2010 at 12:11 PM, Scott Wilson scott.bradley.wil...@gmail.com wrote: I've just had a look at this: https://apps.mozillalabs.com/ In some respects this is very much what we are aiming for (apps using HTML+JS+CSS) however it proposes a new proprietary app manifest format for Widgets that is almost identical to PC, plus an auto-update spec (that isn't Widget Updates). So a lot of reinventing the wheel. Does anyone here have any contact with the project? I don't (sadly)
Re: ISSUE-122 (add mousewheel): Consider adding 'mousewheel' again [DOM3 Events]
On Fri, Sep 10, 2010 at 2:09 PM, Web Applications Working Group Issue Tracker sysbot+trac...@w3.org wrote: 'mousewheel' was later dropped based on feedback from implementers (Mozilla, Microsoft), who expressed a reluctance to implement 'mousewheel', and a lack of useful interoperability and concern that any change to improve interop would likely break a number of sites. However, the group may wish to consider adding it again, see: * http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0103.html I'm generally concerned about events which don't work well in other media. One of the challenges we faced while developing the n900 was dealing with web sites which expected a fully functional two button mouse (the n900 is a touch screen with no buttons). We've had designs at time which provide for showing a mouse on part of the screen and enabling a user to tap on the left/right buttons etc., this is painful, expensive, awkward, and I don't have any studies showing users manage to make this work. Having to deal w/ the scroll wheel case makes this worse. Otoh, it /might/ be ok to specify onzoom and onscroll, most devices have /some/ support for these operations (in the n900 we have hardware volume keys which are sometimes used for zooming, and the user can user their finger or stylus to trigger a scroll operation). The same general behaviors could exist in e.g. the iPod Touch/iPhone/iPad -- none of which have a scroll wheel. Sorry for the lateness of my reply, I was on vacation last month and now have 100+ conversations in this group to catch up on (this includes not being able to respond to messages between LC Announcement and LC Deadline).
Re: XHR2 proposal: support for informational responses
On Fri, Sep 10, 2010 at 6:07 PM, Julian Reschke julian.resc...@gmx.de wrote:
it might be cool (and not too complicated) to (optionally) expose 1xx
responses to the caller (see
http://greenbytes.de/tech/webdav/rfc2616.html#status.1xx).
There's one application I know of (not browser based) which regularly
reports Error 100 Continue ... as a dialog.
This could be done through an opt-in, such as specifying a callback function
to be called asynchronously when the messages come in (returning status line
and headers).
As long as it's opt in per specific code, to avoid the disaster that
I've seen in existing apps which don't properly handle this, it should
be fine.
xhr.addEventListener(http100, function callback(status_number,
status_string, response_headers, response_body){})
Note that I'm not in favor of someone adding support for http1xx, I
expect callbacks to be surprised when they get a specific number that
is not the one they were designed for (just as my app above wasn't
expecting 100).
Re: [widgets] Draft minutes from 23 September 2010 voice conf
On Thu, Sep 23, 2010 at 5:06 PM, Arthur Barstow art.bars...@nokia.com wrote: Regrets Minor note, I had told people in August that I would be on vacation for September, thus I should have been listed in Regrets for this meeting (and the previous one).
Re: A URL API
On Mon, Sep 20, 2010 at 9:27 AM, Adam Barth w...@adambarth.com wrote: On Sun, Sep 19, 2010 at 10:48 PM, Devdatta Akhawe dev.akh...@gmail.com wrote: 1) There are now two methods for getting at the URL parameters. The and none for setting them? That's correct. Looking at various libraries, there seems to be much more interested in paring out query parameters than for constructing them. One popular JavaScript library did have an API that took a dictionary and built a query string out of it. I imagine most folks just use the HTML Form element. MXR (hg.mozilla.org/webtools/mxr/) has an api for constructing urls (mostly parameters really). It tends to do redirects/rewrites which send most but not all of a set of parameters to another location. Another thing it sometimes tries to do is drop empty bits (input name=x value=) from the url. another thing it of course does is strip out '../' or similar variations. Note that MXR happens to mostly do its work server side, but there are bits which would do equivalent work client side, the server/client side bit is an implementation detail and I'd expect that people not caring about JS-off browsers would put much more of the code into the client and use javascript to do these manipulations. I'm sorry that I don't have time to read the current document. I'll try to do that once I finish reading my backlog.
Re: [widgets] Best practice / recommendation for widget id scheme?
On Sat, Oct 2, 2010 at 6:53 PM, Marcos Caceres marc...@opera.com wrote: Alway use a http uri. Should we make an Authoring note in PC about this? https should be ok too :)
Re: Seeking agenda items for WebApps' Nov 1-2 f2f meeting
Thanks to Art, I'll be there. Most likely I'll be available as a scribe. I'm still digging through my backlog (one month's vacation takes time to recover). I should be done w/ my webapps backlog sometime tonight minus comments on actual documents (and that leaves one more mailing list w/ 400 threads to read). notes to self: Currently I need to look at D3E, DOM-Core, Widgets: TWI + PC. I'll also try to read a few charters before TPAC, e.g. Web-Notifications.
Re: ISSUE-137 (IME-keypress): Should keypress events fire when using an IME? [DOM3 Events]
On Wed, Oct 6, 2010 at 9:16 AM, Web Applications Working Group Issue Tracker sysbot+trac...@w3.org wrote: ISSUE-137 (IME-keypress): Should keypress events fire when using an IME? [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/137 Raised by: Doug Schepers On product: DOM3 Events Hallvord R. M. Steen http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0176.html: [[ current spec text says about the keypress event: This event type shall be generated after the keyboard mapping but before the processing of an input method editor, normally associated with the dispatching of a compositionstart, compositionupdate, or compositionend event. I think this is wrong, if an IME is actively processing the input no keypress event should fire. ]] There was some discussion at work about how a search engine (e.g. Google [this was before it had the really live search, but after they added the drop down stuff]) might want to handle incomplete IME bits. I'm not sure if we have useful notes on this subject, nor do I remember what my opinion was at the time (it would have been about a month before my vacation which lasted a month). I think my general tendency was to ask not to provide keypress but to provide the event in some IME specific event instead. It's ok for an IME aware HTML application to listen for such events, but it isn't OK to confuse a naive web application (and let's face it, most are). I might have also argued that it would be ok to provide keydown/keyup notifications and only suppress keypress, but I really don't recall.
Re: ISSUE-141 (IME examples): IME examples [DOM3 Events]
On Wed, Oct 6, 2010 at 9:22 AM, Web Applications Working Group Issue Tracker sysbot+trac...@w3.org wrote: ISSUE-141 (IME examples): IME examples [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/141 Raised by: Doug Schepers On product: DOM3 Events Hallvord R. M. Steen http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0180.html: [[ In the text about Input Method Editors [1], the examples do keydown: 's' (U+0073, Latin Small Letter S key) compositionstart: '' keyup: 's' (U+0073, Latin Small Letter S key) keydown: 'i' (U+0069, Latin Small Letter I key) keyup: 'i' (U+0069, Latin Small Letter I key) keydown: 'Convert' Now, I'm not a developer - merely a black box QA tester - but is it possible to implement this in a cross-platform way? AFAIK, on Windows, Windows mobile and perhaps other platforms all the implementation will get in a keydown event is a VK_PROCESS virtual key code. How is the implementation then supposed to map that to an 's', an 'i' and so on? What sensible implementations currently do is to fire keydown with keyCode set to 220 (VK_PROCESS) and keyup with the actual key's virtual key code - if the platform makes it available in keyup events, otherwise 229. (Sorry about the number of separate E-mails today. I've tried to read the spec carefully earlier, but it's funny how you overlook things and they suddenly jump at you..) [1] http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#keys-IME ]] I think I had similar concerns when looking at what the IME for Maemo5 or its successor could provide (it tends to take lots of shortcuts). I think in general it is not safe to expect IMEs to be particularly forthcoming in their contribution of events. Also, the Maemo 5 IME can do things like complete ti as timeless, from my perspective this is really an IME effect, it's equivalent to me pasteing timeless or meless over/after ti (however you want to think about it), it isn't equivalent to me typing t i m e l e s s, as I didn't do that. One reason to consider this is when you look at how PuTTY for s60 or the Maemo IME work w/ SSH sessions over dialup. If each character is pressed, each would be sent as its own *expensive* packet over a slow and expensive dialup link (where the user is paying per padded encrypted packet), plus the round trip response packets. In mobile devices each packet and each computation to process each useless intermediate step is expensive, so avoiding them is appreciated.
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
Whomever adds delete/continue back to the spec needs to inline into the spec an explanation of why it's ok per ES5. Most (all) of us grew up pre ES5 and *believe* that they're truly reserved keywords and that what you're doing is invalid. So without inlining the explanation into the spec, you're asking for people to think you're crazy. Personally, i think trying to mark something as locally unreserved is crazy, since you're fighting the web's collective knowledge. http://javascript.about.com/od/reference/g/rdelete.htm Definition: The delete statement deletes an object that was created using the new statement. Delete is a reserved word and cannot be used for anything other than deleting an object. Note that it seems clear that people here do not care about the web's collective knowledge, so I'm not asking you to stop.
Re: Updates to File API
On Fri, Jun 11, 2010 at 10:04 PM, Michael Nordman micha...@google.com wrote: Another advantage is that... blobdata://http_responsible_party.org:80/3699b4a0-e43e-4cec-b87b-82b6f83dd752 ... makes it clear to the end user who the responsible party is when these urls are visible in the user interface. (location bar, tooltips, etc). It doesn't, it just means yet another way for scripts to confuse the user. Every time we provide a string whose domain is in control of a domain, the set of evil uses increases as evil groups set up more interesting domains and trick users for another two or three years. With browsers targeting smaller devices, as well as users who are less familiar with the web, or even experienced users who missed memos about IDN, these improvements just cause more problems. Tab: I'd like to specifically call you out for your inclusion of: http://www.詹姆斯.com/blog/2010/06/html5-atom-gone-wrong, a comparison in a recent email. .COM does not allow IDN and you should not have used that. I know someone was being cute, but that doesn't justify confusing users. I don't have time to construct a similarly written domain which happens to go to my own spoof, nor am I going to invest the ~9 USD that it would cost to do so, but it is perfectly reasonable for someone else to do so. The time it would take is probably around 10mins including picking a similar character, registering the domain, and posting content. It's true that this spoof would not fool all of the people all of the time, but it would probably fool most of the people most of the time.
Re: XMLHttpRequest Priority Proposal
On Wed, Jun 2, 2010 at 10:11 PM, Mike Belshe mbel...@google.com wrote: Changes: * changed the setPriority() method to be an attribute priority Applications may alter the priority by calling the setPriority() method on the XMLHttpRequest object. The priority set on the object at the time the applicaiton calls the XMLHttpRequest.send() method determines the priority the browser should use when fetching this resource. Calling setPriority() Presumably you intend to change these instances of 'setPriority()' to reference setting the attribute?
Re: ENISA Smartphone security study
On Wed, May 19, 2010 at 5:27 PM, Giles Hogben giles.hog...@enisa.europa.eu wrote: I am a security expert at ENISA (the European Network and Information Security Agency). We conducting a study on smartphone security and would like to have input from the Web Apps WG via the attached questionnaire, as well as reviewing of drafts of the study when it is ready. Questonnaire1.pdf contains: Please specify the platform(s) your answers apply to (e.g. Android, Apple, Blackberry, Ovi, Windows Phone 7) I don't think Ovi is a platform in the same sense that Android, Apple (s.b. iPhone), Blackberry and Windows 7 are. Ovi is perhaps a store (ala Apple's iTunes store) and a services platform (perhaps akin to Google Apps or Microsoft's Live suite). Nokia provides a number of platforms: S40, Symbian, Maemo, Meego. Nokia also has other software stacks including Qt (which is perhaps comprable to Apple's Cocoa). Personally -- And I do mean this, I don't represent my employer, this working group or any other -- I think that your request to this working group to fill out your survey is a misuse of this working group's openness. OTOH, I'm glad that I had the opportunity to see your survey, because I'm sure had you used proper channels, I wouldn't have.
Re: Pre-LC Review Requested: System Information API
On Wed, May 12, 2010 at 12:35 PM, Max Froumentin max...@opera.com wrote: - isBattery: true if the current power source is a battery - isBeingCharged: true if the current power source is a battery and is and drop current from the descriptions. Why? The power source can be changed over time. batteries=getBatteries(); battery0=batteries[0]; battery1=batteries[1]; --- battery0.isBattery == true; battery1.isBattery == true; battery0.isCharging == true; battery1.isCharging == true; --- Here we have two batteries, both are charging. current here adds nothing. A property isCharging naturally applies to the object of which it is a property (battery0 or battery1), the batteries are both current since they came from batteries[]. dunno. my n900 has a vpn regularly, the others at the office will often have WiFi + USB. At the same time in the same application? I think we're going to get in trouble with the definition of application. My browser will certainly have some traffic which wants to go over the VPN and some traffic which will want not to go over the vpn. Oddly enough, while i'm at work, I'll have a web app where the authentication bits will somehow come from the office side and then somehow want to connect me to an application outside our intranet. The MMS use case really is a use case. wrt apps which implement mms, for the n900, i'll point to fMMS. Note that in reality, MMS is basically a web app which uses web like protocols to send web like content. but for MMS the application can use the Messaging API. I think it's confusing to see MMS withing the scope of Network. In the case of fMMS, there *was* no Messaging API, the poor guy had to write his own (presumably using http). He's a real use case, he added something because the platform was perhaps arguably deficient. The platform had chosen not to include a feature. The platform is also fully capable of shipping a deficient feature implementation which someone needs to replace... I think that I leaning towards the former now, but with string values [[ attribute type; one of Wired, WiFi, Bluetooth, GPRS, GSM. Updates of this specifications may standardise more string values. In the meantime vendors may define non-standard values, blah blah blah ]] I'm sure someone will someday curse me for having to guess the case of the strings.
Re: Pre-LC Review Requested: System Information API
On Tue, May 11, 2010 at 5:47 PM, Max Froumentin max...@opera.com wrote: Ah, I see. It was the most logical place to put it. After both high and low were defined, but not separate. I don't know if it's wise repeating the same text in both places, either. I'm just flagging. I'm hoping someone else will have an opinion, or an example of precedent. In that case we should remove internal/external terminology and define attributes as: - isBattery: true if the current power source is a battery - isBeingCharged: true if the current power source is a battery and is being charged What do you think? I'd prefer isCharging, but otherwise, yes. and drop current from the descriptions. The tracker is down at the moment, and I'm not sure what to look for in my email, but the group decided that we shouldn't put in the API features that we can't see used outside of a system monitoring context. ok For instance, we don't find a common use for exposing multiple CPUs and their frequencies. The same principle applies here: how often does a device use multiple internet connections? Should it matter to the API user? I think that the answer is no. dunno. my n900 has a vpn regularly, the others at the office will often have WiFi + USB. It's likely that some n900s or similar will have both a GPRS network and an MMS network. Those are oddly enough distinct networks. And if an app wants to be an MMS sender, it actually needs to know that the MMS network exists and that it is different from the normal GPRS network. The IP addressing for GPRS and MMS can be entirely unrelated (it's a disaster, if you have some time for an amusing read, feel free). The MMS use case really is a use case. wrt apps which implement mms, for the n900, i'll point to fMMS. Note that in reality, MMS is basically a web app which uses web like protocols to send web like content. That seems to be a good use case for policy rules, actually. I expect the policy framework comes up with would cater for this scenario. ok It would be interesting to have those attributes, but I don't think it's going to be what webapp developers will want. Adding Bluetooth, WiMax, USB (or just Serial) seems acceptable, seems reasonable. but listing mobile phone data network types (GPRS, EDGE, etc.) risks becoming quickly obsolete. Oh, I'm suggesting offering the attributes w/o specifying the actual network names. Of course, we have the problem of security grades where we once had high, medium, and low. Eventually low disappeared, and we couldn't recalibrate. I'm a bit lost. You suggested that the type of network connection is a UA defined type, in constrast to a number, such as error codes? Can you elaborate on how it would work? Oh, I wasn't suggesting, mostly poking at the contrast. If you use attributes instead of names/numbers, then it's much less of a problem.
Re: Pre-LC Review Requested: System Information API
Please note, that like Jonas, I'm not endorsing any of this.
http://dev.w3.org/2009/dap/system-info/
the system which they are running on.
... on which they are running.
Specifically, properties pertaining to the device hardware are addressed.
exposed?
Therefore, a conforming implementation of this specification MUST ... SHOULD
Wow, that's incredibly expensive. I'm pretty sure this will be death
by a thousand papercuts to the computer user, and we'll suffer from
the same problems that the java security dialogs gave us in 1996.
user's express permission
Please end sentences (and paragraphs) with periods :).
The user interface MUST include the URI of the document origin, as defined in
[[!HTML5]].
If the URL is 50,000 characters long and has a bidi domain, and my
screen is tiny, must I show the whole URI?
User Agents MUST respect revoked permissions.
What does this mean?
permission to access one API ... does not... granted permission... to access
the same method with ... different ... arguments
This sounds like more papercuts.
permission ... to... access the... battery level, ... seek... permission
...when any... function is called on this API.
More papercuts.
Some User Agents will have prearranged trust relationships that do not
require such user interfaces.
require [][showing] ?
Privacy considerations for recipients of system information
Jonas suggested removing this section, since it's just misleading to
everyone. I concur. Most content providers will ignore this and it's
unenforceable.
Recipients should clearly and conspicuously disclose the fact that they
are collecting system data, the purpose for the collection, how long the
data is retained, how the data is secured, how the data is shared if it is
shared, how users can access, update and delete the data, and any
other choices that users have with respect to the data.
So after giving me hundreds of papercuts you're going to drown me in
HIPA forms, to ensure my eyes glaze over?
* An interface, whose name is the same as the property's name, and which
contains its attributes
attributes[][.]
identify the property accessed.
accessed property
(through the id attributes of the options parameter,
attribute[s][]
The URI or name of the property to retrieve.
... requested property.
can I pass http://www.w3.org/2010/../2009/dap/SysInfo/Power?
PendingOp watch()
Object.watch is taken, please don't step on it.
https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference:Global_Objects:Object:watch
monitor() if you mean continuous, inspect(), if this is merely a one
time polling operation.
2. ... have changed
changed[][.]
3. When a system event is successfully received
received?
received[][,]
Property URI or name identifying the property to track.
function called when the properties have been successfully retrieved
[f][F]unction ... retrieved[][.]
function called when an error occurred while retrieving the properties
[f][F]unction ... properties[][.]
An object containing the various options for fetching the properties
requested
requested[][.]
I think property should be in the singular
The URI or the name of the property to check for.
[for][][Don't end a sentence with a preposition.]
All functions except has return a PendingOp object,
has[][()]
defined in [[!CORE-DEVICE]], which has a cancel function allowing the
asynchronous operation to be interrupted.
cancel[][()] ... [interrupted][stopped]
The application context does not have permission to access this property
The property that has been passed to the set function that has triggered
this callback cannot be modified.
set() or setter
The number of milliseconds beyond which the operation must be interrupted
and the cancel method of the PendingOp object must be called.
cancel[][()]
attribute double highThreshold
attribute double lowThreshold
This attribute has no effect on the get method. On the watch method, it
indicates that the
get() or getter
On the inspect() method...
If both highThreshold and lowThreshold parameters are specified, the success
callback is triggered if and only if the property value is either lower than
the value of lowThreshold or higher than the value of highThreshold.
It's odd that you've stuck this into lowThreshold but not high
If this property is enumerable,
[this][the]
this device (e.g. the microphones attribute of the InputDevices property).
In the first blob you used 'this property', in the second 'this
device'. Both are problematic (as can be seen by the fact that you
used two), please find something else.
navigator.system.watch(Power,success,null,{lowThreshold:0.2,
thresholdTarget:level});
function success(power) {
alert(Low battery level: +power.level);
So, there's no timeout, to me watch implies continuous, is the UA
supposed to call success repeatedly until it does
Re: Pre-LC Review Requested: System Information API
On Mon, May 10, 2010 at 3:23 PM, Max Froumentin max...@opera.com wrote: On 10/05/2010 11:12, timeless wrote: Please note, that like Jonas, I'm not endorsing any of this. What do you mean by that? Oh, it's sort of a standard disclaimer that people involved with Mozilla or as members of other companies which aren't necessarily part of the working group tend to include. But Jonas's disclaimer was funnier. If both highThreshold and lowThreshold parameters are specified, the success callback is triggered if and only if the property value is either lower than the value of lowThreshold or higher than the value of highThreshold. It's odd that you've stuck this into lowThreshold but not high What do you mean? == attribute double highThreshold This attribute has no effect on the get() method. On the monitor() method, it indicates that the successCallback is only be triggered if the property is a number and its value is greater than or equal this number. attribute double lowThreshold This attribute has no effect on the get method. On the monitor() method, it indicates that the successCallback is only be triggered if the property is a number and its value is lower than or equal this number. If both highThreshold and lowThreshold parameters are specified, the success callback is triggered if and only if the property value is either lower than the value of lowThreshold or higher than the value of highThreshold. == That last sentence is only present in the description of the second attribute. Indicates whether the internal power source is currently charging. A value of true, indicates that the battery is being charged. If false then the battery is not being charged. What if I have an external battery which is being charged? then both isExternal and batteryBeingCharged are true. The description says internal power source is currently charging, I'm offering to charge the external power source. I think you should elide internal. I've looked for a reference that explained the meaning of all the terms that I considered, and failed to find one. Do you know if there is something out there that would indicate what those terms mean? Wikipedia's articles here don't seem particularly bad: http://en.wikipedia.org/wiki/Load_(computing) http://en.wikipedia.org/wiki/CPU_usage Sentence. Why? Your emacs already fixed that. However. Round 2: ! The list of all the network connections. [the][] What if I'm using 2 or more connections concurrently? That's very advanced for this API. See previous discussions on this topic. Link please? :) The VPN case worries me. Sorry to hear. Why? People are unlikely to be aware that exposing details of their vpn connection is more interesting and potentially dangerous than just exposing their network connection. I might be willing to provide the connection details for my normal network connection, but corporate policy probably doesn't want me to disclose my vpn's information. Above you've specified that the UA can only disclose one, so which does it pick (and how?). TYPE_BLUETOOTH? or IRDA, RS-232, USB, WAP, etc. I wasn't sure where to draw the line and include standards that define a whole protocol stack, or ones that merely act as tethering protocols, or ones that just encapsulate Ethernet. I'd very much welcome a comprehensive list. I'd kinda want the list to be based on properties (pulse based v cable, power expensive, currency expensive, range [short, medium, long]): USB is Cable+Minor+Free+Short. Ethernet is Cable+Minor+Free+Medium. IRDA is Beam+Medium+Free+Short. Bluetooth is Radio+Medium+Free+Short. GPRS is Radio+Expensive+Expensive+Medium. WiMax is Radio+Expensive+Expensive+Long. People generally don't need to know the name, they need to know the attribute (is it $0, is it power hungry, can I ask the user to shake the screen, ...). Or a UA defined type? As a free-form string? It's tricky because they're basically not usable. The contrast was to this: == attribute unsigned short code The code attribute SHOULD contain one of the error values defined in this specification. An implementation MAY define additional error codes, but those MUST NOT use the numeric values defined here. == Btw, I'd suggest that you reserve a certain range, either for standards values or for UA values. This is not what I think about when I read RAM. I'd rather FLASH even if it's terribly inaccurate. I'd rather something accurate, so any suggestion is welcome. My colleague here said usually they'd call it Flash, so let's pretend I didn't posit that it might be inaccurate. http://en.wikipedia.org/wiki/Flash_memory seems to indicate that Flash is perfectly reasonable. Not to be confused with USB flash drive or Memory card is funny, because: A memory card or flash card is an electronic flash memory data storage device used for storing digital contents. The number of image sensor elements (pixels) of this camera This is a strange way to write what
Re: [widgets] Moving to DVCS platform Re: [admin] DVCS platform at W3C
On Tue, May 4, 2010 at 3:25 PM, Marcos Caceres marc...@opera.com wrote: With the WG's permission, I would like to move the widget specs to the DVCS platform. sounds good Maybe we can put it on the agenda for discussion tomorrow.
Re: [widgets] Zip vs GZip Tar
2010/4/30 Ian Fette (イアンフェッティ) ife...@google.com: I remain perplexed by the state of the spec is feature complete and looking for implementations - potential implementors saying the spec has X,Y,Z flaws - sorry, the spec is feature complete. We're looking for implementations. At this rate, it's not clear to me what implementations it's going to get. (speaking as an individual here, and not a representative of Google Inc, Google Chrome Team, or necessarily even as a member of webapps WG.) -ian Roughly there are already implementations. A spec at this point is looking for implementers to say this is not implementable because of a bug or fatal error. It is not looking for an implementer to say we don't like X, why not randomly tweak the bike shed color from red to hot pink. If it turns out that using a red bike shed will cause people to crash because they're all red-green color blind and can't see the red shed in front of the flat green background, then perhaps painting the shed hot pink is a necessary step to delivering the bike shed. But given that there are already implementations which have shown that a red bike shed works, then just asking to paint the bike shed hot pink doesn't work at this point. fwiw, I came two years ago and was already too late to change the signature mechanism. You're coming two years after I came late and asking to change the packaging mechanism. Your argument is that the bike shed color should be hot pink because you like it (it would be nice if you could use it on some beach somewhere in some condition which was not part of the requirements capture). My argument against the signature mechanism was based on canonicalization problems, and they tried to address that (not my hand waving, just the problem) by tweaking the spec, not by throwing out the entire model.
Re: [widgets] Zip vs GZip Tar
On Wed, Apr 28, 2010 at 7:48 PM, Gregg Tavares g...@google.com wrote: I'm sorry if I'm not familiar with all the details of how the widgets spec is going but the specs encourage comment so I'm commenting :-) It seems like widgets have 2 uses #1) As a way to package an HTML5 app that can be downloaded similar to a native executable #2) As a way to package an HTML5 app that can be embedded in a page but easily distributed as a single file (ie, do what Flash / Silverlight / Unity3D currently do except based in HTML5 / EMCAScript) Use #2 would benefit tremendously if like Flash / Sliverlight / Unity3D the application could start as soon as it has enough info to start as supposed to having to wait for the entire package to download. To accomplish that goal requires using a format that can be streamed. Zip is not such a format. Zip files store their table of contents at the end of the file. They can have multiple table of contents but only the last one found is valid. That means the entire file has to be downloaded before a UA can correctly figure out what's in the file. That's incorrect. Zip is streamable. Go read the format.
Re: [widgets] Zip vs GZip Tar
cool. thankfully the way the standards stuff works, it's too late to change any of this. e.g. the standards group has already selected a signing mechanism to which mozilla objects, but it can't be changed. similarly, zip can't be replaced in widgets. people are free to write replacement standards, and hopefully the signing mechanism will be replaced, but we're stuck with zip for widgets with the mime type they've registered. there's also a request to use multipart mime instead of zip, that too has been rejected. this is all covered in the archives.
Re: VMMF — new version
On Thu, Mar 4, 2010 at 3:13 PM, Robin Berjon ro...@berjon.com wrote: I just produced an update of VMMF to make it ready for publication: http://dev.w3.org/2006/waf/widgets-vmmf/. Essentially I changed it so that it corresponds to CSS Media Queries. That, plus it being a UI oriented specification, means that there's only one normative assertion and it's a SHOULD. Comments welcome, I think that this baby can ship. Just to be difficult, i object to maximized being misspelled by an old-worlder. I'd suggest max or maxed as a compromise :) widgets that have no chrome and that therefore could masquerade some other existing objects on the screen. s/therefore could/could therefore/ (e.g. tool bars, title bars, menus, etc.). (e.g. the menu bar, the clock and similar icons, the system menu, etc.). the use of 'e.g.' is generally incompatible with 'etc.' The view mode is the manner in which a widget is presented to a user that corresponds to the metaphors and functionalities in use on a given functionality [N-UNCOUNT] Describes a widget providing a more immersive interface, Google says that immersive isn't in their dictionary, Firefox concurs. Oh well, the web and its 3 million hits evolves to provide such terms.
Re: [widgets] API - openURL security considerations
On Mon, Feb 8, 2010 at 6:36 PM, Marcos Caceres marc...@opera.com wrote: At Opera we've been discussing some of the security implications around the openURL method in the widgets API spec. We think the spec might benefit if we were to add a non-normative security consideration section for openURL. The following text, which I did not write, can serve as a basis for the note - we are presenting it here for discussion, and you'll note it uses different terminology than the one found in the spec. In other words, please don't consider the following to be spec text, it needs a fair amount of editing but tries to get to the heart of the problem: Personally, I'd rather suggest that openURL not be treated as openURL but add url to suggested links. I have a blog draft that tries to explain it, but basically, an application has no reason to ask another application to open urls. Instead it should have the ability to give the user a series of urls which the user can treat as a bookmark list. If the user chooses to open one or more of those bookmarks, fine, however, if the user closes the application, having decided that the bookmarks aren't interesting, then they're gone. http://viper.haque.net/~timeless/blog/2/popups/ is the write-up, it's actually the oldest thing in my blog :). Note that my opinion has nothing specifically to do with widgets, I don't approve of random applications on my computer launching my web browser and ordering it to go somewhere. I'd rather my web browser just collect those suggestions and enable me to decide whether *I* want to go to some of them, and if so, which, and of course, at the time of my choosing. Note that in the case where a user actually trusts another application on their system, the user is free to use drag and drop to pull a url into the web browser, that would bypass the suggestion behavior. In the case of widgets, I don't think that such a feature should be supported because there's too much risk that the user is tricked into dragging something dangerous and changing the security principals of the source.
Re: Steps to creating a browser standard for the moz-icon:// scheme
2010/1/29 Pierre-Antoine LaFayette pierre.lafaye...@gmail.com: Perhaps if we found some creative commons icons to use as defaults for the most used extensions. It wouldn't match the native theme but at least we'd have something for cases where platform icons are not available. We'd need to have some number of sizes. I think Windows goes to a max of 72x72, while Mac OSX goes to 128x128. Mozilla defines the size as: No. Windows does 256x and OS X does 512x. At least, I've shipped such icons on behalf of Nokia and they seemed to match what Windows 7 and OS X wanted. http://www.macworld.com/article/60877/2007/11/big105icons.html http://www.axialis.com/docs/iw/How_to_create_Windows_Vista_compliant_icons.htm
Re: [public-webapps] Comment on Widget URI (3)
On Tue, Dec 15, 2009 at 6:09 PM, Robin Berjon ro...@berjon.com wrote: The term drive-by comment is one made against a specification in passing without the diligence and conscientiousness to participate in the follow-up discussion; and typically to then re-iterate it later. I believe that the term was coined during the denial of service by LC-comment conducted against SVG Tiny 1.2 — I may have mistakenly taken its usage to be more widespread. For the record, drive-by commenting exists in bugzilla.mozilla.org, along with drive-by reviewing (a form of commenting where one gives a review, typically negative).
Re: [widgets] Draft Agenda for 17 September 2009 voice conf
Regrets, i'm on vacation for a month starting tomorrow
Re: [widget-uri] Widget URI ABNF definition comments
On Tue, Sep 15, 2009 at 1:49 PM, jere.kapy...@nokia.com wrote: /4/ Finally, the IRI vs URI naming debate applies as ever. I agree it's messy in that we are so accustomed to URIs, but really should be using IRIs, and that not everyone is conditioned to mentally replace URI with IRI every time. Maybe changing the document name to Widgets 1.0: Widget Resource Identifiers would sidestep some of the problem. :-) So we can have URNs, URLs, URIs, IRIs, and WRIs? i'm not sure that's an improvement :)
Re: ISSUE: The application/widget media type has not yet been registered with IANA. This will happen when the specification reaches Candidate Recommendation status.
On Mon, Sep 14, 2009 at 3:14 AM, Innovimax SARLinnovi...@gmail.com wrote: I wanted to propose that the mediatype should be application/widget+zip In this case it is clear that it is a zip package (just in case another widget package come along with another packaging format : gzip, opc, etc...) This seems like a bad reason for a design decision. what will probably happen if two widget formats come into existence is that they'll both be .wdgt and then the mime type will always be wrong because someone will map .wdgt to application/widget+zip and the file will be TGZ, and on another system .wdgt will be tagged as application/widget+tgz but the file will actually be PKZIP. Either the file format is supported by the widget user agent, or it isn't. The widget user agent will have to open it up, follow its step and reach a conclusion. Nothing changes. Determining whether a file is PKZIP or something else isn't hard. I'm pretty confident that we're going to squat on application/widget, a right of being the first w3 group for an area. People will complain 10 years from now that we took the logical mime type, and that's their right. But the +xml stuff is a disaster that never went anywhere useful, so I'd just as soon not adopt it now.
Re: [widgets] Widgets URI scheme... it's baaaack!
On Tue, Sep 8, 2009 at 1:21 AM, Mark Bakerdist...@acm.org wrote: I don't understand. In what scenario would a script be comparing URIs produced by different implementations? implementations tend to be stupid and parse things by hand. if you don't believe this, all you have to do is look at the html5 discussion about c:\fakepath
Re: HTTP status code equivalents for file:// operations - compat with xhr
I'd rather we formally indicate that using file urls in XMLHttpRequests is not expected to work with an explanation that there are security concerns which prevent XMLHttpRequest safely exposing arbitrary file urls. People who need access to local files should use a locally bound web server or if the content is something they control, JSON or an iframe. something like: In order for implementations to protect their users, XMLHttpRequest implementations MAY choose not to support file urls or MAY choose whatever error values they like.
Re: DnD vs CnP (was Copy/Paste Events)
Paul Libbrecht wrote: - drag and drop allows a precise visual target identification thus may be considered safer (and this is actually implemented so: you can faster drag-and-drop URLs than copy and paste them). this isn't true. depending on how friendly your drop target is, it theoretically could be true, but in practice many apps do not make it easy to understand precisely where you're dropping or precisely what effects a drop will have. sometimes your entire document is replaced by the thing you thought you were dragging. sometimes you get something you didn't think you were dragging. I have a mac book, and sometimes when I want to eject my usb media, i try to drag it to the trash, because this is one way to eject disks. http://everything2.com/title/Dragging+a+disk+to+the+trash+to+eject+it+on+a+Macintosh talks about it a bit. Unfortunately, the concept isn't as simple as that, it turns out (and i finally understand it now [actually, i think i discover it ever couple of weeks and then promptly forget), then there's a difference between dragging the disk reference from the desktop to the trash and dragging the item from a finder window's tray to the trash. the former changes the trash to an eject icon and the latter doesn't. either way, when you drag a usb volume to the trash, the volume disappears from the finder window. except if you dragged it from the desktop you've safely unmounted it, and if you drag it from the finder window, you've just removed the entry from the finder window. There's almost enough feedback, but as it happens, i've now safely unmounted my phone half a dozen times this week because i can't remember how to use apple's drag and drop metaphor. Keep in mind that this drop target is supposedly *friendly* it tells me if it's actually going to eject by changing the icon of the target, and yet, i still don't manage to get it right most of the time (probably because my desktop is typically obscured, so i couldn't drag or see the volume on the desktop). Copying, however, is simpler and better understood as long as the selection model is clear. yesterday i was merging two documents using a third window (a browser) as a reference. mostly this meant a was copying an annotation (# UNUSED) from old-document to new-document and copying an identifier from new-document to cross reference to verify whether the identifier was indeed unused. I did this by having the browser (Camino.app) as approximately full screen behind a text editor that supports multiple windows (XCode.app) with two windows side by side. The process was basically: * in right editor window (new-document) 1. use the down arrow to move to the next identifier 2. use alt-right to select the identifier 3. use cmd-tab to switch to Camino * in Camino 4. double tap into the xref search field (this is about 10% down the screen and 10% to the right of the left edge) 5. use cmd-v to paste 6. use enter to start the search 7. use cmd-tab to switch back to XCode.app * in XCode 8. use cmd-` to switch to old-document 9. use cmd-c to copy # UNUSED 10. use cmd-` to switch to new-document 11. use cmd-left to go to the start of the line 12. use cmd-v to paste 13. loop In this process, i have two things which have to be in my clipboard, obviously neither is in my clipboard as long term storage, it's in fact merely drag and drop, but the coordinates of my drag source and drag targets are too disparate for me to use a mouse for most of them (and if i was really a keyboard user, i might have arranged it so that i could use a keyboard to focus the search field in the browser, or used the urlbar. I'm a power user, not a keyboard user, so i used the mouse for this step. the fact is that this process is really drag and dropping between three windows, i'm only using the keyboard because it's expensive to retarget and focus each of these areas. - copy-and-paste is aimed at long term storage: if you write to the clipboard you have to write all the flavours you think a recipient would ever make use of! The clipboard often survives computer-restarts. That's a clipbook, not a clipboard. Most clipboards do not survive restarts, heck half the time they don't survive apps quiting. - drag-and-drop is aimed at direct negotiations: generally, only at the end of the drag is the actual data produced. In case this is running over a network-based conversion this is significant I feel. I don't understand this. So I would insist to split the two set of events while keeping common, of course, some of the interfaces to denote what can be transferred. Insisting isn't how we do things here. Provide use cases, provide explanations, try to convince with real data. Hopefully my example is compelling,.
Re: Copy/Paste Events
Jacob Rossi wrote: Are you mostly referring to non-touch mobile users? I'll answer this first, by saying that it was a general reference. Although, it is true that today I work in the mobile industry. But i also worry about other scenarios. Perhaps for some people it's hard to use a mouse (there are cases where people who need accessibility aids really can't easily manipulate mice). Do you have any data on how many people would be browsing with neither mouse nor touch capabilities? I'm not going to go looking through my internal sources (partly because they're almost certainly confidential, but mostly because i'd have to find them). I'd imagine that the majority of cell phones do not have touch or a mouse. I'm fairly certain that there are more mobile phones than there are personal computers. Please keep in mind that just because a device is under powered doesn't mean it doesn't have a web browser or the ability to use a browser proxy (SkyFire [1] / Opera Mini [2]). I'm fairly certain more devices are capable of running proxies than have touch screens or mice. One possible solution is that copy-and-paste could be treated as drag-and-drop only when the browser is in Caret Browsing mode (do any browsers other than Firefox and IE have this?) and on mobile devices without touch capabilities. This would mean that such devices wouldn't be able to easily trigger copy/paste behaviors. Explaining multiple modes to users is a royal pain. Caret browsing is just another form of pain, so is spacial navigation. For lack of a confusing reference to such pain, i've done a quick search and found one: Widget interaction models [3]. I haven't read it, and please excuse the wonderful url structure. A quick glance indicates to me that it's confusing, and that's all I wanted in a reference :). [1] http://www.skyfire.com [2] http://www.opera.com/mini/ [3] http://www.forum.nokia.com/infocenter/index.jsp?topic=/Design_and_User_Experience_Library/GUID-759A5FA5-5B7D-4B64-ACD1-48783FFC4486.html
Re: Copy/Paste Events
On Mon, Jul 27, 2009 at 2:03 PM, Sebastian Markbågesebast...@calyptus.eu wrote: I agree with Jacob. I find this part of the spec... puzzling. so, one advantage of not distinguishing is that it enables people w/o mice to trigger drag events. if you don't do this, you effectively block such users from interacting with certain classes of web pages. Having encountered various other stupid forms of discrimination while working on devices which have limitations wrt input methods, i appreciate it when things are designed with more flexibility in mind. i'm not absolutely certain as to where i stand on this specific event, but i'm not immediately opposed to what Jacob quoted, and i respectfully request people to consider this. (I considered responding earlier and decided I'd wait.)
Re: Widgets 1.0: Packaging and Configuration LCWD review
Marcos Caceres wrote: a class of software application Was plural intended? Plural? as in: software applications
Re: widgets feedback
DoC: ok
Re: [widgets] PC, outstanding feedbac...
On Wed, Jul 8, 2009 at 4:51 PM, Marcos Caceresmarc...@opera.com wrote: For the sake of the DoC, can you live with the current i18n model? No.
Re: widgets feedback
On Fri, Jul 3, 2009 at 5:12 PM, Marcos Caceresmarc...@opera.com wrote: Fixed issues below. If satisfied with the corrections, please give us an OK for the DoC :) DoC: OK I guess the person at Times Square that made the decision to activate the widget. Oh well. Someday that user will be replaced by an automated random heisencat. I guess I'll just have to wait for that cat. * sections marked with the text This section is non-normative, *authoring guidelines, I hope there's a space after that bullet :) * examples, including sentences that contain the words for example, * and notes. AFAIK, that is correct here. But I can't be bothered looking up a manual of style. Yeah, I think you're right.
Re: widgets feedback
On Fri, Jul 3, 2009 at 6:37 PM, Marcos Caceresmarc...@opera.com wrote: Fixed all editorial comments below for this third set of comments. If satisfied with the corrections, please give us an OK for the DoC :) DoC: OK This would be the author's fault for including an empty file. The UA still does the right thing (it loads the index.svg file and finds it is not well formed.) Should CC's be encouraged to complain about such things? I suppose not as it's fairly hard to determine if random start formats won't work...
Re: widgets feedback
On Fri, Jul 3, 2009 at 6:55 PM, Marcos Caceresmarc...@opera.com wrote: Addressed your final set of editorial issues. If satisfied with the corrections, please give us an OK for the DoC :) DoC: OK except for the one below. 4:37 PM A user agent will acquire a potential Zip archive from a data transfer protocol that either labels resources with a media type (e.g. [HTTP]) or from a data transfer protocol that does not label resources with a media type (e.g., BitTorrent, Bluetooth, etc.). A tautology ... (yes, i know we're trying to say this, but is there a better way to write it?) I think I will leave it. The point here is to alert the reader that we handle both cases. Oh, I wasn't asking you to remove it, just rewrite it ;-) A user agent can acquire a potential Zip archive both from data transfer protocols which label resources with media types (e.g. ) and from data transfer protocols which do not (e.g. ...). I think you already got rid of the e.g.+etc. pair.
Re: [widgets] PC, outstanding feedbac...
On Fri, Jul 3, 2009 at 7:35 PM, Marcos Caceresmarc...@opera.com wrote: I talked to our localization guys about this, they said that is definitely not a good thing. They said any content is better than no content, even if there is a mismatch. I've spoken w/ coworkers recently, and other people too, and the general spirit is if the app is so poorly localized, and it usually is, they'd rather see it in the language where it isn't poorly localized that they actually understand (typically English; the people in question are typically natives of Finland and surrounding countries and have have English as at best a second or often a third language) I suspect that in the end, as long as a user agent allows the user to see which localizations the widget has and for the user to express a more limited list of preferences for a given widget, this won't be a problem, and hopefully user agents will do this. I agree, but that is Apple's fault. Yes, the model allows things like this to happen. But I think it's better thank getting no license at all. I still feel that this is an author-level error. I don't like enabling authors to screw up localization, it's too easy to do already, and they've proven to be quite adapt at it locally. -- My experiences in the States didn't show these problems, but that's probably because I was being sold untranslated goods or goods by vendors who were more careful. I agree this sucks, but like I said, my preference is to have something shown. When authors make such mistakes, then can easily be patched via updates, which is what updates are for. The iTunes example is unfixed to this day, a number of updates later. As is Nokia's flags example [1] and Centre (I got an update last week). I agree. But again, iTunes should do something about that. It can't be the case that widgets would not allow me to ship a widget because I can't get something translated. If that was the case, I would still include the wrongly localized content just so I could ship I'd prefer for you to be aware that you're screwing your customer. Having to actively jump through a hoop This is wrong, but I'm desperate and in a hurry, and know it's wrong v. I'm done, it's perfect, I'm never making any changes ever again (and just say, centre, center, meh! Only a few will notice, so I'll fix that in the next update.). Bah, it's still not fixed, and I've complained both through the care number and internal feedback. [1] http://library.forum.nokia.com/index.jsp?topic=/Web_Developers_Library/GUID-63F29096-C1A3-45DB-9E2F-6110562E0237.html It's good to see no one fixes their bugs. I really look forward to widget updates being as useless as everyone else's updates in these areas.
Re: [widgets] PC, outstanding feedbac...
I wrote:
hey, you won't like this, but... I think we botched the
l10n stuff :). The problem is that the design is based on individual
resources, which is wrong. Negotiation should really be done at the
Package level. This is one of those things where thinking HTTPish
screws you over. A user thinks about a web application or widget as a
single resource. That there are multiple subresources isn't
interesting to a user.
Jere wrote:
Well, I have an issue with thinking about the negotiation at the package
level, because that means that you need to provide separate downloadable
packages for each localized widget version. The idea is to provide as
complete localizations as possible in the one and same widget package, with
the added suboptimization that material can be reused if desired.
Oh, I'm not saying that you have to provide separate downloadable
packages, just that for the purpose of the user it should be as if the
user downloaded a package and was told:
This package is available in the following languages:
{list}
The useragent then says it seems that you prefer language X, I will
now ignore all of the other languages that are available in this
package while I'm running it.
The useragent may enable the user to specify a language Y, but doing
that would take effect when the widget is instantiated and again, all
languages not related to Y are ignored.
The user gets to express a list of preferences, but only one is taken,
the rest of the preferences are ignored.
One more example of this disaster as I don't think I included it:
A coworker of mine has his computer configured to use Russian as his
user interface language. We're both in Finland. He ran iTunes which
presented a license agreement.
As far as we were concerned, the license agreement was composed of
three resources:
1. a picture which said (in English) License Agreement
2. picture buttons which said (in Russian) Accept, Reject
3. a license, which was sent in Finnish
The useragent here was iTunes and it managed to do a really terrible
job of negotiating for resources. No user actually wants this result.
As it happens, We (my coworker and myself) don't speak Finnish to the
level of being able to accept license agreements.
Package:
iTunesLicense.wdgt/
index.html (widget container with iframes)
fi/licenseText.html (Finnish)
en/licenseAgreement.html
ru/accept.png
ru/reject.png
fi/accept.png
fi/reject.png
en/accept.png
en/reject.png
This is effectively what was provided by iTunes (in fact, the
accept/reject buttons came from Windows according to the user's select
User Interface Language, the licenseAgreement.html came from
iTunes.exe, and licenseText.html came from a web server which checked
our IP and determined our country).
As far as this iTunes useragent was concerned, the language
preferences were: ru, en, fi.
Myself, I got a version which was equivalent of en, fi. It wasn't
sufficient for me to accept the license (so all I got was a voucher
for two mp3's from the iTunes store... but only after I accept the
license).
So the right algorithm is: 1. collect the full
list of all locales for which the package is partially localized. 2.
build the list of user requested locales using the algorithm we
defined. 3. Use the first matching locale between (1) and (2). 4. Deal
with fall back. I think 4 involves telling Authors that if they want
to be able to use a /locales/en/ image in /locales/en-us/ then they
need a /locales/en-us/images.css that pulls in /locales/en/bird.jpg --
however, it's probably best just not to allow it at all.
I'm not convinced how this is the 'right' algorithm... Could you highlight
how this is different from the current one in the spec?
The key is that the algorithm in the spec will result in authors
accidentally getting an image whose caption doesn't work, because they
weren't aware that such a mix would happen. -- See further examples
below.
The reason for that is developer error, not system error or design failure.
Maybe somebody forgot to insert an appropriate image, and the fallback used
the wrong one. That¹s what localization testing and QA is for.
Oh, hey, we work for the same company. My experience with our testing
is that they miss everything of interest and when they give feedback,
the wrong things are fixed. But I can give examples for most companies
and also various open source projects (in case people object to
biasing toward companies).
I would
rather allow for the occasional wrong resource to be shown than make the
user pay for bloated download packages and duplicated resources. So,
fallback is important because it reduces duplication.
Falling back to Finnish when I don't speak Finnish is really annoying.
Had you gotten my iTunes license dilemma, it wouldn't have bothered
you, but that's because you speak Finnish. Try moving to China or
Russia and signing up for iTunes.
The UA locale list handles #1, but there¹s not a lot that the spec can do
for PC. Authors
Re: File API Feedback
On Wed, Jul 1, 2009 at 2:22 AM, Garrett Smith dhtmlkitc...@gmail.com wrote: The picasa-style example mentioned earlier uses the word upload. I've not used Picasa, but it appears to read files off a local network. confused. i suspect i was the one who mentioned it. Picasa is mostly a local application. One can do a large number of operations with it. among them: 1. select a number of local files 2. get previews (in some file formats that might be possible by sampling, e.g. an interlaced image format) 3. rotate 4. color correct (etc.) 5. upload in the case of getting previews and doing manipulations (which are actually done in two passes, a fast pass on the preview, and then an expensive background pass on the underlying data), these are local operations where portions of a file would be sufficient in certain stages. And it definitely would make sense to be able to upload a large file in chunks. I'm glad to see the API under discussion is growing support for ranges. Note of course that whatever API supports ranges needs to ensure that the data isn't forcibly coerced into valid Unicode, as the underlying data for an image can include all sorts of patterns which aren't valid UTF8/16/
Re: [widgets] Please include a statement of purpose and user interaction expectations for feature
On Tue, Jun 23, 2009 at 2:44 PM, Robin Berjonro...@berjon.com wrote: Precisely: defining behaviour would turn us into a UI specification — which we dearly want to avoid. yep. Constant prompting makes for a dreadful UX, that's for sure, yep. but fixing that should be up to UA vendors. or rather getting it right (and preferably the first time). At the end of the day, I do however have some confidence that they can do UI much better than anything Java related :) I have confidence that certain vendors could. But the vendor to which Henri alludes, and certain vendors in certain spaces OTOH, we don't have confidence about their abilities. But it really is beyond the scope of a specification like this to say don't drive your users crazy. Our goal should be to avoid requirements written as drive your user crazy. There's apparently a MUST in some HTTP spec for some stupid error case which would effectively mean you must annoy your user whenever you encounter this, thankfully either all browser vendors missed it, or they chose to ignore it. WRT the codecs thing, I'm not sure if it's in the minutes, but iirc the example was mine so as to avoid having something which said like APIs but provided no examples. And yes, granting permissions for features is beyond the scope of this specification.
widgets feedback
http://dev.w3.org/2006/waf/widgets/
Date: Tue, Jun 16, 2009 at 2:52 AM
2:29 AM me: hey
suppose that times square becomes widget capable
2:30 AM and starts running widgets, like a Clock.wdgt
who's the end user? :){
9 minutes
2:40 AM me: Bluetooth is spelled as such, no capital T
(i.e., users can share widgets over non-HTTP distribution channels,
such as BlueTooth, a USB thumb drive, etc.).
the idea of using both 'i.e.' and 'etc.' in the same parenthetical
scares me. although it might be correct in this instance
2:41 AM Supported means that a user agent implements a said specification,
said - mentioned ?
a said sounds really odd
2:42 AM maybe listed, indicated, ... dunno
Initialization means a run through the steps for processing a widget
package post installation of a widget.
post = after ?
2:43 AM As well as sections marked as non-normative, authoring
guidelines, diagrams, examples, and notes in this specification are
non-normative.
is hard to parse.
As well as sections marked as non-normative, authoring
guidelines, diagrams, examples, and notes in this specification are
non-normative.
2:44 AM In addition to (non-normative marked|marked non-normative)
sections, all authoring guidelines, ... and notes in this
specification are ... non-normative.
2:46 AM There are four classes of products that can claim conformance
to this specification:
2:47 AM that = which ?
(very uncertain about that)
2:49 AM Other legacy/proprietary widget types can be supported by a
user agent, but a user agent must conform to this specification when
dealing with a widget package.
should this say:
2:52 AM While a conforming user agent may support other
legacy/proprietary widget types in order to conform to this
specification it must treat widget packages as according to this
specification.
widgets feedback
Date: Tue, Jun 16, 2009 at 11:42 AM 8:42 AM me: A conformance checker (CC) is a user agent that verifies if a widget package and a configuration document conform to this specification. if = whether 56 minutes 9:38 AM me: liwhen the a class=no-toc no-num href=#rule-for-verifying-a-file-entry0rule for Verifying a File Entry/aspan/span is applied to the file, it returns the empty span is probably a bug 9:39 AM 6.3 Reserved File and Folder Names Reserved File Names you need to change 'xml' to '.xml' and similar 9:40 AM The [Widgets-DigSig] specification also defines the naming conventions for a distributor signature and the naming convention for an author signature. i think you want 'for distributor signatures' and 'for author signatures' (plural for both) 19 minutes 10:00 AM me: via a an access control policy. drop a 10:02 AM Marcos: end user should not be defined, me thinks me: fine by me 10:03 AM Marcos: I'm too nice to people like Benoit who want things like that defined but are not actually useful in the spec 10:06 AM Re: said - mentioned? I like said as it implies that a thing will be mentioned when the term is used. However, if you think it causes confusion, I will change it or clarify it 10:07 AM used mentioned 10:09 AM me: given? a said just sounds really odd a google search for a said fails the hits are all for people :) 10:14 AM Marcos: all fixed now :) 10:15 AM fixed for both supported and unsupported. No other instances found. 10:19 AM me: so, i'm not a fan of out of scope of (very few google hits), i prefer beyond the scope of (millions of hits) 10:20 AM Marcos: nice 10:21 AM me: The start file of a widget package is a file that is used by the user agent when the widget is instantiated. kinda useless statement you use the configuration file when the widget is instantiated too 10:22 AM you kinda want to somehow explain that it's more than a file that's used. although w/o limiting things to DOM style :) 10:25 AM does Default Start File actually specify the order in which one is found and if so, does it define a name for the thing that's found? When a start file is not explicitly declared via the content element, then start file will be one of the default start files. 10:26 AM it'd be better if you could just reference the algorithmically determined start file instead of hand waving at a list 31 minutes 10:58 AM me: might not be supported on all user agents. on = by then Make sure that the widget is labeled with an why is Make capitalized? Marcos: no reason 11:00 AM me: you use case-sensitively 5 times and as case-sensitive 4 times i don't like the latter :) as case-sensitive = case-sensitively 11:01 AM Marcos: sorry, distracted with our big product launch http://unite.opera.com/ 11:02 AM me: yeah, sorry, i don't care ;-), but i don't need realtime responses :) 17 minutes 11:19 AM me: feature name=http://example.com/camera; param name=autofocus value=true/ random blank line between those two? width = 200 viewmodes = application fullscreen 11:20 AM most things line up in this tag's attribute list, except viewmodes preference name =apikey 11:21 AM this tag doesn't get spaces after =,... if you're trying to demo lots of different styles, ok, but please note that somewhere, otherwise, ick :) Be sure to declare the widget namespace as part of the widget element. If the namespace is absent, then Zip archive will be treated as an invalid Zip archive. 11:22 AM it's odd to mark a zip file as invalid because of an error in the widget shouldn't the widget be invalid instead ? 11:24 AM Some general rule rules (plural) 11:28 AM Keyword list attribute oh fun, this,is,forbidden 11:30 AM do we need to say that ., .., ..., are interesting? 11:33 AM either by default as part of the [XML] specification (as is the case with xml:lang) or if the user agent implements the optional [ITS] specification. i don't think either .. if is a well accepted concept :) 11:34 AM drop either (it only fits either .. or) 5 minutes 11:40 AM me: Avoid subtags from the IANA Language Subtag Registry marked as deprecated, grandfathered, or redundant. The intended purpose of the xml:lang attribute is to declare the primary language of an element, its attributes, and its descendent nodes. shouldn't CC's complain about them too? 11:42 AM A valid URI that denotes an identifier for the widget. It is optional for authors to use this attribute. why mention 'authors'? does anyone else write this file? :)
widgets feedback
Date: Thu, Jun 18, 2009 at 4:52 PM
4:15 PM me: (e.g., floating and application mode)
either floating mode and application mode
or the floating and application modes
The following example shows the usage of the name element.
widget xmlns=http://www.w3.org/ns/widgets;
name short=Weather
The Ultimate Weather Widget
probably indent The one more space :)
19 minutes
4:35 PM me: file identification table
has 3 columns, one is entirely empty
4:36 PM Step 1 - Acquire a Potential Zip Archive
Step 1 involves acquiring a potential Zip archive
-- Potential v. potential?
4:37 PM A user agent will acquire a potential Zip archive from a data
transfer protocol that either labels resources with a media type (e.g.
[HTTP]) or from a data transfer protocol that does not label resources
with a media type (e.g., BitTorrent, Bluetooth, etc.).
A tautology ...
(yes, i know we're trying to say this, but is there a better way to write it?)
4:39 PM Step 2 - Verify the Zip archive
The previous step used more uppercase letters :)
4:41 PM must treat the value as null(i.e., not as empty string and not
as the text string null).
add a space between 'null' and '('
4:42 PM Configuration Defaults
this table uses column headers and footers, the other ones don't. (just noting)
4:43 PM must attempt to locate digital signatures for the widget (step ).
step number missing
4:44 PM So, for example, fr,en-us,en,en-au,en,fr,en would become
fr,en-us,en-au.
there should be an example of a tripple (zh-hans-cn)
7 minutes
4:52 PM me: ignore means that a user agent must act as if the element,
or fileis not present.
add a space between 'file' and 'is'
widgets spec
btw, don't forget the little people when you make the credits :) have a good vacation, sorry about the delays. all done :)
widgets feedback
Date: Thu, Jun 18, 2009 at 6:48 PM 6:36 PM me: (e.g., a user agent could use an array, or an object, or a hash map, etc.). drop each or 6:41 PM For each element in the elements list, if the element is one of the following: A preference element: doesn't mention readonly (this might be ok, or maybe not...) 6:48 PM 1. For each file name in the default start files table (from top to bottom) that has a media type that is supported by the user agent: 1. Let potential-start-file be the result of applying the rule for finding a file within a widget package to file name. 2. If potential-start-file is null or in error, ignore this file name and move onto the next file name in the default start files table. 3. If potential-start-file is a file, then: 1. Let widget start file be the value of potential-start-file. 2. Let start file content-type be the media type given in the media type column of the default start files table. 3. Terminate this algorithm and go to Step 9. I'm worried about the case where a package has two files: index.svg and index.xhtml. index.svg is 0 bytes and index.xhtml is a well formed xhtml file. The author developed this package using a user agent which doesn't support image/svg+xml and things worked well. A user unfortunately gets the widget and uses it with a user agent which does support image/svg+xml. I'm fairly certain what happens is that this process sends the user agent to step 9 with index.svg and the user ends up unhappy.
Re: File API Feedback
On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathana...@mozilla.com wrote: Hixie, I think a Base64 representation of the file resource may be sufficient, particularly for the image use case (which is how it is used already). Can you flesh out why the new schema is a good idea? so. I have folders with 100-1000mb of pictures in them. If I decide that I want to upload them all (Picasa style), i'd expect it would take a very long time to convert each file name into a base64 url. It sounds like part of the goal is to be able to retain references to files across crashes. As an example, I occasionally decide to upload the contents of stress (about 1000 images and 100mb iirc). The url for stress can be found in a bug report. 1. User visits uploader page 2. User selects the contents of an entire folder (stress) with a file picker 3. Browser provides relatively tiny urls which are opaque to the Web App for each of the files 4. Web App stores the opaque urls into localstorage 5. Web App asks for the data for the first couple urls 6. Web App starts showing previews and uploading files 7. As files are uploaded, webapp removes opaque urls from localstorage 8. Web app repeats 5-7 w/ other files from 4 9. Browser crashes; web app has uploaded say 100 items of my 1000 items 10. Browser restarts; web app is able to use localstorage and opaque urls to continue uploading the remaining 900 items. the requirements for such an opaque url are: a. that the browser retain a mapping to the real file paths b. that opaque urls the browser hasn't generated for a given web application not be usable by that web application one potential scheme: browser-file-reference://host.principle.example.com:port/opaque-sequence-number note that at this time, the web apps working group is trying to propose a widget: scheme, and the amount of push back web apps is getting from various groups is quite high. -- just something to keep in mind.
Widgets 1.0: Digital Signatures
Hi, apologies for the late comments. I hope all of my comments are of an editorial nature. The only one that might not be is the last one which is a question. http://dev.w3.org/2006/waf/widgets-digsig/ - I'm aware this is non normative: 1.4 Example CanonicalizationMethod Algorithm=http://www.w3.org/2006/12/xml-c14n11/ SignatureMethod Algorithm=http://www.w3.org/2001/04/xmldsig-more#rsa-sha256; / but..do we want to be consistent about trailing spaces before / ? - there are tabs here, which is inconsistent with the rest of the example: KeyInfo X509Data X509Certificate.../X509Certificate /X509Data /KeyInfo - 4 Locating and Processing Digital Signatures for the Widget 3. If the signatures list is not empty, sort the list of signatures by the file name field in ascending numerical order (e.g. signature1.xml followed by signature2.xml followed by signature3.xml etc). In Safari 4 beta, the paragraph has a blank paragraph between it and the 3. number, this differs from 6. - If the signatures list is not empty, sort the list of signatures by the file name field in ascending numerical order (e.g. signature1.xml followed by signature2.xml followed by signature3.xml etc). change xml etc to xml, etc. - 7.1 Common Constraints for Signature Generation and Validation 4. Every Signature Property required by this specification MUST be incorporated into the signature as follows: b. A widget signature MUST include a ds:Object element within the ds:Signature element. This ds:Object element MUST have an Id attribute that is referenced by a ds:Reference element within the signature ds:SignedInfo element. Why is Id written in mixed case? -
Re: Widgets 1.0: Digital Signatures
Why is Id written in mixed case? On Thu, Jun 4, 2009 at 4:44 PM, Thomas Roessler t...@w3.org wrote: That's a choice that was made in the original version of the XML Signature spec 7 years ago. gah. thanks, and i think i've actually asked about this before. oops. ok, retracted. sorry :) although, would it be unreasonable to add a note reminding people that it is mixed case and why? :)
Re: [widgets] Widgets URI scheme... it's baaaack!
On Wed, May 27, 2009 at 10:44 AM, Thomas Roessler t...@w3.org wrote: 2. Where does the requirement for query strings suddenly come from? I can't find it in the current editor's draft, and (beyond a side discussion with timeless) don't recall conversation about it. Basically web apps expect that window.location behave properly, if you use a scheme such as data: data:text/html,scriptalert(window.location.query%20?%20window.location.query%20:%20query is not supported)/script?%20Wouldn't%20it%20be%20nice? note that i can't do anything useful with this web app encoded as a data url because query is empty. Query based web apps are very common. Note: regrets for the next meeting, I'm traveling again.
Re: [widgets] Widgets URI scheme... it's baaaack!
On Wed, May 27, 2009 at 12:03 PM, Thomas Roessler t...@w3.org wrote: Just to be clear... The expectation you're talking about is that: 1. upon dereferencing, the query part is ignored I'm not specifically making this request, I believe in our unminuted discussion we talked about the potential to allow a script to handle mappings between URL and Resource. (Also note that HTML5 has at times talked about this sort of thing for Offline Apps.) In such a system, 1 wouldn't apply. However, yes, ignoring such a feature (or similar), the query part should be ignored. 2. when present, it's propagated into window.location.query Correct? it isn't just query that wants behavior, it's more the way that query is supposed to be filled (and certainly is for gecko) is that the object be a URL as opposed to simply a URI. http://mxr.mozilla.org/mozilla-central/source/netwerk/base/public/nsIURL.idl http://mxr.mozilla.org/mozilla-central/source/netwerk/base/public/nsIURI.idl http://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsStandardURL.cpp http://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsSimpleURI.cpp http://www.ietf.org/rfc/rfc2396.txt The URI syntax is dependent upon the scheme. In general, absolute URI are written as follows: scheme:scheme-specific-part ^ Simple (data:, telnet:,) v Generic (http:, hypothetical widget:) This generic URI syntax consists of a sequence of four main components: scheme://authoritypath?query From an implementation perspective, a hypothetical widget: needs to fall into nsStandardURL instead of nsSimpleURI, path must behave, query must behave, fragment should behave. In general host and other fields should also behave, as having them throw exceptions just to break applications doesn't seem helpful. To everyone else who wasn't involved in my discussion w/ tlr, I'm sorry, but the above is I believe one of the many items we discussed.
Re: [widgets] Draft Agenda for 28 May 2009 Voice Conference
regrets, i'm traveling (again, i seem to do this often these days)
