[Bug 11117] New: this is a test message
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7 Summary: this is a test message Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#pos ting-messages OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Web Messaging (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#posting-messages Comment: this is a test message Posted from: 116.3.14.200 -- 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: Can we remove forminput and formchange events and related dispatch methods?
I agree with Erik, the generic feature probably is not worth the simple use case. It can (and probably should) be easily implemented by the developer in his form logic when needed. Sergey/ On 21 October 2010 22:56, Erik Arvidsson wrote: > The forminput and formchange events are dispatched on all resettable > elements in a form when any element associated with the form > dispatches an input or a change event. > > Is this case really worth the cost of increasing the size of the API > when it can easily be achieved with capturing events? > > erik > >
Re: Can we remove forminput and formchange events and related dispatch methods?
On Fri, 22 Oct 2010 10:55:24 +0200, Sergey Ilinsky wrote: I agree with Erik, the generic feature probably is not worth the simple use case. It can (and probably should) be easily implemented by the developer in his form logic when needed. Yeah, I don't mind moving these features to libraries. Anyone implemented them apart from Opera? -- Anne van Kesteren http://annevankesteren.nl/
Re: Use cases for Range::createContextualFragment and script nodes
On Thu, 21 Oct 2010 08:43:18 +0200, Maciej Stachowiak wrote: It should probably be added to a spec at some point. Perhaps Web DOM Core could be expanded to cover Range & Tranversal? There is: http://bitbucket.org/ms2ger/dom-range I am not sure if it is a good idea to put Range into DOM Core. Range probably means doing Selection too and that is quite far away from what DOM Core is about. -- Anne van Kesteren http://annevankesteren.nl/
[Bug 10584] toString does not represent what WebKit and Mozilla do, which is to return only the text within the selection that is visible to the user.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10584 Ms2ger changed: What|Removed |Added Status|RESOLVED|VERIFIED CC||ms2...@gmail.com, ||public-webapps@w3.org Component|pre-LC1 HTML5 spec (editor: |DOM Range |Ian Hickson)| AssignedTo|i...@hixie.ch|dave.n...@w3.org Product|HTML WG |WebAppsWG QAContact|public-html-bugzi...@w3.org |member-webapi-...@w3.org -- 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: ISSUE-152: [widgets] P&C test suite needs a few more XML entity cases to check for well-formed XML
On Tue, Oct 19, 2010 at 6:28 PM, Web Applications Working Group Issue Tracker wrote: > > ISSUE-152: [widgets] P&C test suite needs a few more XML entity cases to > check for well-formed XML > > http://www.w3.org/2008/webapps/track/issues/152 > > Raised by: > On product: Added new tests to test suite: # lt Tests support of XML, by making sure the user agent treats < as malformed XML. To pass, the user agent must treat this as an invalid widget. http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-klLDaEgJeU/004/lt.wgt # amp (download, files) Tests support of XML, by making sure the user agent treats & as malformed XML. To pass, the user agent must treat this as an invalid widget. http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-klLDaEgJeU/005/amp.wgt -- Marcos Caceres Opera Software ASA, http://www.opera.com/ http://datadriven.com.au
[Bug 11117] this is a test message
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7 Anne changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #6 from Anne 2010-10-22 14:57:37 UTC --- ffs -- 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: Can we remove forminput and formchange events and related dispatch methods?
On Oct 22, 2010 2:00 AM, "Anne van Kesteren" wrote: > Yeah, I don't mind moving these features to libraries. Anyone implemented > them apart from Opera? Neither WebKit nor Gecko implements it: https://bugs.webkit.org/show_bug.cgi?id=26141 https://bugzilla.mozilla.org/show_bug.cgi?id=605997 IE9 beta does not have it either. -- erik
Re: Can we remove forminput and formchange events and related dispatch methods?
On Fri, Oct 22, 2010 at 11:15 AM, Erik Arvidsson wrote: > On Oct 22, 2010 2:00 AM, "Anne van Kesteren" wrote: >> Yeah, I don't mind moving these features to libraries. Anyone implemented >> them apart from Opera? > > Neither WebKit nor Gecko implements it: > > https://bugs.webkit.org/show_bug.cgi?id=26141 > https://bugzilla.mozilla.org/show_bug.cgi?id=605997 > > IE9 beta does not have it either. This means that we should also remove dispatchFormInput/dispatchFormChange from the HTML5 spec, right? / Jonas
Re: Can we remove forminput and formchange events and related dispatch methods?
On Fri, Oct 22, 2010 at 12:09, Jonas Sicking wrote: > This means that we should also remove > dispatchFormInput/dispatchFormChange from the HTML5 spec, right? That was my intention and the subject hints at that. Sorry for not including it in the body as well. -- erik
[Bug 11104] [IndexedDB] removeObjectStore/Index should be renamed to delete___
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11104 Jonas Sicking changed: What|Removed |Added Status|NEW |RESOLVED CC||jo...@sicking.cc Resolution||FIXED --- Comment #1 from Jonas Sicking 2010-10-22 21:53:42 UTC --- I also rename IDBDatabase.objectStores to IDBDatabase.objectStoreNames to match IDBObjectStore.indexNames as well as be more descriptive. -- 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 10304] Rename "remove" method on object store to "delete"
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10304 Jonas Sicking changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- 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: Can we remove forminput and formchange events and related dispatch methods?
On Fri, 22 Oct 2010 21:31:32 +0200, Erik Arvidsson wrote: On Fri, Oct 22, 2010 at 12:09, Jonas Sicking wrote: This means that we should also remove dispatchFormInput/dispatchFormChange from the HTML5 spec, right? That was my intention and the subject hints at that. Sorry for not including it in the body as well. Can you file a bug against HTML5? I'll see about getting it removed from Opera. -- Anne van Kesteren http://annevankesteren.nl/
[IndexedDB] IDBKeyRange cleanup
Hi all,
IDBKeyRange is in need of some cleanup. The first issue is its
constructors. Currently the IDL for IDBKeyRange, define that the
constructors, .only, .leftBound, .rightBound, .bound, on object
instances themselves. I don't think this is intentional since first of
all it makes it impossible to create the first IDBKeyRange, second,
second it seems strange to have constructor functions on instances.
It seems like the intent is that the following should work:
x = new IDBKeyRange.bound(...);
and possibly also
x = IDBKeyRange.bound(...);
(the latter works for for example XMLHttpRequest, JS-heads have also
informed me that it should work).
Unfortunately there is no way to express this in WebIDL, so I think we
need to describe it in prose instead. I'll raise this with Cameron,
but I think that since at this point only IndexedDB uses these
"static" functions, it might not make sense to add support to WebIDL.
The other thing is that the .flags attribute is really not very
javascript friendly as it uses bitfields. It also is weird in that it
has multiple bits, but some have strong interdependencies. For example
if SINGLE is set LEFT_OPEN and RIGHT_OPEN must be false, and
LEFT_BOUND and RIGHT_BOUND must be true. It also seems like the
LEFT_BOUND flag is closely correlated to the .left property.
I suggest the following API instead:
interface IDBKeyRange {
readonly attribute any left;
readonly attribute any right;
readonly attribute boolean leftOpen;
readonly attribute boolean rightOpen;
};
the .left and .right properties return 'null' or 'undefined' (to be
discussed) when the keyrange isn't bound in that direction.
Another question I had is if "left" and "right" really are good names.
Seems to me that "upper" and "lower" are better words, but it might be
that left/right is established concepts in the database community? I
don't feel strongly on this issue. Oh, I see now that bug 10397 is
filed on this exact issue.
Lastly, should we allow values to be passed directly to all APIs that
currently take IDBKeyRanges? It seems nice to not require people to
create an IDBKeyRange object using patterns like:
req = objectStore.openCursor(new IDBKeyRange.only(foo));
and instead allow
req = objectStore.openCursor(foo);
Similarly, should we allow IDBObjectStore.get on and IDBIndex.get to
take a IDBKeyRange and return the first value that matches the
keyrange. This would allow things like "give me the first entry with a
value greater than X".
/ Jonas
