Re: [File API] Issue 182 about OperationNotAllowed
On Tue, 04 Oct 2011 00:59:18 +0200, Jonas Sicking jo...@sicking.cc wrote: Yup. I do wonder if we should introduce a DOMError class which can be reused in various cases which need APIs like this. IndexedDB could also use it and I seem to recall that HTML5 does too. I could certainly introduce a DOMError interface with a name and a message attribute. For the APIs that want to provide the same information asynchronous as they do synchronous through exceptions that makes sense. Would that work? OK. So it's when we need new exception codes, names, and types that the confusion with this model sets in. While we can add to DOMException in a decentralized way, do the editors of DOM4 intend to add the new exceptions to DOMException? I'll leave this one for Anne. I personally don't care where the new strings are defined. Anne seemed to prefer to do it in the DOM4 (aka DOM Core) spec, but I don't think we want to block on that happening. The idea I had was that everyone can introduce new strings. After all, as far as normative statements in a specification go, you need nothing more than this line: # Throw a SyntaxError exception On top of that my plan was that whenever a specification author introduces a string there that is not yet in DOM4 they send a request for it to be included and one of the DOM4 editors will add the exception and a brief description to the overview table. Having it in the overview table will help other editors choosing the appropriate string. Apart from making sure certain strings get their legacy code value assigned (already in the table) the table would be completely non-normative however and no specification introducing strings not yet in the table is blocked by it updating. It's just an overview. -- Anne van Kesteren http://annevankesteren.nl/
Re: Behavior Attachment Redux, was Re: HTML element content models vs. components
On Tue, Oct 4, 2011 at 12:38 PM, Ian Hickson i...@hixie.ch wrote:
* Any case of taking an element with existing semantics (e.g. a select
showing a list of countries) and replacing its presentation with
something completely different (e.g. a map selector), where the exact
binding could depend based on media queries (e.g. different UIs for
tablets vs TVs) or alternative style sheet selections (e.g. the user
picking a high-contrast view rather than a custom cool one).
Well for one we already have HTML elements that do more or less the same
(select vs. input type=radio, button vs. input type=button), so it
doesn't seem such a stretch to me to allow select vs. select
is=mapselect.
On a second note, what you essentially seem to demand is swapping out entire
HTML sub-branches based on presentation. It is IMHO not entirely a given
that it's components who have to fulfill this mechanism. IOW, components
could be seen as a neat, simple wrapping of a complex DOM structure under a
single element name (or binding attribute), and the task of switching out
different HTML trees (whether containing components or not) could be handled
by another, yet-to-be-specified mechanism. This incidentally would also
solve the security issue you mentioned in conjunction with CSS bindings.
On Mon, 3 Oct 2011, Roland Steiner wrote:
X-MYWIDGET
Pros:
- element name is inherently immutable
- can provide arbitrary API, can (but does not have to) derive from
arbitrary HTML element
- best performance (in instantiation, CSS selector matching)
I don't see why it would be more performant, can you elaborate on that?
Instantiation: for button is=mywidget I assumed there is a gap during
parsing when a button is instantiated, then later is expanded/replaced
when the is attribute is read. This may or may not be the case, though. In
any case, x-mywidget does not suffer from this.
CSS Selector matching: WebKit at least has a fast path for element names,
but not for attribute matches. So button[is=mywidget] { color: red; }
would be slower than x-mywidget { color: red; }. (The former also requires
up to 2 comparisons - attribute value and element name - besides.)
button IS=MYWIDGET
Pros:
- fallback behavior as per HTML element
- accessibility as per HTML element + shadow tree contents
- binding only at creation, or immediately thereafter
- API is that of host element, +alpha
Cons:
- add'l APIs ignored for accessibility
I'm not sure what this means. I would have thought the with-binding
accessibility would be at least as good as the x-foo case; better if you
bind to an element that already has some semantics and just augment them.
That's what I meant to say under Pros. It's the augmentations that are
ignored. But that's the case in all scenarios, so I shouldn't have singled
it out here.
button { BINDING: MYWIDGET; }
Pros:
- fallback behavior as if un-styled
- accessibility
- mutability depending on medium, etc.
- host element stays unchanged
Cons:
- dynamic binding is hard to implement
It doesn't have to be. In particular, now that we have the event loop
specified we can just specify how this works asynchronously.
- shadow DOM dependent on rendering tree (something we explicitly wanted
to avoid)
It's dependent on the style resolution, not the rendering tree.
Right, but the point still stands: We'd have a DOM tree hanging off (be
dependent on) something that isn't the DOM. This was the case previously in
WebKit before we started with the whole shadow DOM approach, and caused a
lot of headaches.
- unclear what happens if a HTML element with (intrinsic or explicit)
shadow DOM is assigned a CSS binding as well
It doesn't have to be unclear, it just has to be defined. There are two
obvious options: replace it, or augment it. XBL2 supported both.
TBH, XBL2's answer to multiple bindings felt rather hand-wavey to me - it
assumed that an arbitrary intrinsic order would work in all circumstances,
and that the various bindings wouldn't end up clobbering each other on
application.
Specifics aside, it's also a fundamental question how to address multiple
applicable CSS bindings that may be mutually exclusive - e.g., a layout
manager component gets both a vertical and horizontal layout binding
from different rules. For these reasons I would argue that replacing or
ignoring additional bindings is the only feasible way to go, but that OTOH
will easily lead to arbitrary results.
Cheers,
- Roland
Re: [File API] Issue 182 about OperationNotAllowed
On Mon, Oct 3, 2011 at 11:54 PM, Anne van Kesteren ann...@opera.com wrote: On Tue, 04 Oct 2011 00:59:18 +0200, Jonas Sicking jo...@sicking.cc wrote: Yup. I do wonder if we should introduce a DOMError class which can be reused in various cases which need APIs like this. IndexedDB could also use it and I seem to recall that HTML5 does too. I could certainly introduce a DOMError interface with a name and a message attribute. For the APIs that want to provide the same information asynchronous as they do synchronous through exceptions that makes sense. Would that work? Yup, that'd work. Another option which just occurred to me is to actually use DOMException objects. The ECMAScript error objects don't actually have anything exception specific about them. DOMException only does so by name of the interface. Either way is fine with me. / Jonas
Re: [indexeddb] Implicit Transaction Request associated with failed transactions
On Mon, Oct 3, 2011 at 7:59 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Sep 12, 2011 at 2:53 PM, Israel Hilerio isra...@microsoft.com wrote:
Based on previous conversations, it seems we've agreed that there are
situations in which a transaction could failed independent of explicit
requests (i.e. QUOTA_ERR, TIMEOUT_ERR). We believe that this can be
represented as an implicit request that is being triggered by a transaction.
We would like to add this concept to the spec. The benefit of doing this
is that it will allow developers to detect the error code associated with a
direct transaction failure. This is how we see the concept being used:
trans.onerror = function (e) {
//eventTarget is mapped to an implicit transaction that was created behind
the scenes to track the transaction
if (e.eventTarget.errorCode === TIMEOUT_ERR) {
// you know the transaction error because of a timeout problem
}
else if (e.eventTarget.errorCode === TIMEOUT_ERR) {
// you know the transaction error because of a quota problem
}
}
Our assumption is that the error came not from an explicit request but from
the transaction itself. The way it is today, the e.eventTarget will not
exists (will be undefined) because the error was not generated from an
explicit request. Today, eventTargets are only populated from explicit
requests.
Good catch!
We had a long thread about this a while back with the subject
[IndexedDB] Reason for aborting transactions. But it seems to have
fizzled with no real conclusion as to changing the spec. In part that
seems to have been my fault pushing back at exposing the reason for a
aborted transaction.
I think I was wrong :-)
I think I would prefer adding a .errorCode on IDBTransaction through
(or .errorName or .error or whatever we'll end up changing it to).
This seems more clear than creating a implicit request object. It'll
also make it easy to find the error if you're outside the error
handler. With the implicit request, you have no way of getting to the
request, and thus the error code, from code outside the error handler,
such from code that looks at the transaction after it has run.
And the code above would work exactly as is!
Let me know what you think?
In detail, here is what I suggest:
1. Add a .errorCode (or .errorName/.error) property on
IDBTransaction/IDBTransactionSync.
2. The property default to 0 (or empty string/null)
3. In the Steps for aborting a transaction add a new step between
the current steps 1 and 2 which says something like set the errorCode
property of vartransaction/var to varcode/var.
This way the reason for the abort is available (through the
transaction) while firing he error event on all still pending
requests in step 2. The reason is also available while firing the
abort event on the transaction itself.
/ Jonas
Reminder: RfC: LCWD of Touch Events version 1; deadline October 11
On 9/13/11 1:32 PM, ext Arthur Barstow wrote: On September 13, the Web Events WG published a LCWD of the Touch Events version 1 spec: http://www.w3.org/TR/2011/WD-Touch-Events-20110913/ That WG explicitly asked the WebApps WG for comments. Individual WG members are encouraged to provide individual feedback directly to the Web Events WG. If you have comments, please send them to the following list by October 11: public-webeve...@w3.org@w3.org http://lists.w3.org/Archives/Public/public-webevents/ If anyone in WebApps wants to propose an official WG response, please do so ASAP, in reply to this email so the WebApps WG can discuss it. -AB
Re: [File API] Issue 182 about OperationNotAllowed
On 10/4/11 2:54 AM, Anne van Kesteren wrote: On Tue, 04 Oct 2011 00:59:18 +0200, Jonas Sicking jo...@sicking.cc wrote: Yup. I do wonder if we should introduce a DOMError class which can be reused in various cases which need APIs like this. IndexedDB could also use it and I seem to recall that HTML5 does too. I could certainly introduce a DOMError interface with a name and a message attribute. For the APIs that want to provide the same information asynchronous as they do synchronous through exceptions that makes sense. Would that work? Works for me :-) Happy to work with you to introduce DOMError in DOM4; seems pretty straightforward and as soon as it is in, I'll refer to it. OK, it's time to bid a fond farewell to FileException and FileError if that's the way we're doing exceptions from this day forward. OK. So it's when we need new exception codes, names, and types that the confusion with this model sets in. While we can add to DOMException in a decentralized way, do the editors of DOM4 intend to add the new exceptions to DOMException? I'll leave this one for Anne. I personally don't care where the new strings are defined. Anne seemed to prefer to do it in the DOM4 (aka DOM Core) spec, but I don't think we want to block on that happening. The idea I had was that everyone can introduce new strings. After all, as far as normative statements in a specification go, you need nothing more than this line: # Throw a SyntaxError exception On top of that my plan was that whenever a specification author introduces a string there that is not yet in DOM4 they send a request for it to be included and one of the DOM4 editors will add the exception and a brief description to the overview table. Having it in the overview table will help other editors choosing the appropriate string. Apart from making sure certain strings get their legacy code value assigned (already in the table) the table would be completely non-normative however and no specification introducing strings not yet in the table is blocked by it updating. It's just an overview. OK, this works for me. -- A*
Re: Fwd: W3C Workshop on the Future of Offline Web Applications (Call for Participation)
The deadline for Position Papers is now October 12. On 9/9/11 5:09 PM, ext Arthur Barstow wrote: Speaking of application caches and widgets, below is an announcement about a Future of Offline Web Applications workshop on Saturday November 5 in Redwood City CA US: http://www.w3.org/2011/web-apps-ws/ Position Papers are due September 30. Original Message Subject: Join the W3C Workshop on the Future of Offline Web Applications (Call for Participation) Date: Fri, 9 Sep 2011 20:16:07 + From: Ian Jacobs i...@w3.org Dear Advisory Committee Representative, W3C is pleased to announce an upcoming Workshop: The Future of Offline Web Applications 5 November 2011 Redwood City, CA, USA Hosted by Vodafone http://www.w3.org/2011/web-apps-ws/ The Web has rapidly evolved into a platform suitable for applications that exhibit a level of richness and interaction that could barely be envisioned 20 years ago. Word processors, email clients, navigation systems, and games are just a small sample of applications that are now a regular part of the Web experience, but there are many types of applications that are difficult to produce using Web technologies. In order to facilitate these complex applications move into the Web, additional functionality is required from the Open Web Platform. Off-line use of Web applications is one of the key missing elements from the Web platform that application developers require. The current fragmentation in this solution space is creating confusion among would-be WebApp developers and organizations who would otherwise invest in the Open Web Platform. The goal of this workshop is to identify a clear path forward for innovation in the Open Web Platform related to offline Web application invocation and use. More background information for this Workshop is available: http://www.w3.org/2011/web-apps-ws/#cfp_background If you have any questions, please contact the chairs: Daniel Appelquistdaniel.appelqu...@vodafone.com and Matt Womerm...@w3.org. This announcement follows section 9 of the Process Document: http://www.w3.org/2005/10/Process-20051014/events#GAEvents Ian Jacobs, Head of W3C Communications -- Important Dates 9 September: Call for Participation 30 September: Deadline for position papers 15 October: Program released 28 October: Deadline for Registration 5 November: Workshop -- Requirements for Participation Participation will be governed by the following: - To ensure maximum interaction among participants, the number of participants will be limited to two from one company. - W3C membership is not required to participate in this workshop. - Attendees are required to submit a Position Paper by email toteam-uwa-rev...@w3.org by 30 September For details on Position Paper and Statement of Interest, see: http://www.w3.org/2011/web-apps-ws/#cfp_participationRequirements -- Ian Jacobs (i...@w3.org)http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447
Re: Adding Web Intents to the Webapps WG deliverables
Circling back to the original topic, it seems like there's a good amount of interest and opinions, and that the spec would probably benefit from the input of the people in this WG, especially since multiple platforms are all shipping something similar in approach (android intents, contracts in win8 and whatever implication that has for Metro/IE, and the proposed web intents). This is good to see. -Ian On Thu, Sep 29, 2011 at 11:34 AM, Charles Pritchard ch...@jumis.com wrote: Top posting: in web messaging, we typically set an origin property on events and authors are expected to check that property. Are your concerns addressed by that practice? It is an added step, an added nuance. And developers may neglect it. But, if they are neglecting origin, they are just plain leaving security holes. On Sep 28, 2011, at 12:09 PM, Adrienne Porter Felt a...@berkeley.edu wrote: Android developers chronically misunderstand and misuse Android Intents, and these mistakes lead to security bugs. To illustrate how prevalent the confusion is, Erika Chin and I found that 9 of 20 popular Android apps (45%!) contain security vulnerabilities due to misusing Intents. I've also found these same types of bugs in Google-produced Android applications (the default ones that ship as built-in apps). I posted examples details of two real-world applications that exhibit these vulnerabilities: http://www.adrienneporterfelt.com/blog/?p=313 http://www.adrienneporterfelt.com/blog/?p=313. It's my hope that Web Intents can be designed to prevent developers from making the same mistakes. There are two common types of errors: 1) Android Intents can be used for both inter- and intra-application communication, and developers don't know the difference. A canonical accident occurs when a developer creates a unique action string like foo.bar.xyz and uses it for internal communication. The problem is that any other application can register for the same action string, even if it's supposedly hard to guess. This introduces two security bugs. (1) The component that receives foo.bar.xyz has been unintentionally made public, since anyone can send that action string to it. (2) Another application could register to receive foo.bar.xyz and steal any data associated with it, or simply gain the user's attention away from the original app. 2) The Android OS sends Intents to applications as notifications. Developers register components to receive these system Intents. By default, registering for a system Intent makes a component public. Developers don't realize that these components become public by default, so they don't check that the Intent was really sent by the OS. I have two suggestions to prevent these same errors from appearing in Web Intents: 1) Developers need to be discouraged from using Web Intents for internal application communication. One way to do this is to make it so that Web Intents are only delivered after the user selects a service in a browser popup window. (Nothing hidden in the background!) This would be annoying for intra-application communication, so I think developers would avoid it. 2) If a developer registers to receive a Web Intent from the browser (like for a system notification), that component should NOT be invocable by any other application unless it's registered for a second Intent as well. Adrienne
[Bug 13794] I think length-prefixed messages would be a lot more useful than line-delimited messages. Sentinel terminators, especially newlines, are more error prone to generate and parse than a few
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13794 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||WONTFIX --- Comment #2 from Ian 'Hixie' Hickson i...@hixie.ch 2011-10-04 18:36:09 UTC --- EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: It's a text format. Text formats are commonly delimited on newlines. As Anne says, if there's a use case for binary blobs, we can add that feature in the future. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 13910] There can never be no active range
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13910 Aryeh Gregor a...@aryeh.name changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 13908] WordStar semantics aren't supported
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13908 Aryeh Gregor a...@aryeh.name changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 13913] Attributes don't have an order
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13913 Aryeh Gregor a...@aryeh.name changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 13812] The EventSource garbage collection does not mention open/error events. It also does not seem to match the language entirely of WebSocket garbage collection.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13812 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||FIXED --- Comment #2 from Ian 'Hixie' Hickson i...@hixie.ch 2011-10-04 19:56:02 UTC --- Not matching the language isn't a big deal; they have different behaviour. I've fixed the other thing though. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 14248] Merge selection spec into editing spec
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14248 Aryeh Gregor a...@aryeh.name changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Aryeh Gregor a...@aryeh.name 2011-10-04 20:14:45 UTC --- Done: http://dvcs.w3.org/hg/editing/rev/197e383926ac Now we should replace the DOM Range spec with a pointer to DOM4 and the editing spec. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 14383] New: Investigate interaction between focus and selection
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14383 Summary: Investigate interaction between focus and selection Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: HTML Editing APIs AssignedTo: a...@aryeh.name ReportedBy: rn...@webkit.org QAContact: sideshowbarker+html-editing-...@gmail.com CC: m...@w3.org, public-webapps@w3.org Right now interactions between focus and selection are UA-dependent. Maybe it should stay that way but it's worth investigating. e.g. WebKit automatically focuses the element with selection when the user types, moves caret, etc... whereas Trident and Gecko moves selection to wherever focus is. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[From-Origin] editorial
Anne, editorial comment. in http://www.w3.org/TR/from-origin/#introduction document on http://example.org can embed an image from http://corp.invalid without issue. to be replaced by document on http://example.org can embed an image from http://corp.example.com/ without issue. -- Karl Dubost - http://dev.opera.com/ Developer Relations Tools, Opera Software
Re: [From-Origin] on privacy leakage
Anne, Glenn, Le 3 oct. 2011 à 05:07, Anne van Kesteren a écrit : On Sat, 23 Jul 2011 16:49:38 +0200, Glenn Adams gl...@skynav.com wrote: The description of privacy leakage doesn't elaborate the issue sufficiently. I'd suggest adding a reference to a more complete, external document that discusses this in detail. It seems pretty clear to me. Any suggestions? in http://www.w3.org/TR/from-origin/#introduction Suggestion for rewriting privacy leakage: Privacy leakage — Web sites often provide services depending on third party Web sites (such as social network sign-in for commenting). These systems are storing credentials using cookies. It makes it possible to trigger the download of certain resources from the 1st party Web site. With this mechanism, the third party Web sites can gain knowledge on which first party Web site the visitor is signed on. -- Karl Dubost - http://dev.opera.com/ Developer Relations Tools, Opera Software
[Bug 14384] New: upgradeneeded event should set request.readyState to DONE
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14384 Summary: upgradeneeded event should set request.readyState to DONE Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: dave.n...@w3.org ReportedBy: bent.mozi...@gmail.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org upgradeneeded event should set request.readyState to DONE, otherwise we will throw an exception getting request.result. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 13856] I am not sure whether it is due to the nature of this documentation but it would be very helpful to include an example of HTTP response and how it should react to HTTP 3xx and 4xx.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13856 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||FIXED --- Comment #1 from Ian 'Hixie' Hickson i...@hixie.ch 2011-10-04 23:36:20 UTC --- EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: I added a paragraph to talk about useful response codes; is that sufficient? If not, can you elaborate on what you would like to see? Thanks! -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
