On May 22, 2014, at 1:52 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, May 1, 2014 at 5:31 PM, Ben Peters ben.pet...@microsoft.com wrote:
Proposal
To make this simpler for sites, frameworks, and browsers, it makes sense to
enable a new, simpler version of contentEditable that provides
On May 27, 2014, at 1:33 AM, Robin Berjon ro...@w3.org wrote:
On 27/05/2014 01:47 , Ben Peters wrote:
-Original Message- From: Robin Berjon
On 26/05/2014 05:43 , Norbert Lindenberg wrote:
Were any speakers of bidirectional languages in the room when
this was discussed?
I don't
On May 23, 2014, at 1:37 PM, Robin Berjon ro...@w3.org wrote:
On 23/05/2014 21:32 , Jonas Sicking wrote:
On Fri, May 23, 2014 at 4:43 AM, Robin Berjon ro...@w3.org wrote:
On 23/05/2014 12:28 , Jonas Sicking wrote:
And on mobile autocorrect of misspelled words is common, though that
can
Can this be an attribute on elements instead? Otherwise, browsers would have
to repeatedly call these functions to update edit menu, etc...
Also, we should talk with people working on Indie UI
(http://www.w3.org/WAI/IndieUI/). The problem we're solving here is very
similar to the one they're
On May 27, 2014, at 2:56 AM, Robin Berjon ro...@w3.org wrote:
On 27/05/2014 09:19 , Piotr Koszuliński wrote:
Yes, it should be possible to disable whichever feature you don't need.
In some cases you don't need lists (because e.g. you're editing a text
that will become a content of a
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25914
Anne ann...@annevk.nl changed:
What|Removed |Added
Status|RESOLVED|REOPENED
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25915
Anne ann...@annevk.nl changed:
What|Removed |Added
Status|RESOLVED|REOPENED
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25987
Bug ID: 25987
Summary: Blob URL parsing / fetching model
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Dimitri,
Thank you for your excellent reply.
As you mention the dependency resolution properties are also available
in ES6 modules.
I feel there is a case to be made for ES6 modules being used for any
resource type loading.
e.g.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25994
Bug ID: 25994
Summary: invalid extended attribute list syntax
Product: WebAppsWG
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity:
From: Ryosuke Niwa [mailto:rn...@apple.com]
Can this be an attribute on elements instead? Otherwise, browsers would
have to repeatedly call these functions to update edit menu, etc...
This may be an issue, I agree. But since it's dynamic and changes every time
the selection/caret moves,
On 6/5/14 1:42 PM, Ben Peters wrote:
From: Ryosuke Niwa [mailto:rn...@apple.com]
Can this be an attribute on elements instead? Otherwise, browsers would
have to repeatedly call these functions to update edit menu, etc...
This may be an issue, I agree. But since it's dynamic and changes every
Playing with Promise wrappers for IDB, the intersection of IDBTransaction's
|active| state and microtask execution came up. Here are a couple of
interesting cases:
case 1:
var tx;
Promise.resolve().then(function() {
tx = db.transaction(storeName);
// tx should be active here...
On Thu, 5 Jun 2014, Joshua Bell wrote:
For case 2, it looks like implementations differ on whether microtasks
are run as part of the event dispatch. This seems to be outside the
domain of the IDB spec itself, somewhere between DOM and ES. Anyone want
to offer an interpretation?
Event
Hi Joshua, IDB folks,
I was about to wrap up work on a small app that uses IDB but to my absolute
surprise it looks that the number of indexed values in a MultiEntry index
is limited to 50. Maybe it's not meant to contain an infinite number but 50
seems small and arbitrary. Why not 4096?
The spec has no such limitation, implicit or explicit. I put this together:
http://pastebin.com/0GLPxekE
In Chrome 35, at least, I had no problems indexing 100,000 tags. (It's a
bit slow, though, so the pastebin code has only 10,000 by default)
You mention 50 items, which just happens to be how
You are correct:
A case of BROKEN debugging tool (Chrome Web Console in Chrome 35) and a
typo that produced no error (I had e.target.cursor instead of
e.target.result)
If the debugger is broken (I realize it's been fixed now) it makes it hard
to tell weather the bug is in my code or in the
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26001
Bug ID: 26001
Summary: [Shadow]: The type of arguments of
ShadowRoot.ElementFromPoint must be `double` instead
of `float`
Product: WebAppsWG
Version:
On Jun 5, 2014, at 10:42 AM, Ben Peters ben.pet...@microsoft.com wrote:
From: Ryosuke Niwa [mailto:rn...@apple.com]
Can this be an attribute on elements instead? Otherwise, browsers would
have to repeatedly call these functions to update edit menu, etc...
This may be an issue, I agree.
19 matches
Mail list logo
