Re: contentEditable=minimal
On Thu, May 22, 2014 at 3:59 AM, Piotr Koszuliński p.koszulin...@cksource.com wrote: ## What should cE=minimal handle? Awesome feedback! ## What should cE=minimal handle? 1. Selection and caret drawing. 2. Selection API Agreed on both! 3. Typing characters. 4. Delete, backspace. I think these are the hard ones. More below. 5. Navigating with arrow keys, selection with SHIFT, CTRL modifier. Agreed. Developers have to deal with selection moving around anyway since they should handle touch screens. But we should definitely fire events whenever cursor or selection is moved and enable the page to either cancel the movement, or adjust the location before it takes effect. 6. Spell check. When you want a native spell check you cannot override context menu. When you want custom context menu, you need custom spell check (which is extremely hard). And context menu is very important for many users because they used to look there for contextual options, so most editors override it. Therefore, a way control at least one of them (I guess it won't be a context menu, though that would be awesome) will be great. There's already a contextmenu feature in HTML, though I don't know if any other browser than Firefox implements it. And the spec has seen so much changes that I don't know how closely Firefox conforms to the spec. Anyhow, I think the ability to extend/replace the existing context menu is the way to go if that's what people need. Adding spellchecking primitivies, and forcing webpages to implement their own spellcheck, seems like the wrong way to go about enabling pages to do their own context menus. ## What should not be handled by cE=minimal? 1. Bold, italic, list, link, blockquote and other commands creating content. 2. Enter key support. 3. Tables and images resizing. 4. Another thing that browser engines cannot do is trying to be... too smart? Strongly agree with all of these. 5. There should be no native toolbars in cE=minimal (and other native UI interfering) like the one Safari opens on iOS if you have non-empty selection. I haven't yet checked exactly what's in the iOS toolbar, but generally I don't think we should dictate UI. Clearly on mobile we don't want to forbid browsers to bring up the virutal keyboard, which is a form of native UI. And the spellcheck UI that safari displays also doesn't seem bad if spellchecking is enabled. And UI for cut/copy/past that android renders seems good to render *somewhere* when there's selection. Regarding text entry, I think this is the really hard decision that we need to make. I.e. should we only fire enough semantic input events, or also implement plaintext editing in addition. One interesting question is: Are pages generally happy with the plaintext editing of input type=text and textarea? Or do they find themselves often having to override their behavior using the events that browsers fire? What are the use cases of events like compositionstart and compositionend? Were they added in order to enable webpages to override composition related editing of input type=text and textarea? What about the beforeinput event? I think there might be a lot of boiler plate needed to implement plaintext editing. Not only are there normal beforeinput events to take into account. There's also things like composition events, backspace vs. delete, modifier+backspace/delete (deleting a word/line), voice-to-text input (provides data word-by-word), pasting, (bidi?), etc. It adds up pretty quickly. Some of these things pages will have to deal with no matter what. As has been pointed out, if the user selects across multiple elements and presses delete or 'a', then almost certainly the page will have to run application logic. Likewise if the cursor is placed right after an element but before a bunch of text, and the user then presses backspace. However it seems like if authors generally are ok with the plaintext editing that input type=text and textarea has, and then only have them worry about things like inserting elements to do styling or inserting document structure (lists, headers, paragraphs, etc), then that means less work for the author, and greater likelihood that text editing works as the user expects. I suspect that the right thing to do here is some experimentation. It would be very interesting to do a prototype implementation of contenteditable=minimal which never did any DOM mutations, not even for IME or text editing. Then see how much code needs to handle all of the plaintext editing features above. I'd also be interested trying out having the browser perform plain-text DOM mutations but make sure to keep the rules very simple. So if you select a stretch of text and press delete, we would not do any DOM mutation (or possibly we could delete just any text content, possibly leaving elements empty). Then see how much of a pain it would be to allow the page to apply its own rules like ensure all characters are lowercase or insert
Re: contentEditable=minimal
On 23/05/2014 01:23 , Ben Peters wrote: As I said I am unsure that the way in which composition events are described in DOM 3 Events is perfect, but that's only because I haven't used them in anger and they aren't supported much. My thought is that we can use CommandEvent with type=insertText. This would be the corollary to execComamnd(insertText), and the data would be the ñ that is about to be inserted. But if you only get one event you can't render the composition as it is carrying out. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [clipboard events] click-to-copy support could be hasFeature discoverable?
On Wed, May 21, 2014 at 2:01 AM, Glenn Maynard gl...@zewt.org wrote: I think I'd suggest avoiding the mess of execCommand altogether, and add new methods, eg. window.copy() and window.cut() (or maybe just one method, with a cut option). execCommand is such a nonsensical way to expose an API that trying to stay consistent with its commands is probably not much of a win. I'm inclined to agree, FWIW. If the command is really strictly editor-related, and makes sense only in conjunction with an editor based on existing commands, I would add it to execCommand for consistency (like defaultParagraphSeparator or fontSizePt). But anything else should stay far away. (Actually, if contenteditable wasn't an unsalvageable trainwreck, I would rather write a new API that actually follows JS norms, like window.editor.bold() or similar, but it is, so there's no point in doing anything beyond *maybe* trying to get it a bit more interoperable.)
Should minimal contentEditable default text input (was: contentEditable=minimal)
Starting a new thread for this specific topic as I think it's one of the important early points of contention. On 22/05/2014 12:59 , Piotr Koszuliński wrote: 3. Typing characters. It works in textarea and I think it should work out of the box in cE=minimal. Otherwise, cE=minimal will be useless for simple cases (mentioned Twitter), because you'll always need a pretty complex library to handle text input. Additionally, I don't remember any problem with typing characters, so this seems to work well already in cE=true. There's also the IME which scares me, but I don't have any experience with it. I hear your point about essentially making simple things simple, but I really want to resist supporting as much built-in behaviour as possible. Of course, it's a trade-off, but I think we should strive for the smallest possible amount of behaviour. Note that 1) the complexity of simple things by and large depends on the quality of the primitives we provide and 2) on the interoperability of what is supported. And the simpler the functionality, the more easily interoperable. Inserting text as the default behaviour for text input events has implications: Things get very weird if you support it when you have a caret (i.e. a collapsed selection) but not when you have a selection. And a selection can have arbitrary endpoints around and into an element. This means that typing with an active selection can do more than add some text to a node: it can delete or modify elements. Sure enough this can be described interoperably, but it does bring us back to issues we dislike. It also means that the browser needs to handle composition and its rendering, which while it is ongoing may produce relatively weird states in the DOM. I agree that the Twitter box is a good very basic example. It basically needs: 1) Words that start with @ or # to be a specific colour. 2) Links to be a different colour, and to have their characters counted as the shortened link rather than the full thing. 3) Newlines must be taken into account. 4) Characters beyond 140 are highlighted in red. I'm ignoring complications with files and the such. In fact, for the purpose of our use case it is only useful IMHO to look at how best to handle (3) and (4). I tried to bang together some code that would do the Twitter box, adding a few features along the way and documenting assumptions and issues. It looks like that (untested, off the top of my head): https://gist.github.com/darobin/8a128f05106d0e02717b#file-twitter-html It looks a bit scary, but if you remove the part that handles excess text and the wordy comments, you just get: https://gist.github.com/darobin/8a128f05106d0e02717b#file-like-textarea-html Granted, that's still a fair bit of boilerplate. But I think we have to take into account the following: • This is meant to be low-level. I'm happy to make things easier but only so long as we don't introduce magic. • We can make introduce some convenience methods for the non-obvious parts of the boilerplate. Just having Selection.replace(node|text...) or something like new Range(sNode, sOffset, eNode, eOffset) would make things a lot nicer. It's likely I've forgotten stuff though (notably paste filtering, which I'm unsure how to best handle here — see comments). Please review the code so that we have an idea for a baseline of what we'd like to get at the end. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: contentEditable=minimal
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.) Though one interesting edge case there is what happens if the page adjusts the selection as it's being moved to the word autocorrect wants to fix? I'm sorry, I don't understand the case you're thinking of? -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: contentEditable=minimal
On 23/05/2014 11:55 , Jonas Sicking wrote:
On Thu, May 22, 2014 at 3:59 AM, Piotr Koszuliński
5. Navigating with arrow keys, selection with SHIFT, CTRL modifier.
Agreed. Developers have to deal with selection moving around anyway
since they should handle touch screens.
Even without accounting for touch screens, you really want the platform
to be the thing that knows what Ctrl-Shift-Left means so you don't have
to support it yourself (and get it wrong often).
But we should definitely fire events whenever cursor or selection is
moved and enable the page to either cancel the movement, or adjust the
location before it takes effect.
Agreed. I also think that it is important that if the selection is
allowed to have anchors both inside and outside the editing area then
the editing MUST NOT retain focus. Anything else would lead to really
annoying cases.
Note: you keep saying things like cursor or selection. Can we agree
that they are the same thing? A caret on its own is a selection with a
single collapsed range (and a direction).
Which brings me to think: when we discussed this at the Summit, there
was some agreement (between all four of us :) that it was a good idea to
support multi-range selections. These are useful not just for tables,
but also for bidi. The reason for the latter is that when selecting a
line with multiple embedded directions (using a mouse), you want to have
the visual selection be an unbroken line (as opposed to the crazy
jumping around you get if you follow logical order).
It's definitely useful, though it does come with its problems. The
question that opens up for me is: do we want to support multi-caret
editing as well? The data model certainly supports it, but we have to
account for it early if it's an option.
At any rate, multi-range selections would be much easier to handle if we
had something like Selection.forEachRange(function (r) {...}).
Regarding text entry, I think this is the really hard decision that we
need to make. I.e. should we only fire enough semantic input events,
or also implement plaintext editing in addition.
One interesting question is: Are pages generally happy with the
plaintext editing of input type=text and textarea? Or do they find
themselves often having to override their behavior using the events
that browsers fire?
I would say yes and no. I don't think we need numbers to state that
there's a lot of content out there that uses unadulterated
input/textarea. But they're also handling what is guaranteed to be pure
text. That is not at all the same as structured text.
Also, a non-negligible subset of those do indeed override the browser's
default behaviour. Typical cases are input masking or formatting. (Given
the largely useless state of date inputs today, that's not going away
any time soon, either.)
What are the use cases of events like compositionstart and
compositionend? Were they added in order to enable webpages to
override composition related editing of input type=text and
textarea?
If you look at the examples I posted, you can see that you can't do your
own rendering of composition unless you have these. As far as I know
that's the primary use case.
What about the beforeinput event?
My understanding is that it is cancellable while input is not, which
enables people to pick the one they need based on their needs and its
performance implications.
A lot of sites nowadays do something like this: have a textarea in which
you can enter Markdown, WikiText, or some other horrible goo and with
every character you type a preview rendering of your text gets updated.
If you use a cancellable text event and carry out the rendering in the
event handler, the browser has to wait for the rendering to finish
before it can paint the character in the source box. That leads to a
small but perceptible lag. Presumably if you operate on events that have
already had their default action carried out you're fine here.
This isn't to say that this is perfect. It seems to me that this is an
area of events that isn't all that interoperable yet so we have some
leeway to change things. (Or perhaps even invent something new.)
I think there might be a lot of boiler plate needed to implement
plaintext editing. Not only are there normal beforeinput events to
take into account. There's also things like composition events,
backspace vs. delete, modifier+backspace/delete (deleting a
word/line), voice-to-text input (provides data word-by-word), pasting,
(bidi?), etc. It adds up pretty quickly.
Not all of those are separate, though. Voice input is just an input (or
beforeinput) that's more than one character long. There's nothing wrong
with that. So is pasting (though you need cleaning up). Composition you
need to handle, but I would really, really hope that the platform gives
you a delete event with a range that matches what it is expected to
delete rather than have you support all the modifiers (which
Re: [clipboard events] click-to-copy support could be hasFeature discoverable?
I'm all in favor of a new API as well. Sincerely, James Greene On Fri, May 23, 2014 at 5:53 AM, Aryeh Gregor a...@aryeh.name wrote: On Wed, May 21, 2014 at 2:01 AM, Glenn Maynard gl...@zewt.org wrote: I think I'd suggest avoiding the mess of execCommand altogether, and add new methods, eg. window.copy() and window.cut() (or maybe just one method, with a cut option). execCommand is such a nonsensical way to expose an API that trying to stay consistent with its commands is probably not much of a win. I'm inclined to agree, FWIW. If the command is really strictly editor-related, and makes sense only in conjunction with an editor based on existing commands, I would add it to execCommand for consistency (like defaultParagraphSeparator or fontSizePt). But anything else should stay far away. (Actually, if contenteditable wasn't an unsalvageable trainwreck, I would rather write a new API that actually follows JS norms, like window.editor.bold() or similar, but it is, so there's no point in doing anything beyond *maybe* trying to get it a bit more interoperable.)
Re: [clipboard events] click-to-copy support could be hasFeature discoverable?
On 23/05/2014 14:33 , James Greene wrote: I'm all in favor of a new API as well. Me too, as discussed in http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0550.html. I wouldn't put this on window though; why not put it on Selection? -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [clipboard events] click-to-copy support could be hasFeature discoverable?
I wouldn't put this on window though; why not put it on Selection? This kind of copy does not implicitly have anything to do with Selection, unless we continue to have its default action be copying the currently selected text. It is substantially more likely to be used for custom text insertion. Sincerely, James Greene On Fri, May 23, 2014 at 7:43 AM, Robin Berjon ro...@w3.org wrote: On 23/05/2014 14:33 , James Greene wrote: I'm all in favor of a new API as well. Me too, as discussed in http://lists.w3.org/Archives/ Public/public-webapps/2014JanMar/0550.html. I wouldn't put this on window though; why not put it on Selection? -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [clipboard events] click-to-copy support could be hasFeature discoverable?
Moreover, the clipboard is systemwide, when selection exists per document. So in my opinion window is a better choice. On Fri, May 23, 2014 at 3:21 PM, James Greene james.m.gre...@gmail.comwrote: I wouldn't put this on window though; why not put it on Selection? This kind of copy does not implicitly have anything to do with Selection, unless we continue to have its default action be copying the currently selected text. It is substantially more likely to be used for custom text insertion. -- Piotrek Koszuliński CKEditor JavaScript Lead Developer
Re: [Bug 25376] - Web Components won't integrate without much testing
On Tue, May 20, 2014 at 8:41 PM, Axel Dahmen bril...@hotmail.com wrote: I got redirected here from a HTML5 discussion on an IFrame's SEAMLESS attribute: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25376 Ian Hickson suggested to publish my findings here so the Web Components team may consider to re-evaluate the draft and probably amending the spec. Could you post your findings here? Digging through the bug thread, it appears you might be talking about this: Web Components require a plethora of additional browser features and behaviours. Web Components require loads of additional HTML, CSS and client script code for displaying content. Web Components install complex concepts (e.g. decorators) by introducing unique, complex, opaque behaviours, abandoning the pure nature of presentation. Web Components require special script event handling, so existing script code cannot be reused. Web Components require special CSS handling, so existing CSS cannot be reused. Web Components unnecessarily introduce a new clumsy “custom”, or “undefined” element, leaving the path of presentation. Custom Elements could as easy be achieved using CSS classes, and querySelector() in ECMA Script. The W3C DOM MutationObserver specification already provides functionality equivalent to insertedCallback()/readyCallback()/removeCallback(). Is this correct? Is this the full list of comments you wish to make? ~TJ
Re: [Bug 25376] - Web Components won't integrate without much testing
On May 23, 2014 10:18 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, May 20, 2014 at 8:41 PM, Axel Dahmen bril...@hotmail.com wrote: I got redirected here from a HTML5 discussion on an IFrame's SEAMLESS attribute: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25376 Ian Hickson suggested to publish my findings here so the Web Components team may consider to re-evaluate the draft and probably amending the spec. Could you post your findings here? Replying to the points from the bug, quoted by Tab below ... Digging through the bug thread, it appears you might be talking about this: Web Components require a plethora of additional browser features and behaviours. Natively though, that seems a good thing to me.. Web Components require loads of additional HTML, CSS and client script code for displaying content. How? CSS seems the same either way, html could actually be significantly lessened and script is dependent on what you actually want to do. If it's just a fragment js for a single fragment element would potentially serve many and you can describe declaratively a lot. Web Components install complex concepts (e.g. decorators) by introducing unique, complex, opaque behaviours, abandoning the pure nature of presentation. Decorators were dropped last i checked, but many of the new features create a lightweight alternative to iframes and, again, give us, new powers to create. Web Components require special script event handling, so existing script code cannot be reused. Depends, but possibly. Can you provide a specific that works better with iframes in this regard. Web Components require special CSS handling, so existing CSS cannot be reused. Same comment as above.. Web Components unnecessarily introduce a new clumsy “custom”, or “undefined” element, leaving the path of presentation. Custom Elements could as easy be achieved using CSS classes, and querySelector() in ECMA Script. Definitely not, because as you say, we add new mechanisms to treat Custom Elements (note title casing) as first class things with a known lifecycle, larger meaning etc. you could visually and interactively achieve similar results from a user perspective potentially, and nothing prevents you going forward from maintaining this mentality for your use. What that approach doesn't give you is a universal means to declaratively share these with scores of users who don't have to understand all that and for the community to participate easily in finding out what actually works for us instead of spending years in a committee to debate about things only to find out that, after all, it doesn't. The W3C DOM MutationObserver specification already provides functionality equivalent to insertedCallback()/readyCallback()/removeCallback(). MutationObservers, I believe, are neutral spec-wise on the point of when they fire in terms of parsing (I think), but regardless of the spec, at least Mozilla does not fire them during parse. That turns out to be a pretty big deal actually. Ideally, though, we should be connecting APIs and layering them atop one another so just because this is possible with another API does not make it a bad thing. Is this correct? Is this the full list of comments you wish to make? ~TJ
Re: [clipboard events] click-to-copy support could be hasFeature discoverable?
Hallvord: By the way, please add the editor of the HTML spec to the beginning of the list in your references. It's strange to list a bunch of author names, but not the person who actually writes the spec. On Fri, May 23, 2014 at 8:21 AM, James Greene james.m.gre...@gmail.comwrote: This kind of copy does not implicitly have anything to do with Selection, unless we continue to have its default action be copying the currently selected text. It is substantially more likely to be used for custom text insertion. I'd assume something like: // Copy text: window.copyToClipboard(hello); // Copy HTML text: span = document.createElement(span); span.innerHTML = bhello/b; window.copyToClipboard(span); // Copy an image from a CanvasImageSource: window.copyToClipboard(canvas); window.copyToClipboard(img); // Copy the selection: window.copyToClipboard(window.getSelection()); // Copy HTML text with plaintext alternative: dt = new DataTransferItemList(); dt.add(hello, text/plain); dt.add(span.innerHTML, text/html); window.copyToClipboard(dt); This avoids the busywork of creating a DataTransfer in common cases, but allows using DataTransfer when you want to do something more advanced, like provide alternatives or explicitly specify a MIME type. Note that DataTransferItemList isn't actually constructable right now. Note that I used DataTransferItemList in the example and not DataTransfer, since DataTransfer is only relevant to drag-and-drop. I wonder what the right way to handle images is. Native Windows applications can copy pixel data to the clipboard, then paste it back out. DataTransferItem wants things to act like strings, though, so you'd have to encode the image to a file format. If that's PNG, that's an expensive conversion. Maybe DataTransferItem should be able to return an ImageSource. (As an aside, why is the paste event's .clipboardData not set to the text being pasted? I wanted to see what pasting images did in current browsers, but at least in Chrome there's nothing in there, even if I just paste plain text.) -- Glenn Maynard
Re: [HTML Imports] What is the imagined work flow?
HTML Imports seems the least crucial of the Web Components specs.
Consider that all but the most trivial of Web Components will require JS.
JS is now getting a module system which can be used to load other
resources ( e.g. https://github.com/systemjs/systemjs/#plugins ).
The JS module system seems much more flexible then loading via URLs.
I think it's fair to question if HTML Imports is even necessary.
Are any of the current HTML Import use cases impossible to implement
using JS modules?
On Wed, May 21, 2014 at 8:13 AM, Scott Miles sjmi...@google.com wrote:
Sorry, but just a bit of follow up.
One may notice that the Web Components spec is imperative and assume that
declarative support is not important. But as it turns out, the notion of
using custom-elements to bootstrap declarative syntaxes allows various
parties to experiment in the real-world, as opposed to a working group
trying to resolve the trade-offs in an a-priori spec.
I mention this, because although I used Polymer as an example (it's my
project after all), the fact is we hope people will use web-components like
this:
link rel=import href=sweet-button.html
...
sweet-button/sweet-button
Is sweet-button implemented via Polymer? X-tags? Vanilla JavaScript? User
doesn't need to know to use the resource.
Ideally, best-of-breed technology emerges and the option to standardize is
still available.
On Tue, May 20, 2014 at 11:56 PM, Scott Miles sjmi...@google.com wrote:
Some of the ways Polymer team uses imports are as follows:
- aggregating script src and/or link rel=stylesheet elements into
functional units
- aggregating imports themselves into units
- expressing dependencies (N modules can each import jquery2-import.html
and I only get one copy of jquery)
- importing self-organizing databases via custom elements (e.g.
core-meta elements describe/provide metadata using monostate pattern)
Also, one of the first things Polymer does is register a custom-element
which itself provides a declarative interface to the custom element
machinery. Most other Polymer elements are then structured declaratively (as
HTML) which makes using imports highly convenient.
would stick a style element in the imported document
You can do that, reference an external stylesheet, or place a (scoped)
style tag directly in the shadow-root.
E.g. using Polymer idiom
polymer-element name=my-button noscript
template
style
:host div.someclass {
color: aliceblue;
}
/style
div class=someclassmy-button/div
/template
/polymer-element
On Tue, May 20, 2014 at 10:08 PM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
Over here at mozilla we've been trying to understand how the HTML
Imports spec is intended to be used.
We have so far received descriptions of how the spec works. I.e. what
happens when the various import related attributes are added to an
link rel=import.
However I'm curious to understand the expected developer work flows.
Let me make a few guesses to clarify the type of description I'm looking
for.
Clearly imports are expected to be used together with web components.
However so far web components are mainly an imperative API, and not a
declarative thing. Any element registrations needs to be created
through JS calls, and all the shadow DOM inside a custom element needs
to be created using JS calls and then inserted into the shadow root
using script.
At first glance it seems like a simple script src=... would then
provide all that you need?
However it might be tedious to create all elements using createElement
and appendChild calls. A better work flow is to stick a script in a
link rel=imported document together with some template elements.
Then clone the of those templates from the constructors of the custom
elements.
And in order to style the custom elements, you would stick a style
element in the imported document which would have rules like
my-button::shadow div.someclass {
color: aliceblue;
}
Is this an accurate description? Are there other reasons to stick
non-script content in the HTML? Are there any examples out there of
how HTML imports are intended to be used?
/ Jonas
Re: IndexedDB Proposed API Change: cursor.advance BACKWARD when direction is prev
I thought .continue/advance was similar to the 'continue' statement in a for loop in that everything below the statement will be ignored and the loop would start again from the next index. So my console logging was giving confusing results. I figured it out and it works fine now. For sanity's sake, I've resorted to adding a 'return' in my code in the .success callback after every .advance and .continue so the execution flow is easier to follow. It's very confusing, from execution flow perspective, for execution to continue past .continue/.advance while at once looping asynchronously. I understand it's two different instances of the .success callback but it was entirely not clear to me from reading the docs on MDN (for example) that .advance / .continue are async. Also, the description of .advance in browser vendor's documentation, e.g. on MDN, says Advance the cursor position forward by two places for cursor.advance(2) but what they should really say is advance the cursor position forward by two results. For example, let's say cursor first landed on an item with primary key = 7, and you issue the statement cursor.advance(2), I would expect it to go to the item with primary key 5 (for cursor direction = prev) but instead it goes to the item with primary key 2 because that's the 2nd match for the range argument from the cursor's current position, which means that .advance(n) would be far more clear semantically speaking if it was simply done as .continue(n) ... I guess if there is an understanding that the cursor is always at a matching item and that it could only continue/advance to the next/prev matching item, not literal 'positions' in the table (i.e. sequentially through the list of all items) then there would be no confusion but the very concept of a cursor is foreign to most front end developers, and that's where the confusion comes from for many. My inclination as a front end developer, so far removed from database terminology, would be 1) to deprecate .advance in favor of .continue(n) and 2) if it makes sense (you have to say why it may not) have .continue()/.continue(n) cause the return of the execution flow similar to 'continue' in a for loop. What do you think? On Wed, May 21, 2014 at 10:42 AM, Joshua Bell jsb...@google.com wrote: On Wed, May 21, 2014 at 7:32 AM, Arthur Barstow art.bars...@gmail.comwrote: [ Bcc www-tag ; Marc - please use public-webapps for IDB discussions ] On 5/20/14 7:46 PM, marc fawzi wrote: Hi everyone, I've been using IndexedDB for a week or so and I've noticed that cursor.advance(n) will always move n items forward regardless of cursor direction. In other words, when the cursor direction is set to prev as in: range = IDBKeyRange.only(someValue, prev) and primary key is auto-incremented, the cursor, upon cursor.advance(n), will actually advance n items in the opposite direction to the cursor.continue() operation. That runs contrary to the spec. Both continue() and advance() reference the steps for iterating a cursor which picks up the direction from the cursor object; neither entry point alters the steps to affect the direction. When you say you've noticed, are you observing a particular browser's implementation or are you interpreting the spec? I did a quick test and Chrome, Firefox, and IE all appear to behave as I expected when intermixing continue() and advance() calls with direction 'prev' - the cursor always moves in the same direction regardless of which call is used. Can you share sample code that demonstrates the problem, and indicate which browser(s) you've tested? This is not only an issue of broken symmetry but it presents an obstacle to doing things like: keeping a record of the primaryKey of the last found item (after calling cursor.continue for say 200 times) and, long after the transaction has ended, call our search function again and, upon finding the same item it found first last time, advance the cursor to the previously recorded primary key and call cursor.continue 200 times, from that offset, and repeat whenever you need to fetch the next 200 matching items. Such algorithm works in the forward direction (from oldest to newest item) because cursor.advance(n) can be used to position the cursor forward at the previously recorded primary key (of last found item) but it does not work in the backward direction (from newest to oldest item) because there is no way to make the cursor advance backward. It only advances forward, regardless of its own set direction. This example is very rough and arbitrary. But it appears to me that the cursor.advance needs to obey the cursor's own direction setting. It's almost like having a car that only moves forward (and can't u-turn) and in order to move backward you have to reverse the road. That's bonkers. What's up with that? How naive or terribly misguided am I being? Thanks in advance. Marc
Re: [HTML Imports] What is the imagined work flow?
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 implement script type=module (https://github.com/dherman/web-modules/tree/master/module-tag), it will fit nicely into the imports story as well -- it's just one of dependencies. :DG On Fri, May 23, 2014 at 9:35 AM, Brian Di Palma off...@gmail.com wrote: HTML Imports seems the least crucial of the Web Components specs. Consider that all but the most trivial of Web Components will require JS. JS is now getting a module system which can be used to load other resources ( e.g. https://github.com/systemjs/systemjs/#plugins ). The JS module system seems much more flexible then loading via URLs. I think it's fair to question if HTML Imports is even necessary. Are any of the current HTML Import use cases impossible to implement using JS modules? On Wed, May 21, 2014 at 8:13 AM, Scott Miles sjmi...@google.com wrote: Sorry, but just a bit of follow up. One may notice that the Web Components spec is imperative and assume that declarative support is not important. But as it turns out, the notion of using custom-elements to bootstrap declarative syntaxes allows various parties to
Re: IndexedDB Proposed API Change: cursor.advance BACKWARD when direction is prev
On Fri, May 23, 2014 at 9:40 AM, marc fawzi marc.fa...@gmail.com wrote: I thought .continue/advance was similar to the 'continue' statement in a for loop in that everything below the statement will be ignored and the loop would start again from the next index. So my console logging was giving confusing results. I figured it out and it works fine now. Thanks for following up! At least two IDB implementers were worried that you'd found some browser bugs we couldn't reproduce. For sanity's sake, I've resorted to adding a 'return' in my code in the .success callback after every .advance and .continue so the execution flow is easier to follow. It's very confusing, from execution flow perspective, for execution to continue past .continue/.advance while at once looping asynchronously. I understand it's two different instances of the .success callback but it was entirely not clear to me from reading the docs on MDN (for example) that .advance / .continue are async. Long term, we expect JS to evolve better ways of expressing async calls and using async results. Promises are a first step, and hopefully the language also grows some syntax for them. IDB should jump on that train somehow. Also, the description of .advance in browser vendor's documentation, e.g. on MDN, says Advance the cursor position forward by two places for cursor.advance(2) but what they should really say is advance the cursor position forward by two results. For example, let's say cursor first landed on an item with primary key = 7, and you issue the statement cursor.advance(2), I would expect it to go to the item with primary key 5 (for cursor direction = prev) but instead it goes to the item with primary key 2 because that's the 2nd match for the range argument from the cursor's current position What range argument are you referring to? Assuming the store has [1,2,3,4,5,6,7,8,9] and the cursor's range is not restricted, if the cursor's key=7 and direction='prev' then I would expect after advance(2) that key=5. If you're seeing key=2 can you post a sample somewhere (e.g. jsfiddle.com?) , which means that .advance(n) would be far more clear semantically speaking if it was simply done as .continue(n) ... I guess if there is an understanding that the cursor is always at a matching item and that it could only continue/advance to the next/prev matching item, not literal 'positions' in the table (i.e. sequentially through the list of all items) then there would be no confusion but the very concept of a cursor is foreign to most front end developers, and that's where the confusion comes from for many. My inclination as a front end developer, so far removed from database terminology, would be 1) to deprecate .advance in favor of .continue(n) and continue(n) already has meaning - it jumps ahead to the key with value n 2) if it makes sense (you have to say why it may not) have .continue()/.continue(n) cause the return of the execution flow similar to 'continue' in a for loop. The API can't change the language - you return from functions via return or throw. Further, there are reasons you may want to do further processing after calling continue() - e.g. there may be multiple cursors (e.g. in a join operation) or for better performance you can call continue() as early as possible so that the database can do its work while you're processing the previous result. What do you think? On Wed, May 21, 2014 at 10:42 AM, Joshua Bell jsb...@google.com wrote: On Wed, May 21, 2014 at 7:32 AM, Arthur Barstow art.bars...@gmail.comwrote: [ Bcc www-tag ; Marc - please use public-webapps for IDB discussions ] On 5/20/14 7:46 PM, marc fawzi wrote: Hi everyone, I've been using IndexedDB for a week or so and I've noticed that cursor.advance(n) will always move n items forward regardless of cursor direction. In other words, when the cursor direction is set to prev as in: range = IDBKeyRange.only(someValue, prev) and primary key is auto-incremented, the cursor, upon cursor.advance(n), will actually advance n items in the opposite direction to the cursor.continue() operation. That runs contrary to the spec. Both continue() and advance() reference the steps for iterating a cursor which picks up the direction from the cursor object; neither entry point alters the steps to affect the direction. When you say you've noticed, are you observing a particular browser's implementation or are you interpreting the spec? I did a quick test and Chrome, Firefox, and IE all appear to behave as I expected when intermixing continue() and advance() calls with direction 'prev' - the cursor always moves in the same direction regardless of which call is used. Can you share sample code that demonstrates the problem, and indicate which browser(s) you've tested? This is not only an issue of broken symmetry but it presents an obstacle to doing things like: keeping a record of the primaryKey of the
Re: [clipboard events] click-to-copy support could be hasFeature discoverable?
Maybe it's just me but... I would personally never want the browser to
automatically assume what I wanted copied and into which clipboard
segments, with the possible exception of a Selection.
I would prefer something very explicit, e.g.:
```js
window.clipboard.copy({
text/plain: BLAH,
text/html: bBlah/b,
application/rtf: {\\rtf1\\ansi\n{\\b Blah}},
text/x-markdown: **Blah**
});
```
Also, Hallvord et al: switching to a standalone API would also mean that we
can drop all of the `cut`-specific parts of the spec since `cut` requires
an active Selection, right?
Sincerely,
James Greene
On Fri, May 23, 2014 at 10:13 AM, Glenn Maynard gl...@zewt.org wrote:
Hallvord: By the way, please add the editor of the HTML spec to the
beginning of the list in your references. It's strange to list a bunch of
author names, but not the person who actually writes the spec.
On Fri, May 23, 2014 at 8:21 AM, James Greene james.m.gre...@gmail.comwrote:
This kind of copy does not implicitly have anything to do with Selection,
unless we continue to have its default action be copying the currently
selected text. It is substantially more likely to be used for custom text
insertion.
I'd assume something like:
// Copy text:
window.copyToClipboard(hello);
// Copy HTML text:
span = document.createElement(span);
span.innerHTML = bhello/b;
window.copyToClipboard(span);
// Copy an image from a CanvasImageSource:
window.copyToClipboard(canvas);
window.copyToClipboard(img);
// Copy the selection:
window.copyToClipboard(window.getSelection());
// Copy HTML text with plaintext alternative:
dt = new DataTransferItemList();
dt.add(hello, text/plain);
dt.add(span.innerHTML, text/html);
window.copyToClipboard(dt);
This avoids the busywork of creating a DataTransfer in common cases, but
allows using DataTransfer when you want to do something more advanced, like
provide alternatives or explicitly specify a MIME type. Note
that DataTransferItemList isn't actually constructable right now. Note
that I used DataTransferItemList in the example and not DataTransfer, since
DataTransfer is only relevant to drag-and-drop.
I wonder what the right way to handle images is. Native Windows
applications can copy pixel data to the clipboard, then paste it back out.
DataTransferItem wants things to act like strings, though, so you'd have
to encode the image to a file format. If that's PNG, that's an expensive
conversion. Maybe DataTransferItem should be able to return an ImageSource.
(As an aside, why is the paste event's .clipboardData not set to the text
being pasted? I wanted to see what pasting images did in current browsers,
but at least in Chrome there's nothing in there, even if I just paste plain
text.)
--
Glenn Maynard
Re: contentEditable=minimal
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. Though one interesting edge case there is what happens if the page adjusts the selection as it's being moved to the word autocorrect wants to fix? I'm sorry, I don't understand the case you're thinking of? 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. / Jonas
[webcomponents]: Next weeks telcon agenda
As a reminder, we have our standing meeting next week: https://www.w3.org/wiki/WebComponents/ Please reply to this mail with your agenda topics. I haven't had a chance to work on specs this week, so I don't have any topics. :DG
Re: IndexedDB Proposed API Change: cursor.advance BACKWARD when direction is prev
Thanks for following up! At least two IDB implementers were worried that you'd found some browser bugs we couldn't reproduce. Yup. I had to figure this stuff out as the API is very low level (which is why it can also be used in very powerful ways and also potentially very confusing for the uninitiated) Assuming the store has [1,2,3,4,5,6,7,8,9] and the cursor's range is not restricted, if the cursor's key=7 and direction='prev' then I would expect after advance(2) that key=5. If you're seeing key=2 can you post a sample somewhere (e.g. jsfiddle.com?) In the case I have say 7 items [1,2,3,4,5,6,7] and the cursor's range is restricted by IDBKeyRange.only(val, prev) ... so if the matching (or in range) items are at 7, 6, 4, 2, 1 then I can obtain them individually or in contiguous ranges by advancing the cursor on each consecutive invocation of my search routine, like so: on first invocation advance(1) from 7 to 6, on second invocation advance(2) from 7 to 4, on third invocation advance(3) from 7 to 2 and on fourth invocation advance(4) from 7 to 1. I could also use advance to advance by 1 within each invocation until no matching items are found but only up to 2 times an invocation (for a store with 700 or 7 items we can advance by 1 about 200 times per invocation, but that's arbitrary) I can definitely post a jsfiddle if you believe the above is not in accordance with the spec. As to continue(n) or continue(any string), i would make that .find(something) On Fri, May 23, 2014 at 10:41 AM, Joshua Bell jsb...@google.com wrote: On Fri, May 23, 2014 at 9:40 AM, marc fawzi marc.fa...@gmail.com wrote: I thought .continue/advance was similar to the 'continue' statement in a for loop in that everything below the statement will be ignored and the loop would start again from the next index. So my console logging was giving confusing results. I figured it out and it works fine now. Thanks for following up! At least two IDB implementers were worried that you'd found some browser bugs we couldn't reproduce. For sanity's sake, I've resorted to adding a 'return' in my code in the .success callback after every .advance and .continue so the execution flow is easier to follow. It's very confusing, from execution flow perspective, for execution to continue past .continue/.advance while at once looping asynchronously. I understand it's two different instances of the .success callback but it was entirely not clear to me from reading the docs on MDN (for example) that .advance / .continue are async. Long term, we expect JS to evolve better ways of expressing async calls and using async results. Promises are a first step, and hopefully the language also grows some syntax for them. IDB should jump on that train somehow. Also, the description of .advance in browser vendor's documentation, e.g. on MDN, says Advance the cursor position forward by two places for cursor.advance(2) but what they should really say is advance the cursor position forward by two results. For example, let's say cursor first landed on an item with primary key = 7, and you issue the statement cursor.advance(2), I would expect it to go to the item with primary key 5 (for cursor direction = prev) but instead it goes to the item with primary key 2 because that's the 2nd match for the range argument from the cursor's current position What range argument are you referring to? Assuming the store has [1,2,3,4,5,6,7,8,9] and the cursor's range is not restricted, if the cursor's key=7 and direction='prev' then I would expect after advance(2) that key=5. If you're seeing key=2 can you post a sample somewhere (e.g. jsfiddle.com?) , which means that .advance(n) would be far more clear semantically speaking if it was simply done as .continue(n) ... I guess if there is an understanding that the cursor is always at a matching item and that it could only continue/advance to the next/prev matching item, not literal 'positions' in the table (i.e. sequentially through the list of all items) then there would be no confusion but the very concept of a cursor is foreign to most front end developers, and that's where the confusion comes from for many. My inclination as a front end developer, so far removed from database terminology, would be 1) to deprecate .advance in favor of .continue(n) and continue(n) already has meaning - it jumps ahead to the key with value n 2) if it makes sense (you have to say why it may not) have .continue()/.continue(n) cause the return of the execution flow similar to 'continue' in a for loop. The API can't change the language - you return from functions via return or throw. Further, there are reasons you may want to do further processing after calling continue() - e.g. there may be multiple cursors (e.g. in a join operation) or for better performance you can call continue() as early as possible so that the database can do its work while you're processing the
