[Bug 25853] intentionally constraints

2014-06-20 Thread bugzilla

Anne ann...@annevk.nl changed:

   What|Removed |Added

 Resolution|--- |FIXED

--- Comment #2 from Anne ann...@annevk.nl ---

You are receiving this mail because:
You are on the CC list for the bug.

[Bug 26153] New: Allow ArrayBuffer as argument to send()

2014-06-20 Thread bugzilla

Bug ID: 26153
   Summary: Allow ArrayBuffer as argument to send()
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: XHR
  Assignee: ann...@annevk.nl
  Reporter: ann...@annevk.nl
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Depends on: 23369, 24072

Given that most APIs allow both views an raw buffers, there's not really any
good argument left for XMLHttpRequest to be different here.

You are receiving this mail because:
You are on the CC list for the bug.

PFWG request for abstract and introductions

2014-06-20 Thread Michael Cooper
The WAI Protocols and Formats Working Group has looked at a number of 
specifications published by the Web Applications Working Group recently. 
Our process is to note the publication of documents and take a quick 
look to determine if they need a closer review. However, many of the 
documents we have looked at recently have extremely brief abstracts, and 
no introductions. This makes it very difficult for us to figure out the 
nature of the specification, and in turn to determine what our interest 
in it might be.

We request that you add more complete abstracts to the specifications, 
to provide a high-level but more complete idea of what the specification 
does. We also request that you add introduction sections to the 
specifications, to explain what problem the technology solves and how 
(in general terms) it addresses that. We think this will aid our own 
review and will also greatly help other reviewers to make useful comments.

Michael Cooper
PFWG staff contact

[editing] Recurring Call (was: Best Time for Recurring Call)

2014-06-20 Thread Ben Peters
This call has now been reserved [3] for Friday at 8am San Francisco Time. It 
will not be used every week, but only as needed. In order to allow maximum 
participation, please make a request on this list 1 week prior to the call time 
whenever a call would be valuable. Thanks!


[3] https://www.w3.org/Guide/1998/08/teleconference-calendar#s_6399 

 -Original Message-
 From: Ben Peters [mailto:ben.pet...@microsoft.com]
 Hello Web Apps,
 Our recent call [1] regarding HTML Editing (contentEditable, CommandEvent)
 was quite valuable. It seems valuable to have a time reserved for future 
 though it will likely not be used every week. If you are interested in
 participating, please fill out the Doodle poll below to indicate what times
 work best for you. The poll contains Pacific Daylight Times 8-10am and 5-6pm
 (converter available [2]), Monday-Friday. Ignore the specific dates because
 the call will be used as-needed for any given week, with at least 48 hours
 advance notice (typically 7 days). This poll will close June 18th.
 Ben Peters
 [1] http://lists.w3.org/Archives/Public/public-

Re: [editing] Changing Default Intentions

2014-06-20 Thread Ryosuke Niwa

