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
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.
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
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
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
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
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
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/ -
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
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
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
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
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
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
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
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
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
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,
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.
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
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
21 matches
Mail list logo
