RE: contentEditable=minimal
> From: Robin Berjon [mailto:ro...@w3.org] > > 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). > Agree. One way to do this would be BeforeSelectionChange having a commandType indicating select forward and select by word. > > 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). Yes please:) Cursor and selection are the same thing. > > 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 you'll get > wrong for the user as they are platform specific). As seen in the code > gist I posted, given such a delete event the scripting is pretty simple. I agree, except that I don't know why we want paste to fire two 'intention' events (paste and input). Seems like we should make it clear that the intention is insert text (type, voice, whatever), remove text (delete, including what text to remove), or paste (so you can clean it up). -Ben
RE: contentEditable=minimal
> -Original Message-
> From: Robin Berjon [mailto:ro...@w3.org]
>
> 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.
>
I believe Composition Events are very important for IME input, but we should
fire CommandEvent with Insert text for all text input, including IME. Are you
saying we should use Composition Events even for non-IME input?
RE: contentEditable=minimal
> -Original Message- > From: Robin Berjon [mailto:ro...@w3.org] > Sent: Monday, May 26, 2014 1:41 AM > To: Norbert Lindenberg > Cc: Jonas Sicking; Piotr Koszuliński; Ben Peters; public-webapps > Subject: Re: contentEditable=minimal > > On 26/05/2014 05:43 , Norbert Lindenberg wrote: > > On May 23, 2014, at 5:19 , Robin Berjon wrote: > >> 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). > > > > 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". > > If that turns out not to be the case and we can stick to single-range > selections, > it would certainly make the Selection API simpler. > 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.
RE: contentEditable=minimal
>>> 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. > >On iOS the contextual toolbar not only contains copy/cut options which are of >course ok, but it also contains bold, italic and lists buttons. That's >unacceptable and I assume this kind of native UI will not be implemented for >cE=minimal. The goal of Command Event is to make this a non-issue. If sites respond to bold/italic/list commands they can handle this UI just fine. Are you concerned that a site may not use bold so the button would have no effect?
[manifest] Update and call for review
Hi, Quick update: the Editors have closed off all "V1" bugs for [manifest] and implementations in Blink and Gecko are underway. A thorough review of [manifest] by interested parties would be greatly appreciated! You can file bugs in our GitHub [bug tracker]. We now have the option to cherry-pick V2 features to either spin off into separate specs or to add to the current document. You can view the V2 features at [V2]. See also the [CSP-member], which is already in its own spec. Devs and implementers, please let us know which V2 features should be prioritized. I've also sent the spec (and [CSP-member]) for a security review to: * public-webappsec * public-web-security Thanks! [manifest] http://w3c.github.io/manifest/ [bug tracker]https://github.com/w3c/manifest/issues [V2] https://github.com/w3c/manifest/issues?labels=V2&page=1&state=open [CSP-member] https://github.com/w3c/manifest-csp/ -- Marcos Caceres
Re: [webcomponents]: Next weeks telcon agenda
Since we had no topic suggestions, let's cancel the call this week. :DG< On Fri, May 23, 2014 at 12:36 PM, Dimitri Glazkov wrote: > 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: contentEditable=minimal
On May 23, 2014, at 5:19 , Robin Berjon wrote: > 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). Were any speakers of bidirectional languages in the room when this was discussed? Norbert
Last Call for "CSS Font Loading Module Level 3"
Dear fellow chairs, The CSS WG decided to issue a last call for: Title: CSS Font Loading Module Level 3 URL: http://www.w3.org/TR/css-font-loading-3/ Editors' draft: http://dev.w3.org/csswg/css-font-loading/ Abstract: This CSS module describes events and interfaces used for dynamically loading font resources. CSS is a language for describing the rendering of structured documents (such as HTML and XML) on screen, on paper, in speech, etc. The document was published on the 22nd of may during our ftf meeting in Korea, with a deadline for comments of 30 june. Sorry I could not send the announcement before, I was traveling. The changes from last WD are listed at: http://www.w3.org/TR/2014/WD-css-font-loading-3-20140220/#changes We'd like to especially ask the following groups for a review: - WebApps - WebFonts If you plan to send in a review, but need more time, let us know.
Re: Should minimal contentEditable default text input
On 26/05/2014 10:25 , Anne van Kesteren wrote: On Mon, May 26, 2014 at 4:17 AM, Yoshifumi Inoue wrote: Range.style is cool idea! I assume Range.detach() removes styles added Range.style. detach() is a no-op. http://dom.spec.whatwg.org/#dom-range-detach You're jumping in without context. In talking about Range.style you need a way of clearing that style once attached. Range.detach() was suggested as a possible candidate there To implement text composition with this, I would like to have "wave underline", "dotted underline", "thick underline" etc. Range.prototype.style seems complex in the context of overlapping ranges and such. Suddenly you're no longer applying CSS to a tree. So, since Gecko supports that, do you know how it's done? -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: contentEditable=minimal
On 26/05/2014 05:43 , Norbert Lindenberg wrote: On May 23, 2014, at 5:19 , Robin Berjon wrote: 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). 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". If that turns out not to be the case and we can stick to single-range selections, it would certainly make the Selection API simpler. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: Should minimal contentEditable default text input (was: contentEditable=minimal)
On Mon, May 26, 2014 at 4:17 AM, Yoshifumi Inoue wrote: > Range.style is cool idea! I assume Range.detach() removes styles added > Range.style. detach() is a no-op. http://dom.spec.whatwg.org/#dom-range-detach > To implement text composition with this, I would like to have "wave > underline", "dotted underline", "thick underline" etc. Range.prototype.style seems complex in the context of overlapping ranges and such. Suddenly you're no longer applying CSS to a tree. -- http://annevankesteren.nl/
[Bug 25540] Invalid use of [EnsureUTF16]
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25540 Anne changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Anne --- Please don't reopen my bugs. -- You are receiving this mail because: You are on the CC list for the bug.