On Jun 17, 2014, at 6:08 PM, Ben Peters ben.pet...@microsoft.com wrote:
 Instead of execCommand, we could find another way to declare user intentions 
 (shown in the image [1] upper right). To change a keyboard shortcut we could 
 have a new property, say KeyboardEvent.intention. It could be initialized if 
 a CommandEvent would normally fire, like bold on control+b. And it could be 
 modified like this:
 function handleKeydown(evt) {
 if (evt.key == “b”  evt.ctrlKey) {
 evt.intention=‘backcolor’; // causes command event type 
 backcolor and stops default command event type bold


This design might pose an issue in WebKit if the intention is supposed to 
return the corresponding editing behavior on getting because we wouldn't know 
it for a given key event until the default event handler is called.

Maybe we can add a method instead? e.g. event.setExecCommand();

 For buttons we could do the following, which would cause a CommandEvent to 
 fire when the button is activated.
 input type=”button” command=”bold” value=”b”
 Another option would be a series of methods like those suggested previously 
 [2], such as window.clipboard.copy causing a copy IntentionEvent 
 (ClipboardEvent) and document.getSelection().modify causing a 
 BeforeSelectionChange Intention event.
 Using execCommand to actually execute a command:
 This means execCommand is available for other uses. Since it’s a legacy API 
 that doesn’t have the best shape, perhaps it is best to tie it to the legacy 
 behavior. So the image [1] now shows that execCommand (lower right) would 
 cause the browser to actually perform the command, not fire a CommandEvent. 
 In effect, execCommand(‘bold’) is the default behavior for CommandEvent type 
 bold in contentEditable=”true”. In contentEditable=”minimal” or equivalent, 
 CommandEvent type bold has no default. If a site wishes to use the built-in 
 bold, they can call execCommand(‘bold’) in the CommandEvent, thereby 
 restoring contentEditable=”true” behavior for that specific command.

execCommand not triggering command event seems like a promising approach.  I 
think we really need a concrete list of use cases here though.  It's hard to 
design  evaluate proposals without having a list of concrete use cases against 
which we're evaluating proposals.

- R. Niwa

Re: [editing] Changing Default Intentions

2014-06-20 Thread Ryosuke Niwa
On Jun 17, 2014, at 7:31 PM, Yoshifumi Inoue yo...@chromium.org wrote:

 For overriding keyboard shortcut, how about exposing browser's key binding 
 map as API rather than handling keyboard event?
 window.keymap['Ctrl+B'] = function() { document.execCommand('back color'); }

I don't think this is a much improvement from the status quo of handling 
keydown event manually.  If anything, what we need to be solving here is the 
problem such as Ctrl+B behaving like Cmd+B on Mac and yet another platform may 
have another convention.

We should design API such that authors don't have to manually hard code each 
and every platform's convention.

 window.keymap also contains accesskey. So, editor library can notify or 
 avoid overriding page defined shortcut
 // This can be done by document.querySelectorAll(*[accesskey]) though

I don't follow what you're trying to say here.  Could you clarify what problem 
you're trying to solve?

- R. Niwa

Re: [editing] Leading with ContentEditable=Minimal

2014-06-20 Thread Ryosuke Niwa

On Jun 17, 2014, at 1:44 PM, Julie Parent jpar...@google.com wrote:

 On Tue, Jun 17, 2014 at 12:22 PM, Olivier F teleclim...@gmail.com wrote:
 On Mon, Jun 16, 2014 at 5:48 PM, Julie Parent jpar...@google.com wrote:
 On Mon, Jun 16, 2014 at 5:23 PM, Ben Peters ben.pet...@microsoft.com wrote:
 On Mon, Jun 16, 2014 at 5:12 PM, Julie Parent jpar...@google.com wrote:
  If Intention events are (temporarily) moved out of scope,
 I don’t think I’d say they’re out of scope, just that they will likely not be 
 ready as quickly as we could do contentEditable=’minimal’. Do you agree with 
 Agreed in general, but it would depend on how contentEditable='min' is 
 actually defined. 
  I think this leads us back to the question of what would 
  contentEditable='minimal' do exactly?  Enable collapsed selections and 
  default handling of cursor movement ... anything else?
 Yes we need to define this default functionality. What does everyone think 
 about this?
  If this is all it would do, then perhaps what we really want is an explicit 
  API to enable cursors?
 I think we should still think of this as a path to a full story that includes 
 Intention events. Are you saying that ultimately we would have something like 
 div cursor=”true” commandEvents=”true”minimally editable content/div
 Like all other content, this would also get drag/drop, clipboard, and 
 selection events. We would need 3 specs for this- Selection API, minimal 
 editing (cursor-only editing?), and CommandEvent.
 Yes. I really like the idea of explicitly enabling what you want and of 
 separating the concepts.  Being able to turn on commandEvents independent of 
 a cursor seems useful.  An API like this leaves far fewer questions of what 
 does it do? than contentEditable=minimal.  What does cursor=true do? It 
 turns on the ability for the user or developer to place a cursor, and default 
 movement.  It has nothing to do with dom modification.  What does 
 commandEvents=true do? It enables dispatching commandEvents.  No ambiguity. 
  However, this does make me think again about using beforeinput/input events 
 rather than adding new CommandEvents, since those would include drag/drop and 
 clipboard as well?
 I really like cursor=true. 
 I'm more confused about commandEvents=true as a separate attribute. 
 - Do CommandEvents make any sense without a cursor? In particular, how does 
 end-user focus an area that has commandEvents=true if there is no cursor?
 An app can have a cursor that isn't a native browser cursor.  For example, 
 Google Docs does not use native browser cursors and draws their own, so that 
 they can show multiple cursors for collaborators and control selections 
 entirely the way they want.  They have to use a hidden focused 
 contentEditable region in order to get all the events they need now, but it 
 would be a much nicer solution for them to simply enable the events.

How does that work in mobile?  iOS for example shows lollipops at the end of 
selections to trigger editing actions such as copy, paste, etc... if a web 
content was drawing its own cursor, then these UIs can't be shown for the user. 
 It seems to me that what they want is to use the native cursor and do every 
editing operation themselves.

I'm also not certain how we're going to expose an element with cursor=true but 
commandEvent=false or cursor=false but commandEvent=true to an assistive 

- R. Niwa

Re: [editing] CommandEvent and contentEditable=minimal Explainer

2014-06-20 Thread Ryosuke Niwa

On Jun 17, 2014, at 9:00 AM, Piotr Koszuliński p.koszulin...@cksource.com 

 On Tue, Jun 17, 2014 at 2:39 AM, Julie Parent jpar...@google.com wrote:
 I certainly understand the concern that it would be impossible to properly 
 catch and cancel all events.
 I'm not concerned only about this. I'm concerned about the fact that 
 currently existing commands and editable-related features does not fit in a 
 simple command APIs.
  But I think that is somewhat the point - it forces browser vendors to get 
 these parts right.
 The spec should guide engines' developers, because there's a single spec and 
 many engines. Even if all browser vendors will get these parts right, they 
 may choose different paths. And then, in general, this will be not right and 
 it will be a pain for developers.
  All changes to an editable dom must fire an event before the modifications 
 are made, and must be cancelable. Further, I'd say that if the number of 
 events you would need to preventDefault on grows larger than selection, 
 command, and maybe clipboard then that implies that we are not building the 
 right APIs.
 I don't think that number of events implies that we are building a bad API. 
 Dozen of well defined events is better than three that do too much in an 
 unclear way.
 Besides that, as an editor author I'm not only interested in preventing 
 default action of features I don't want. I also want to hide them - remove 
 them from browser UI like context menus, menu bar, or other widgets like 
 special toolbar appearing over contenteditable on iOS. This makes the 
 situation which spec has to describe much more complex. That's why I think 
 it's better to focus on basics 
 than on trying to make specification for every feature that was introduced in 
 any engine in any away.

This makes me think that we want something like a white list of editing 
features to enable in a given editable element or perhaps * to enable them all.

e.g. div contenteditable=inline-style copy paste dragdrop/div

- R. Niwa