Re: Input events, checkboxes and radio buttons
On Sat, Jun 20, 2009 at 3:43 AM, Anne van Kesterenann...@opera.com wrote: On Sat, 20 Jun 2009 12:35:16 +0200, Anne van Kesteren ann...@opera.com wrote: The input event does not apply to radio/checkbox. (This is stated in the radio/checkbox sectons.) Probably a carry-over from WF 2.0, which did have oninput firing for checkboxes. Having said that, the change event does apply and it is not stated there that it is also dispatched when the checkedness flag changes. What does that mean? Changes to the input's checked state do not trigger change events to fire. Did you mean that you want a change event to fire when the checked state changes? I hope not, because that would contradict HTML 4, DOM Events, and what browsers do. Garrett
Re: WebIDL extension proposal for [Enumerable] interface attribute
Hi Cameron,
2009/7/13 Cameron McCormack c...@mcc.id.au:
Cameron McCormack:
Do you need to specify that some of the optional attributes are
enumerable while others aren’t? Or should all of the optional
attributes be enumerable?
Anselm R Garbe:
We only need to specify that all (optional) attributes are enumerable,
so basically that means we need something that says all attributes of
this interface are enumerable, including the optional ones.
How about syntax like the following:
dictionary interface GenericDictionary {
};
dictionary interface FileMetadata {
readonly attribute long size;
readonly attribute Date creation;
readonly attribute Date modification;
};
dictionary interface ExtendedFileMetadata : FileMetadata {
attribute boolean readable;
attribute boolean writable;
attribute boolean executable;
};
where:
* Dictionary interfaces cannot declare any constants or operations.
* Dictionary interfaces can inherit only from other dictionary
interfaces.
* In ES, there are no interface prototype objects for dictionary
interfaces and thus don’t affect the prototype chain.
* Attributes are always effectively optional.
* Attributes are exposed as properties on the host object, just like
with regular interfaces.
* Entries in a dictionary interface that don’t correspond to the
attributes declared on them are also exposed as properties on the
host object in ES, and are enumerable (unlike corresponding named
properties for regular interfaces).
* Dictionary interfaces are implicitly [Callable,NoInterfaceObject].
[OverrideBuiltins] could be used, which would make dictionary
lookups take precedence over other property lookups, as with
regular interfaces with getters.
* Dictionary keys are always DOMStrings.
* A “dictionary” (an object that implements one or more dictionary
interfaces) can be designated as “not extensible”, which means
effectively the same thing as not having a creator on a regular
interface.
* An entry in a dictionary can be designed as “read only”, which
means that assigning to it or attempting to remove it will fail
(ignored in ES, exception thrown in Java). Explicit attributes are
designed as read only as with regular interfaces, by using the
readonly keyword.
* In Java, any dictionary interface would correspond to the
java.util.MapString,Object interface.
Yes, I'm happy with this proposal, it would provide good syntactical
support for declaring such dictionary interfaces.
Kind regards,
Anselm
Re: WebIDL extension proposal for [Enumerable] interface attribute
2009/7/13 Cameron McCormack c...@mcc.id.au: Cameron McCormack: * Entries in a dictionary interface that don’t correspond to the attributes declared on them are also exposed as properties on the host object in ES, and are enumerable (unlike corresponding named properties for regular interfaces). Ian Hickson: Could you elaborate an what this means? Corresponding named properties are currently specced to be DontEnum. (But corresponding indexed properties are enumerable.) In the above proposal, properties that are reflecting dictionary entries would be enumerable. * Dictionary interfaces are implicitly [Callable,NoInterfaceObject]. [OverrideBuiltins] could be used, which would make dictionary lookups take precedence over other property lookups, as with regular interfaces with getters. What's the difference between a dictionary lookup and other property lookups? Sorry, poor choice of wording. By dictionary lookup I just mean doing a normal [[Get]] with a name that is that name of a property that corresponds to a dictionary entry. So there’s no difference from named properties, here. Cameron McCormack: * A “dictionary” (an object that implements one or more dictionary interfaces) can be designated as “not extensible”, which means effectively the same thing as not having a creator on a regular interface. Ian Hickson: In ES, any object has a creator even if it's not explicitly listed, it just doesn't do anything from the host's perspective. [...] Is this different here? Cameron McCormack: Hadn’t thought of that yet. I suppose I would make it not different (i.e., trying to [[Put]] a property that doesn’t exist would succeed and not affect the underlying dictionary). Does succeed mean that a sub-sequent [[Get]] for such a property will return the value? And does not affect the underlying dictionary effect the enumerability of such properties? Basically I don't mind how [[Put]] is dealt with, since that's apart from the use cases I'm trying to solve, but of course it needs to be specified. Kind regards, Anselm
Re: Do we need to rename the Origin header?
Ian Hickson wrote on 7/14/2009 12:49 AM: (Trimmed cc list to avoid cross-posting.) On Thu, 25 Jun 2009, Bil Corry wrote: Thanks for the clarification. Will there be some mechanism within HTML5 to denote links that are privacy-sensitive versus those that are not? I'm imagining that by default, links to external resources would be considered private unless denoted as public (non-private?). I have no plans to add such a feature at this time, but I suppose if Sec-From becomes popular, we could add it at some future point, sure. The Sec-From draft relies on the adopter to define what constitutes privacy-sensitive -- will you be adding this definition to HTML5? - Bil
[DOM3Events] Action-375 Guiding Principles Thoughts
http://www.w3.org/2008/webapps/track/actions/375 As part of this action, I've taken two approaches to answer the question: what are the guiding principles for event usage? 1. Circumstances when an author would use an event 2. Principles behind when a new feature should consider creating an event #1 is a bit nebulous-but here's my take on it: Authors should use events in scenarios where a web app needs to respond (take an action) in response to a user's action. Generally this happens in relation to user-input, either from directing a mouse at the web app, entering keys on a keyboard (or virtual input surface), voice commands, or other forms of input. Appropriate events have been created (or are defined by this specification) that allow authors to detect and respond to these user-inputs. Other events exist that are designed to proactively notify the author when the state of the application changes. Such events are generally also related to user-inputs, such as a user first navigating to a page, which triggers parsing of HTML, which then triggers DOMContentLoaded (for example) to fire. Another example is the end-user navigating away from a web app (in user-agents where that scenario makes sense), where an unload event is triggered. Another class of events act as confirmation events; they confirm that a state change occurred. Unlike the other events mentioned, these events may not originate from a user-action, but rather from an action taken by program code. Mutation events are such an example. Event types of this class exist not necessarily for the web app author, but rather for extension code written by third parties that does not have an intrinsic knowledge of the author's program code. Naturally, the web app author's program code knows (or should know?) the implications of running its code, therefore it has no need of confirmation events. However, extension code does not necessarily know all the implications of the program code that hosts it; yet it needs to be aware of document state and thus depends upon confirmation events to respond to changes and update its internal state. For this reason, confirmation events generally have a negative performance impact on a web app. Web app authors should use events when responding to user-input as mentioned above. Additionally, authors of extension code (here meaning general-purpose program code written to be hosted inside of a web app) may make use of confirmation events to track and respond to document state changes. #2 is highly correlated with the first principle: This specification (or future event specifications) should define events for common scenarios taken by end-users when interacting with a web app. Such events should include (but not be limited to): mouse interaction, keyboard (and virtual keyboard) interaction, voice interaction, touch interaction, etc. Convenience events should also be specified which allow a web application to respond to common user actions within the categories previously listed. Such convenience events include, for example: reset events (for button clicks on a reset form button), focus and blur events, zoom events, editing events. This specification may also include confirmation events as described earlier. Care should be taken to ensure that confirmation events are specified in a way that ensures that they can be triggered in a scoped, performance-neutral way. Note that due to traditional event registration techniques (e.g., addEventListener), confirmation events in general may be better suited to a different registration model than other events.
[Bug 7104] New: Disagreement on handling of null value for localStorage.setItem()
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7104 Summary: Disagreement on handling of null value for localStorage.setItem() Product: WebAppsWG Version: unspecified Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P2 Component: Web Storage AssignedTo: i...@hixie.ch ReportedBy: br...@python.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Created an attachment (id=718) -- (http://www.w3.org/Bugs/Public/attachment.cgi?id=718) test page that shows what localStorage.getItem() thinks null should be In Safari 4, if you use null as a value when setting a new key it will end up returning the string null. But in Firefox 3.5, you get back null itself. I have attached a dead-simple HTML file that shows the differences when run in the two browsers. Not sure who is right since the spec says a DOMString is expected and I am not sure if null is considered a valid DOMString. And in both browsers you end up with a key being set. While in Safari that makes sense since you are getting back a string, but in Firefox that's confusing as the value for the key is the same as the value used to signify that no value exists for the key. That means in Firefox the only way to know that the key is actually set explicitly to null is to iterate through all the keys using localStorage.key() to try to see if the key has actually been given a value. -- 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.
Re: Do we need to rename the Origin header?
On Tue, 14 Jul 2009, Bil Corry wrote: Ian Hickson wrote on 7/14/2009 12:49 AM: (Trimmed cc list to avoid cross-posting.) On Thu, 25 Jun 2009, Bil Corry wrote: Thanks for the clarification. Will there be some mechanism within HTML5 to denote links that are privacy-sensitive versus those that are not? I'm imagining that by default, links to external resources would be considered private unless denoted as public (non-private?). I have no plans to add such a feature at this time, but I suppose if Sec-From becomes popular, we could add it at some future point, sure. The Sec-From draft relies on the adopter to define what constitutes privacy-sensitive -- will you be adding this definition to HTML5? HTML5 will say whatever Adam tells me it should say once the draft is stable. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [Bug 7104] New: Disagreement on handling of null value for localStorage.setItem()
On Tue, Jul 14, 2009 at 12:41 PM, bugzi...@farnsworth.w3.org wrote: http://www.w3.org/Bugs/Public/show_bug.cgi?id=7104 Summary: Disagreement on handling of null value for localStorage.setItem() Product: WebAppsWG Version: unspecified Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P2 Component: Web Storage AssignedTo: i...@hixie.ch ReportedBy: br...@python.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Created an attachment (id=718) -- (http://www.w3.org/Bugs/Public/attachment.cgi?id=718) test page that shows what localStorage.getItem() thinks null should be In Safari 4, if you use null as a value when setting a new key it will end up returning the string null. But in Firefox 3.5, you get back null itself. I brought this issue up on WhatWG.org a while ago. I'm pretty sure Safari is right. I have attached a dead-simple HTML file that shows the differences when run in the two browsers. Not sure who is right since the spec says a DOMString is expected and I am not sure if null is considered a valid DOMString. And in both browsers you end up with a key being set. While in Safari that makes sense since you are getting back a string, but in Firefox that's confusing as the value for the key is the same as the value used to signify that no value exists for the key. That means in Firefox the only way to know that the key is actually set explicitly to null is to iterate through all the keys using localStorage.key() to try to see if the key has actually been given a value. Exactly. Someone should file a bug on Firefox.
