Re: contentEditable=minimal
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 basic functionality only. For the sake of discussion, call it contentEditable='minimal'. The functionality provided by the browser under contentEditable='minimal' would be as follows: * Caret drawing * Events such as Keyboard , Clipboard, Drag and Drop * Some keyboard input handling- caret movement, typing of characters including Input Method Editor input * Selection drawing and manipulation according to the new Selection API spec This sounds like a super promising approach. I agree. If I understand the proposal correctly, when the user does something that causes input, like pressing the enter key, we would fire a key event, but we wouldn't actually modify the DOM. Modifying the DOM would be the responsibility of the web page. Likewise, if the user pressed whatever key is platform convention for paste, we would fire an event which contains the clipboard data, but not mutate the DOM. Copying data from the event (i.e. from the clipboard) to the page would be the responsibility of the page. Is that correct? If so I like it a lot! I think it'll be nice to allow authors to enable default UA actions; e.g. auto paste into DOM. I'd like to expand, and clarify, the list of services that you propose that the UA provides: * Caret and selection drawing. * Drawing IME UI in response to user typing. * Events for clipboard and drag'n'drop (though the UA would not mutate the DOM in response to those events). * Cursor navigation, including reacting to touch events, mouse clicks and keyboard events. Cursor navigation would likely also fire cancelable events. * Turning keyboard events into events representing text input (but not mutate the DOM in response to those events). * The Selection API spec for selection manipulation. I.e. pressing a key on the keyboard would always fire a keyboard event, and then, as default action, possibly a cursor navigation event or a text input event, depending on what type of key was pressed. I'm unsure about what the proper way to handle text insertion is. I.e. how to handle the second to last bullet. Can we simply use the same events as we fire in input type=text and textarea, but don't actually mutate any DOM? Or is it awkward to fire beforeinput when there is no default action of mutating the DOM and firing input? And is it too much complexity to ask pages to deal with composition handling themselves? I think requiring pages to handle composition events will be bad because many people don't even know how input methods work, or for that latter, what input method is. Another approach would be to allow plain text input events to actually mutate the DOM as a default action. But allow that action to be cancelled. Note that we would never do anything more complex than mutate an existing text node, or insert a text node where the cursor is located. I.e. no elements would ever get added, removed, split, have attributes changed or otherwise be mutated. I think it would be nice for authors to explicitly enable such default behaviors. - R. Niwa
Re: contentEditable=minimal
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 know what languages the others speak. That said, my recollection was that this was presented along the lines of we've had regular requests to support selecting text in geometric rather than logical orders. I have also heard these requests from the bi-directional experts here at Microsoft. A single, unbroken selection is what we're told users want, and multi-selection makes this possible. Thinking about this a little bit more: I don't imagine that the Selection API should prescribe the UI that browsers choose to support in order to select bidi text, on the contrary they should be allowed to innovate, experiment, follow various platform conventions, etc. But if we don't support multi-range selection, then only one model is possible which precludes unbroken selections. I think that this strongly pushes in the direction of supporting multiple ranges. I agree visual selection of bidirectional text is a problem worth solving but I don't think adding a generic multi-range selection support to the degree Gecko does is the right solution. For starters, most of author scripts completely ignore all but the first range, and applying editing operations to a multi-range selection is a nightmare. - R. Niwa
Re: contentEditable=minimal
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 probably be handled by moving the selection to the misspelled word and then writing the fixed word. Autocorrect should be handled like composition. Composition is pretty much what happens whenever you type some stuff and some other stuff comes out. (Technical definition.) I sadly don't think it's that simple. When compositing chinese characters, or characters like ü, an underline should be rendered during the composition and then removed once a character (or set of characters) is selected. This underline should not appear when typing on a mobile keyword, even if it supports autocorrect. It's not clear to me if the difference is just one of styling, or if there are semantic differences as well. Semantically, autocorrect and compositing really are the same thing. They are not. Word substations and input method compositions are semantically different operations. How that gets rendered may be another story, but I'll point out that there are mobile UIs in which the word being typed is underlined. Just because they're treated the same way in one platform doesn't allow us to treat them same in all platforms. It's crucial for editors on the Web to be able to use the same UI for on the platforms that do differentiate the two. Note that if there is a degree of refinement such that we may want to make it possible for authors to style compositing-for-characters and compositing-for-autocorrect, then that ought to go into the styling system. In older versions of Windows, for example, the browser itself can't figure out what kind of style is used by IME. Korean and Japanese IME on Windows, for example, use bolded lines and dotted lines for opposite purposes. And we get bug reports saying that WebKit's rendering for Korean IME is incorrect because we decided to follow Japanese IME's convention. We /could/ consider adding a field to compositing events that would capture some form of ontology of input systems. But I think that's sort of far-fetched and we can get by with the above. (And yes, I'm using ontology on purpose. It wouldn't look good :) In my opinion, it's a requirement that input methods work and look native on editors that use this new API. IME is not a nice-to-have feature. It's a feature required for billions of people to type any text. My assertion is that we don't want to use compositing events when typing on a keyboard which has autocorrect. (This might be a wrong assertion in which case none of this matters). Rather than composition events we fire events like: insert 'c' insert 'a' insert 'g' selection moved to start at index 0 and end at index 3 insert 'cat' insert ' ' However we've previously said that pages should be able to cancel or adjust selection moves. The question is what happens if the page changes the selection when autocorrect attempts to select the word to be fixed. Gotcha, and indeed you are correct. If autocorrect were implemented as a change of the selection followed by an insert of the correction, the application could unwillingly interfere with the selection and cause mayhem. But even if that weren't the case this would feel pretty hacky. Maybe you are thinking of this because on recent Androids when you autocorrect there's an animation that more or less makes it look like that's what's going on? Honestly, I really think that compositing events are the right abstraction here. We can get finicky on style tweaks, but they work for all compositing systems I can think of admittedly not *that* many but still quite a few). They would even work for T9! I strongly disagree. - R. Niwa
Re: [editing] CommandQuery Object and Event
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 trying to solve.
On Jun 4, 2014, at 11:31 AM, Ben Peters ben.pet...@microsoft.com wrote:
There has been some conversation about browser UI for Commands with
ContentEdtiable=minimal. Some people seem to believe that UI should not be
displayed because it may not be relevant. One way to solve this is to have an
event that would allow script to tell the browser what is relevant. Today,
there are several ways to ask the browser if a given command is
enabled/relevant. This includes queryCommandEnabled, queryCommandSupported,
and QueryCommandValue. However, the site is not able to influence the return
value of these events. In order to give more power to browsers, frameworks,
and sites, it seems to make sense to allow these values to be modified.
Therefore I propose a new method:
document.queryCommand(commandName)
which returns a new read-only object (called CommandQuery for now):
CommandQuery
{
Boolean isSupportedByUA;
Boolean isSupported;
Boolean isEnabled;
Object currentValue;
}
By default, this object will match the browser's support for this command in
the current context. However, before it returns, a CommandQuery event will
fire with a read/write CommandQuery object. If a framework or site wishes to
indicate different values for the command state, it can do so in that event.
CommandQueryEvent: Event {
{
CommandQuery commandQuery;
}
In this way, a framework can enable commands that a browser does not natively
support. Further, a browser could fire CommandQueryEvents to determine the
correct toolbar buttons to display. Thoughts?
Ben
Re: contentEditable and forms (was: contentEditable=minimal)
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 paragraph). And in some cases you don't want bold/italic because your use case requires only structured HTML. So being able to handle such commands is a one thing. But first of all there should be no assumption that a user needs these buttons, because a browser just don't know about that. If I think that users need toolbar, I can render a custom one. Much agreed. The browser should not show any markup/styling affordance for cE=minimal. There's one more assumption that makes editing on mobile devices (especially low-res devices) very hard. It's that if user focuses editable, then he/she wants to type, so native keyboard should pop out. Very often it's true, but in some cases user may want to select some text and using toolbar apply styles or lists, etc. And when the keyboard is visible there's very little space to do that. If there was any API to control whether keyboard is visible, then we could achieve much better UX. There are quite a few things from forms that I think could usefully become available in an editing context. We could benefit from having the inputmode attribute be allowed on any editable piece of text. For the specific use case you cite, an additional keyword of none might make sense too. It possibly wouldn't hurt to have the placeholder attribute be available on all editable content, too. I'm less sure about the validation attributes (except perhaps required) but why not. Obviously validation attributes only make sense if the editable content can contribute to forms. But it would make a lot of sense that it could. Today you have to resort to ugly hacks in which you somehow copy over the edited content into a textarea. That's pretty daft: in most use cases you're going to be submitting the content. There was a discussion about participating in the form submission in general back in Feb: http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0448.html There are several ways in which we could handle this. One is to have any element with cE=minimal contribute to the form data set (when inside a form, or possibly when using the form attribute if someone remembers what the use case for that thing was). That's interesting, but I get a sense that it conflates two features. Another approach is to add a submittable attribute that can make the innerHTML of any element contribute to the form data set. Thoughts? I think we should come up with a generic form participation mechanism that could be used for cE=minimal. - R. Niwa
[Bug 25914] No definition of parsing blob's scheme data
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25914 Anne ann...@annevk.nl changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #7 from Anne ann...@annevk.nl --- This is wrong. The URL parser is http://url.spec.whatwg.org/ That returns you components you can operate on. 'scheme data' seems to be the identifier you want. Or maybe 'scheme data' + ? + 'query'. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 25915] Cross-origin requests
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25915 Anne ann...@annevk.nl changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #4 from Anne ann...@annevk.nl --- This still seems wrong. :-( I think basically you do not want to say anything about cross-origin URLs and let that part of the security model be handled by Fetch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 25987] New: Blob URL parsing / fetching model
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 Priority: P2 Component: File API Assignee: a...@mozilla.com Reporter: ann...@annevk.nl QA Contact: public-webapps-bugzi...@w3.org CC: gl...@zewt.org, jo...@sicking.cc, public-webapps@w3.org Depends on: 25914 Blocks: 24338 Given http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0683.html we might need to revisit our strategy. It seems we've already given the URL parser access to the global environment so it can reach the blob URL store. However, the scope of the blob URL store also encompasses global environments that can be reached solely through document.domain and so not all of them are same-origin. So I guess in addition a same-origin check is in order. I guess we should do the same-origin check in the URL parser so it's deterministic. And then fetching a URL which has an associated object will just never fail. Does that make sense? -- You are receiving this mail because: You are on the CC list for the bug.
Re: [HTML Imports] What is the imagined work flow?
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://github.com/briandipalma/spa-2014-app/blob/master/src/SpaApplicationElement.js This Custom Element is able to load in it's dependent styling and template information. Albeit it requires extensions to the ES6 module loader they are not exceptionally complex. My preference for a ES6 module solution is biased by the fact I spend most of my time in JS code. I can imagine people who want to drop in some some broadly reusable functionality (social widgets etc) would prefer a HTML Import. If it's just a matter of adding a tag and either works then I'd question the use of two broadly similar specs. It might be easier to add native CSS and HTML loading to ES6 modules then to add HTMLImports to the platform. B. On Fri, May 23, 2014 at 6:42 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Brian, I believe Scott enumerated all these in his initial reply, but here's my take (I wrote parts of this in another email, my apologies to that email's recipient for repeating myself :) HTML Imports are primarily about dependency resolution. They allow the web developer to think locally in terms of their dependencies. Then, the underlying machinery builds a global dependency graph and turns it into a tree to ensure consistent processing order. Scripts in the imports are evaluated in this order. In addition, HTML Imports load/apply styles to the document in the same order, which enables a much saner way to reason about components and their effects. For example, in Jan Miksovsky's presentation at SFHTML5 event, he shows something very interesting (https://www.youtube.com/watch?feature=player_detailpagev=mN7IAaRdi_k#t=8608). He pastes link rel=import href=http://component.kitchen/packages/sample/basic-autosize-textarea/basic-autosize-textarea.html; in a jsbin and instantly gets his custom element work (modulo the platform.js polyfill, which will eventually not be necessary). This is super important. A typical way to do this prior to imports is: 1) Add the script src reference to the library that was used to develop this component 2) Add the link to the stylesheets that will be used by the component 3) Add the script src reference to the component itself. 4) In the script of the component, there will probably be some strings that are turned into DOM. 5) More than likely, there will be more links to other scripts or some machinery to munge all these scripts into one large one. Effectively, since there isn't a way to manage dependencies, this work would be relegated to build tools. With HTML Imports, Jan is able to do something for more elegant -- a single-line solution. This works, because HTML Imports carefully resolve the dependency tree for him. And this dependency tree is actually non-trivial (you can trace it with me by viewing source of http://component.kitchen/packages/sample/basic-autosize-textarea/basic-autosize-textarea.html): 1) The basic-autosize-textarea.html states that it has basic-element/basic-element.html as a dependent import 2) The basic-element.html has another dependent import, polymer.html 3) polymer.html depends on polymer.js and polymer-body.html Now that the dependency tree is understood, the HTML Imports plumbing evaluates the scripts, according to the tree: 1) polymer.js, which among other things, defines the polymer-element custom element 2) polymer-body.html 3) basic-element.html, which uses polymer-element to define a new basic-element element 4) basic-autosize-textarea.html, which uses polymer-element to extend basic-element to actually create the basic-autosize-textarea that we will need. All of this work is done on Jan's behalf without him needing to worry about it. He simply states dependencies -- locally. What's even cooler is that if anyone uses other components that rely on basic-element or polymer-element elsewhere in the document (or its imports), the respective imports will not be loaded twice -- the dependency management system takes care of that. The light bulb moment for me was realizing that I no longer need to state up front things like I am using jquery or I am using framework/library X at the beginning of your document. Instead, the import lists it as a local, explicit dependency -- which (especially with good inspector/devtools support) is a lot easier to reason about. I think you mentioned ES6 modules vs. HTML imports. They are not in an adversarial relationship. If anything, ES6 modules can be viewed as one of the bedrock technologies on which the HTML imports are built -- namely the underlying underlying loading/dependency resolution machinery. That's where we're going (https://www.w3.org/Bugs/Public/show_bug.cgi?id=25715). Once we figure out how to
[Bug 25994] New: invalid extended attribute list syntax
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: critical Priority: P2 Component: File API Assignee: a...@mozilla.com Reporter: gl...@skynav.com QA Contact: public-webapps-bugzi...@w3.org CC: public-webapps@w3.org The extended attribute list syntax used in the File API does not adhere to current WebIDL specification syntax. In particular, production 64 of the syntax [1] must consist of a comma separated list of ExtendedAttribute items. [1] http://heycam.github.io/webidl/#proddef-ExtendedAttributeList In order to fix this, please make the following changes: (1) on definition of Blob interface, change [Exposed=Window,Worker][Constructor, Constructor(sequence(ArrayBuffer or ArrayBufferView or Blob or DOMString) blobParts, optional BlobPropertyBag options)] to [Constructor, Constructor(sequence(ArrayBuffer or ArrayBufferView or Blob or DOMString) blobParts, optional BlobPropertyBag options), Exposed=Window,Worker] (2) on definition of File interface, change [Exposed=Window,Worker][Constructor(sequence(Blob or DOMString or ArrayBufferView or ArrayBuffer) fileBits, [EnsureUTF16] DOMString fileName, optional FilePropertyBag options)] to [Constructor(sequence(Blob or DOMString or ArrayBufferView or ArrayBuffer) fileBits, [EnsureUTF16] DOMString fileName, optional FilePropertyBag options), Exposed=Window,Worker] (3) on definition of FileReader interface, change [Exposed=Window,Worker][Constructor] to [Constructor, Exposed=Window,Worker] (4) on definition of FileReaderSync interface, change [Exposed=Worker][Constructor] to [Constructor, Exposed=Worker] Note that I have also reordered the Exposed extended attribute above to improve readability (given that it can contain a ',' as well). -- You are receiving this mail because: You are on the CC list for the bug.
RE: [editing] CommandQuery Object and Event
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, would an attribute really help us save computation?
Maybe we should be able to get the status of several commands at once with the
event? Something like this (just thinking out loud here)?
Document.queryCommands('bold', 'italic', 'underline', 'undo')
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 trying to solve.
Absolutely! This has been in the back of my mind for a while. Do you know what
would be the best way to involve them? Are some of them in both working groups?
Re: [editing] CommandQuery Object and Event
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 time
the selection/caret moves, would an attribute really help us save computation?
Maybe we should be able to get the status of several commands at once with the
event? Something like this (just thinking out loud here)?
Document.queryCommands('bold', 'italic', 'underline', 'undo')
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 trying to solve.
Absolutely! This has been in the back of my mind for a while. Do you know what
would be the best way to involve them? Are some of them in both working groups?
Based on a quick scan of the IndieUI WG participant list ([IndieUI]), it
appears Ted and James Craig would be the best suspects. That group's
mail list is http://lists.w3.org/Archives/Public/public-indie-ui/
(FYI, WebApps did a little bit of informal joint work with James in the
TPAC 2013 timeframe.)
-AB
[IndieUI] https://www.w3.org/2000/09/dbwg/details?group=54953
Indexed DB Transactions vs. Microtasks
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...
}).then(function() {
// is tx active here?
});
case 2:
var tx = db.transaction(storeName);
var request = tx.objectStore(storeName).get(0);
request.onsuccess = function() {
// tx should be active here...
Promise.resolve().then(function() {
// is tx active here?
});
};
In Chrome 35, the answers are no, no. This is because it was a
non-conforming Promise implementation, with the Promise callbacks not run
as microtasks. This was addressed in 36, so please disregard this behavior.
In Chrome 36, the answers are yes, yes.
In Firefox 29, the answers are yes, no.
For case 1, ISTM that yes matches the IDB spec, since control has not
returned to the event loop while the microtasks are running.
Implementations appear to agree.
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?
Re: Indexed DB Transactions vs. Microtasks
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 dispatch (specifically, the handling of onsuccess, as opposed to
addEventListener('success') which is similar but defined in other specs)
is something that HTML tries to define. Assuming IndexDB defers to HTML's
definition of event handler IDL attribute, then you go through the
event handler processing algorithm, which calls jump to a code
entry-point which calls clean up after running a callback which calls
perform a microtask checkpoint which, once ES and HTML have been made to
play nice, invokes the promise callbacks, all before the task that fired
the event handler has returned to the event loop. And once it does return
to the event loop, the next major thing _it_ does is perform a microtask
checkpoint anyway.
HTH.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
IndexedDB: MultiEntry index limited to 50 indexed values? Ouch.
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? Performance? If so, why is it NOT
mentioned in any of the IDB docs published by the browser vendors?
Following from my previous example (posted to this list), tags is a
multiEntry index defined like so:
objectStore.createIndex(tags, tags, {unique: false, multiEntry: true})
When I put in say 3000 tags as follows:
var req = objectStore.add({tags: myTagsArray, someKey: someValue, etc: etc})
Only the first 50 elements of myTagsArray show up in the Keys column within
the Chrome Web Console (under Resources--IndexedDB---tags) and it's not a
display issue only: The cursor (shown below) cannot find any value beyond
the initial 50 values in myTagsArray. This is despite the cursor.value.tags
containing all 100+ values.
var range = IDBKeyRange.only(tags[0], prev)
var cursor = index.openCursor(range)
Is this by design? Anyway to get around it (or do it differently) ? and why
is the limit of 50 on indexed values not mentioned in any of the docs?
I bet I'm missing something... because I can't think of why someone would
pick the number 50.
Thanks,
Marc
Re: IndexedDB: MultiEntry index limited to 50 indexed values? Ouch.
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 many records are shown
on one page of Chrome's IDB inspector in dev tools. And paging in the
inspector was recently broken (known bug, fix just landed:
http://crbug.com/379483). Are you sure you're not just seeing that?
If you're seeing this consistently across browsers, my guess is that
there's a subtle bug in your code (assuming we've ruled out a double-secret
limit imposed by the cabal of browser implementors...) This isn't a support
forum, so you may want to take the issue elsewhere - the chromium-html5 is
one such forum I lurk on.
If you're not seeing this across browsers, then this is definitely not the
right forum. As always, please try and reduce any issue to a minimal test
case; it's helpful both to understand what assumptions you may be making
(i.e. you mention a cursor; is that a critical part of your repro or is a
simple count() enough?) and for implementors to track down actual bugs. If
you do find browser bugs, please report them - crbug.com,
bugzilla.mozilla.org, etc.
On Thu, Jun 5, 2014 at 2:15 PM, marc fawzi marc.fa...@gmail.com wrote:
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?
Performance? If so, why is it NOT mentioned in any of the IDB docs
published by the browser vendors?
Following from my previous example (posted to this list), tags is a
multiEntry index defined like so:
objectStore.createIndex(tags, tags, {unique: false, multiEntry: true})
When I put in say 3000 tags as follows:
var req = objectStore.add({tags: myTagsArray, someKey: someValue, etc:
etc})
Only the first 50 elements of myTagsArray show up in the Keys column
within the Chrome Web Console (under Resources--IndexedDB---tags) and
it's not a display issue only: The cursor (shown below) cannot find any
value beyond the initial 50 values in myTagsArray. This is despite the
cursor.value.tags containing all 100+ values.
var range = IDBKeyRange.only(tags[0], prev)
var cursor = index.openCursor(range)
Is this by design? Anyway to get around it (or do it differently) ? and
why is the limit of 50 on indexed values not mentioned in any of the docs?
I bet I'm missing something... because I can't think of why someone would
pick the number 50.
Thanks,
Marc
Re: IndexedDB: MultiEntry index limited to 50 indexed values? Ouch.
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 implementation.
Given our prior conversation on this list resulted in some useful feedback,
according to you, I figured that you wanted to continue getting feedback on
this list. I guess the distinction to make is between reports of potential
bugs (which should go to chromium-html5 unless they are cross browser in
which case I'd post them here, right?) and API design issues (spec issues)
which is what my other post from a couple weeks ago was about. If it's the
latter then I'll post here, right? If the former I'll post to
chromium-html5. Since I only use Chrome in my current work, I'll probably
never bother verifying any bugs I find on other browsers, so I'll direct
them to chromium-html5.
Anything else?
Thanks for coding the test, and will post more DEBUGGER BUGS on
chromium-html5 that impact debug-ability of IDB apps. There are at least a
couple more.
On Thu, Jun 5, 2014 at 2:53 PM, Joshua Bell jsb...@google.com wrote:
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 many records are shown
on one page of Chrome's IDB inspector in dev tools. And paging in the
inspector was recently broken (known bug, fix just landed:
http://crbug.com/379483). Are you sure you're not just seeing that?
If you're seeing this consistently across browsers, my guess is that
there's a subtle bug in your code (assuming we've ruled out a double-secret
limit imposed by the cabal of browser implementors...) This isn't a support
forum, so you may want to take the issue elsewhere - the chromium-html5 is
one such forum I lurk on.
If you're not seeing this across browsers, then this is definitely not the
right forum. As always, please try and reduce any issue to a minimal test
case; it's helpful both to understand what assumptions you may be making
(i.e. you mention a cursor; is that a critical part of your repro or is a
simple count() enough?) and for implementors to track down actual bugs. If
you do find browser bugs, please report them - crbug.com,
bugzilla.mozilla.org, etc.
On Thu, Jun 5, 2014 at 2:15 PM, marc fawzi marc.fa...@gmail.com wrote:
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?
Performance? If so, why is it NOT mentioned in any of the IDB docs
published by the browser vendors?
Following from my previous example (posted to this list), tags is a
multiEntry index defined like so:
objectStore.createIndex(tags, tags, {unique: false, multiEntry: true})
When I put in say 3000 tags as follows:
var req = objectStore.add({tags: myTagsArray, someKey: someValue, etc:
etc})
Only the first 50 elements of myTagsArray show up in the Keys column
within the Chrome Web Console (under Resources--IndexedDB---tags) and
it's not a display issue only: The cursor (shown below) cannot find any
value beyond the initial 50 values in myTagsArray. This is despite the
cursor.value.tags containing all 100+ values.
var range = IDBKeyRange.only(tags[0], prev)
var cursor = index.openCursor(range)
Is this by design? Anyway to get around it (or do it differently) ? and
why is the limit of 50 on indexed values not mentioned in any of the docs?
I bet I'm missing something... because I can't think of why someone would
pick the number 50.
Thanks,
Marc
[Bug 26001] New: [Shadow]: The type of arguments of ShadowRoot.ElementFromPoint must be `double` instead of `float`
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: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: hay...@chromium.org QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14978 WebIDL checker found this minor issue. That said: unless there are specific reasons to use a 32 bit floating point type, specifications SHOULD use double rather than float. Document.ElementFromPoint(..) also uses `double`. See http://dev.w3.org/csswg/cssom-view/#dom-document-elementfrompoint -- You are receiving this mail because: You are on the CC list for the bug.
Re: [editing] CommandQuery Object and Event
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. But since it's dynamic and changes every time the selection/caret moves, would an attribute really help us save computation? Maybe we should be able to get the status of several commands at once with the event? Something like this (just thinking out loud here)? We should avoid running JS to update the browser UI since that will make the timing of events dispatch dependent on specific implementations. I'm fine with adding some interface objects that needs to be called upon selection change, etc... If keep updating the states is a concern, we can expose a list of states that UA care about somewhere so that the scripts can avoid updating other states - R. Niwa
