Re: contentEditable=minimal

2014-05-28 Thread Piotr Koszuliński
On Tue, May 27, 2014 at 11:01 AM, Robin Berjon ro...@w3.org wrote:

 On 25/05/2014 20:40 , Piotr Koszuliński wrote:

 Making some things unselectable might also be useful. IE has
 unselectable, there's also -moz-user-select and friends. But this is
 small fries for later I'd reckon.

 There are also nested non-editable islands. We built very important
 feature based on them - http://ckeditor.com/demo#widgets. Currently we
 block their selection by preventing mousedown and we handle left/right
 arrows. But cancelling selectionchange would allow us to control more
 cases in a cleaner way.


 I'd be curious to know what your take is on the best way to expose this.
 IE has an unselectable attribute, whereas Gecko and WebKit have a CSS
 property. In this thread we've been talking about using cancellable events
 for this (or if not cancellable, ones in which the selection can be
 modified on the fly).

 On instinct I would tend to think that this not a great usage of CSS, it's
 much more tied to behaviour at a lower level. But it sort of is one of
 those borderline things (as many of the properties that initially came from
 the CSS UI module).

 The scriptable option that we're consider is good in that it enables
 arbitrary cases, but it could be interesting to support a number of cases
 out of the box with a simpler (for developers) approach.

 Let's imagine the following DOM:

 div contenteditable=minimal
   pblah blah blah/p
   div class=widget unselectable.../div
   pblah blah blah/p
 /div

 If the cursor is at the beginning of the first p, you hold Shift, and
 click at the end of the second p, we could imagine that you'd get a
 Selection with two Ranges (one for each p) and not containing the
 unselectable widget. I *think* that's the most desirable default behaviour,
 and it's also one that can be pretty painful to control through script. In
 that sense an unselectable attribute would make sense. (I reckon that
 setting the widget to be cE=false would have the same effect, but it is
 nevertheless an orthogonal property.)

 WDYT?


My previous email might be confusing because I mentioned only that CKEditor
handles mousedown event. Actually, this is a tip of an iceberg :). I think
that it may be an interesting case, because we were forced to overwrite
most of browser behaviours when implementing the widget system. Also, this
case is so complex that it's easier to start from what we experienced
rather than saying that if X and Y will be possible, then our needs will be
satisfied. I hope you forgive me this laziness :)

The main requirements for the widget system were:

1. User must not be able to modify a non-editable part of widget.
2. Widget must be selectable as a whole (like an image).
 3. Widget may contain editable fragments (nested editables).
4. There are block and inline widgets (surprisingly important requirement).
5. Widget may contain other widgets in its nested editables. So widgets may
be nested multiple times.
6. Widget must be selectable by click, arrow keys, etc. It also has to be
deletable by backspace/delete and copyable by CTRL+C.

This is a structure that we used:

div contenteditable=true !-- editor's main editable --
   pfoo/p
  div contenteditable=false !-- widget wrapper --
p contenteditable=truenested editable/p
pnon-editable content/p
div contenteditable=true
   panother nested editable/p
/div
  /div
  pfoo2 span contenteditable=falseinline widget/span/p
/div

Why did we choose contenteditable=false? At the beginning it was simply
intuitive. We don't fully control the interaction methods (mouse, keyboard,
selection), so let browser do that. Then we overwrote most of the
interaction methods so currently the attribute is not so crucial. However,
there's one aspect of interaction which we cannot control and I'm not sure
if we'll ever be able - dynamically changing selection (its visual and
logical aspect) around block widgets, their nested editables and a special
case that complicates all this - blocks may be floated. Let's try to
imagine how we could handle selection without using contenteditable=false.

pfoo/p
div class=widgetwidget/div
pbar/p

TC1:
User clicks main editable's margin, on the side of the block widget. If he
clicks closer to the top of the widget, we would like to place caret at the
end of preceding editable block (foo^), and when closer to bottom, then in
the following block (^bar). Without checking dimensions, that would not be
doable, because browser would suggest a selection inside divwidget/div.
On the other hand, we could consider always selecting entire widget if
selection was proposed inside it. This seems to be a good option,
especially taking into account that we may have multiple block widgets one
after another, and then you cannot place selection between them anyway.

TC2:
Another aspect is selection normalisation. When we make a decision that
entire block widget should be selected we want to be able to anchor the
selection 

Re: [manifest] Update and call for review

2014-05-28 Thread Ben Francis
As per our conversation in IRC, something else I'd like to highlight is the
fact that in the current version of the spec any web site can host an app
manifest for any web app. That means for example that I could create my own
app store for web apps and provide a listing for a GMail app which users
can add to their homescreen, without any involvement from Google.

It would be good to hear some opinions on whether it is a good thing or a
bad thing that manifests don't have to be served from the same origin as
the web app itself.


Re: [manifest] Fetching restriction, Re: [manifest] Update and call for review

2014-05-28 Thread Ben Francis
On Tue, May 27, 2014 at 5:11 PM, Marcos Caceres w...@marcosc.com wrote:


 The only way one could do what you describe would be for my own app
 store to host its own manifests. So:
 http://myownappstore.com/gmail/index.html

 Would contain:
 link rel=manifest
 href=http://myownappstore.com/gmail/manifest.json;

 Which would have:

 {
name: Gmail
start_url: http://gmail.com;
 }

 This would allow custom stores that provide tailored app experiences for
 sites that lack manifests.

 Where this could become a problem in the future is if manifests start
 granting elevated privileges (e.g., access to specific APIs or unlimited
 storage). However, the security model could then be refined so that, for
 instance, only same origin manifests that are served over HTTPS get special
 powers. In such a case, non-same-origin manifests could be tainted and
 only the basic metadata from the manifest would be used by the user agent.


To be clear, this is the case I was talking about. The benefit is that it
makes it much easier to build a large app store of tailored app
experiences for sites that lack manifests without the involvement of app
authors themselves. For example, everything.me may have a larger catalogue
of web apps than the Firefox Marketplace because the latter requires
same-origin manifests and for app authors to submit their own apps, whereas
the former doesn't require any involvement from app authors themselves.

One risk of allowing cross-origin manifests might be that these tailored
app experiences are perceived by the actual app author and/or end users as
a fake app masquerading as the real thing. In the longer term when
additional features are added to the manifest there could be additional
risks.

That is why I'm interested in feedback on whether this is a desirable
feature or not.


Re: [manifest] Update and call for review

2014-05-28 Thread Ben Francis
On Mon, May 26, 2014 at 8:18 PM, Marcos Caceres w...@marcosc.com wrote:

 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].


Nice work! FYI I expect implementation in the Firefox OS browser to be
tracked here https://bugzilla.mozilla.org/show_bug.cgi?id=1003890



 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.


To me the biggest issues for v2 are:

URL Scope to which the manifest applies
https://github.com/w3c/manifest/issues/114

Specify how navigation works
https://github.com/w3c/manifest/issues/142

which I think are all part of the same issue of app scope.

The specification describes a manifest whose properties can be used when
bookmarking a web app and effect how that bookmark should be displayed by
the user agent when it is launched (e.g. in a standalone window in
landscape orientation with no navigation controls). But it does not specify
the URL scope to which those properties apply. For example, what display
mode the user agent should use when the browsing context is navigated away
from the start_url, or away from the origin entirely to another unrelated
web site.

In other words, what is the scope of the app?

All the specification has to say on this topic is The user agent MAY
override the default display mode for security reasons (e.g., the top-level
browsing context is navigated to another origin). But this doesn't include
navigational reasons (e.g. getting stranded on another web site without a
back button) or the case of multiple origins per app or multiple apps per
origin.

In Firefox OS the user can get stranded by following a hyperlink from an
installed app to an off-origin web page with no back button and no
indication that they have left the origin.

Chrome for Android will show the new origin at the top of the screen if you
navigate outside the origin in a mobile-web-app-capable homescreen
bookmark, but it won't provide browser chrome.

In Chrome OS if you open the Google search app as a window and click on a
search result, it will navigate you to the result web page but not provide
any browser chrome for the web site.

I think a particular problem with having no defined scope for apps is when
you want to hyperlink from one web app to another. A hyperlink with no
specified target window will always open in the browsing context of the
current app, regardless of whether the URL belongs to another app or web
site. That means that the level of browser chrome you get when following a
hyperlink (as well as the orientation of the page and the title and icon
shown in the task switcher etc.) depends on where you navigated from rather
than where you navigated to.

I would like to see some way to define the scope to which an app manifest
applies, so that the user agent knows which URLs belong to which apps and
therefore what display properties to use for a given URL.


[Bug 25908] New: Is element editable if it's hidden

2014-05-28 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25908

Bug ID: 25908
   Summary: Is element editable if it's hidden
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: HTML Editing APIs
  Assignee: a...@aryeh.name
  Reporter: p.koszulin...@cksource.com
QA Contact: sideshowbarker+html-editing-...@gmail.com
CC: m...@w3.org, public-webapps@w3.org

https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#editable

What if element has contenteditable=true attribute but it's hidden. E.g.:

div style=display:none
  div contenteditable=trueAm I editable?/div
/div

AFAIK Blink and Webkit sets isContentEditable to false on such attributes and
in my opinion it makes sense - especially for editing hosts. Firefox and IE
leaves isContentEditable true and therefore it would be good if this case was
explained in specification.

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



Re: [manifest] Fetching restriction, Re: [manifest] Update and call for review

2014-05-28 Thread Anne van Kesteren
On Tue, May 27, 2014 at 9:53 PM, Marcos Caceres w...@marcosc.com wrote:
 On May 27, 2014 at 3:31:15 PM, Ben Francis (bfran...@mozilla.com) wrote:
 One risk of allowing cross-origin manifests might be that these
 tailored app experiences are perceived by the actual app author
 and/or end users as a fake app masquerading as the real thing.
 In the longer term when additional features are added to the manifest
 there could be additional risks.

 That is why I'm interested in feedback on whether this is a desirable
 feature or not.

 That's a very good summary of both the use case and the problems. I'm also 
 interested in hearing feedback. As Ben makes clear, same-origin basically 
 kills installations from custom stores.

Wait what? Man-in-the-middling someone's content is not a use case.


-- 
http://annevankesteren.nl/



Re: [manifest] Update and call for review

2014-05-28 Thread Anne van Kesteren
On Tue, May 27, 2014 at 3:25 PM, Ben Francis bfran...@mozilla.com wrote:
 As per our conversation in IRC, something else I'd like to highlight is the
 fact that in the current version of the spec any web site can host an app
 manifest for any web app. That means for example that I could create my own
 app store for web apps and provide a listing for a GMail app which users can
 add to their homescreen, without any involvement from Google.

 It would be good to hear some opinions on whether it is a good thing or a
 bad thing that manifests don't have to be served from the same origin as the
 web app itself.

I don't understand this. That would you mean you'd have to modify the
content of Gmail to point to this manifest. That sounds bad.


-- 
http://annevankesteren.nl/



Re: [manifest] Fetching restriction, Re: [manifest] Update and call for review

2014-05-28 Thread Mounir Lamouri
On Wed, 28 May 2014, at 8:59, Jonas Sicking wrote:
 On Tue, May 27, 2014 at 12:39 PM, Marcos Caceres w...@marcosc.com wrote:
 
 
  On May 27, 2014 at 2:30:32 PM, Jonas Sicking (jo...@sicking.cc) wrote:
  On Tue, May 27, 2014 at 9:11 AM, Marcos Caceres wrote:
   The only way that gmail would allow my own app store to use its 
   manifest would be for
  Google to include the HTTP header:
  
   Access-Control-Allow-Origin: http://myownappstore.com;
 
  This is a bit of an abuse of CORS.
 
  hmmm... I thought this was *exactly* the point of having the 
  *-Allow-Origin header (restrict sharing to the domains the server chooses 
  in browsers).
 
  Adding an
  Access-Control-Allow-Origin: * header currently has the semantic
  meaning of any website can read the contents of this file. I.e. it
  only means that the bits in the file are accessible from other
  websites.
 
  Yep. The point was that combined with the `start_url` member, you can make 
  install pages away from the origin where the application resides.
 
  That means that for a webserver on the public internet it is currently
  always safe to add the Access-Control-Allow-Origin: * header to any
  file since all files can be read anyway by simply using a different
  HTTP client than a browser, such as wget.
 
  Sure. But that's not the point here. The use of CORS here is to control who 
  can do what within the context of the browser (as the policy enforcement 
  point). Of course, anyone can just go and download  anything with wget or 
  whatever - but that's not going to give that person a web app with the 
  manifest applied.
 
 So let's start by asking this: What are you trying to protect against
 by using CORS at all? Rather than using the policy that img uses.
 
 If the *only* thing you are trying to protect is the actual bytes in
 the manifest itself, then CORS is indeed the right solution.

This is exactly what I was going to ask: I'm not sure what is the
benefit of CORS restricted manifest fetching if we allow the manifest
start_url to point to a cross origin URL. As is, the manifest doesn't
contain sensitive data. It is only metadata that aren't user-specific
and should be fairly public (at least as public as the website is). In
that regards, the only benefit from enforcing CORS restrictions on the
manifest fetching I think is to be safe and future-proof (if the
manifest ends up having sensitive stuff in it, we don't need to break
all the things).

This said, I think that start_url should be same origin as the manifest.
It sounds very odd to navigator to foo.com, fetch foo.com/manifest.json
and then ends up going to bar.com when I try to navigate again to the
foo.com page via my bookmark. It might not make much sense for the user
and the confusion could lead to attach scenarios. I would be more
comfortable to have everything in the manifest being same origin as the
manifest itself.

Then, it might make sense to have the manifest same origin as the web
page because obviously making start_url same origin as the manifest
would be moot if the manifest doesn't have to be same origin with the
web page ;)

-- Mounir



Re: [manifest] Fetching restriction, Re: [manifest] Update and call for review

2014-05-28 Thread Anne van Kesteren
On Wed, May 28, 2014 at 12:20 PM, Mounir Lamouri mou...@lamouri.fr wrote:
 Then, it might make sense to have the manifest same origin as the web
 page because obviously making start_url same origin as the manifest
 would be moot if the manifest doesn't have to be same origin with the
 web page ;)

I think we have a winner.


-- 
http://annevankesteren.nl/



Re: [manifest] Update and call for review

2014-05-28 Thread Ben Francis
On Wed, May 28, 2014 at 9:39 AM, Anne van Kesteren ann...@annevk.nl wrote:

 I don't understand this. That would you mean you'd have to modify the
 content of Gmail to point to this manifest. That sounds bad.


To quote Marcos:

The only way one could do what you describe would be for my own app store
 to host its own manifests. So:
 http://myownappstore.com/gmail/index.html

 Would contain:
 link rel=manifest
 href=http://myownappstore.com/gmail/manifest.json;

 Which would have:

 {
name: Gmail
start_url: http://gmail.com;
 }

 This would allow custom stores that provide tailored app experiences for
 sites that lack manifests.


This is the scenario I was describing. Allowing this to happen has both
benefits (easy to build huge app stores!) and risks (easy to build fake
apps).

But it sounds as though more people are arguing for the manifest URL and
start URL to be required to be same-origin as each other, which would
prevent this scenario from happening.


Re: [manifest] Update and call for review

2014-05-28 Thread Anne van Kesteren
On Wed, May 28, 2014 at 12:43 PM, Ben Francis bfran...@mozilla.com wrote:
 This is the scenario I was describing. Allowing this to happen has both
 benefits (easy to build huge app stores!) and risks (easy to build fake
 apps).

That seems very confusing UI-wise. Also, this is the web, we don't
need app stores.


-- 
http://annevankesteren.nl/



Re: [manifest] Fetching restriction, Re: [manifest] Update and call for review

2014-05-28 Thread Marcos Caceres
On Wednesday, May 28, 2014, Anne van Kesteren ann...@annevk.nl wrote:

 On Wed, May 28, 2014 at 12:20 PM, Mounir Lamouri 
 mou...@lamouri.frjavascript:;
 wrote:
  Then, it might make sense to have the manifest same origin as the web
  page because obviously making start_url same origin as the manifest
  would be moot if the manifest doesn't have to be same origin with the
  web page ;)

 I think we have a winner.


Yep! Will update the spec. Thanks for all the good input.




 --
 http://annevankesteren.nl/




[Bug 24338] Spec should have Fetch for Blob URLs

2014-05-28 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24338
Bug 24338 depends on bug 25081, which changed state.

Bug 25081 Summary: Make read operation really async
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25081

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

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



[Bug 25081] Make read operation really async

2014-05-28 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25081

Arun a...@mozilla.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #36 from Arun a...@mozilla.com ---
(In reply to Anne from comment #35)
 1) I think it would be clearer if errors were more closely defined as they
 can only occur here.
 
 2) Errors can occur during the read process as well so catching them upfront
 does not help.
 
 3) For the asynchronous algorithm you do not want to return a value, but
 always queue something I think.

Done.

http://dev.w3.org/2006/webapi/FileAPI/#reading-data-section

Marking fixed.

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



[Bug 25713] Formalize the Blob URL Syntax

2014-05-28 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25713

Arun a...@mozilla.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Arun a...@mozilla.com ---
Done based on listserv discussions.

http://dev.w3.org/2006/webapi/FileAPI/#DefinitionOfScheme
and
http://dev.w3.org/2006/webapi/FileAPI/#unicodeBlobURL

Marking fixed.

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



[Bug 24998] What is the origin of a blob: URL?

2014-05-28 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24998

Arun a...@mozilla.com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from Arun a...@mozilla.com ---
Marking this fixed based on listserv discussions and recent specification
update:

http://dev.w3.org/2006/webapi/FileAPI/#originOfBlobURL

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



[Bug 24338] Spec should have Fetch for Blob URLs

2014-05-28 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24338
Bug 24338 depends on bug 24998, which changed state.

Bug 24998 Summary: What is the origin of a blob: URL?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24998

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

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



RE: [editing] CommandEvent and contentEditable=minimal Explainer

2014-05-28 Thread Ben Peters
Great idea! If Intention Events (Clipboard, Selection, Command) cover all of 
the editing operations that a site would want to handle themselves, we don’t 
need CE Min as a feature, only a concept that can achieved with 
preventDefault().

From: Julie Parent [mailto:jpar...@gmail.com]
Sent: Tuesday, May 27, 2014 4:40 PM
To: Ben Peters
Cc: public-webapps@w3.org
Subject: Re: [editing] CommandEvent and contentEditable=minimal Explainer

The discussion of which minimal default handling to include with 
contenteditable=minimal makes me wonder if contentEditable=minimal is 
necessary at all.  It quickly becomes a can of worms of *which* default 
handling should be included, and it seems likely to not satisfy every use case 
no matter which decisions are made.  However, minimal is proposed as a 
building block because currently, disabling all default functionality of 
contentEditable=true is difficult/impossible.  But with CommandEvents, 
shouldn't contentEditable=minimal be equivalent to:

// Let editRegion be div contentEditable id='editRegion'

var editRegion = document.getElementById(editRegion);
editRegion.addEventListener(command, handleCommand);
function handleCommand(evt){
  evt.preventDefault();
}

No default actions would be taken, but selection events would still fire and be 
handled.  There would be no ambiguity.  If implementing 
contentEditable=minimal on top of CommandEvents could just be a few lines of 
code, why complicate things by spec'ing another property?

Then, if someone wants a region that just does basic text input, then they 
simply allow it:
function handleCommand(evt){
 switch (evt.commandType){
   case 'insertText':
 // Let the browser do text insertion
 break;
   default:
 // Prevent all other magic
 evt.preventDefault();
}

This hedges on the fact that CommandEvents would capture ALL the cases that 
contentEditable currently handles, and that the event would fire BEFORE the dom 
is modified, and that calling preventDefault would cancel the event, but isn't 
that a goal of this design anyway?

Julie

-- Forwarded message --
From: Ben Peters ben.pet...@microsoft.commailto:ben.pet...@microsoft.com
Date: Thu, May 22, 2014 at 4:56 PM
Subject: [editing] CommandEvent and contentEditable=minimal Explainer
To: public-webapps@w3.orgmailto:public-webapps@w3.org 
public-webapps@w3.orgmailto:public-webapps@w3.org


I have completed a first-draft explainer document [1], taking the generous 
feedback of many of you into account. There are 6 open issues on the document 
currently, and I'm sure there are others that I have missed. It would be great 
to know if this is heading in in the right direction.

My vision is to use this a non-normative Explainer, and create 2 normative 
specs to go with it. The specs for contentEditable=minimal and CommandEvent 
should have first-drafts next week.

Thanks!
Ben

[1] http://benjamp.github.io/commands-explainer.htm



RE: [editing] CommandEvent and contentEditable=minimal Explainer

2014-05-28 Thread Travis Leithead
Be careful with having events fire before the DOM is updated—at a minimum 
you’ll want to consider whether you will allow dangerous situations like the 
legacy MutationEvents could cause (start a change - pre-change notification - 
make another change - pre-change notification … unexpected things can happen 
(can be especially challenging to implement securely).

HTML5’s focus event model nicely prevents these recursions from looping. I’ve 
proposed a similar mitigation for the “beforeinput” event of DOM Level 3 
Events: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25683

Seems like the Intention Events, if firing before the change is committed, 
might want a similar mitigation strategy.

From: Ben Peters [mailto:ben.pet...@microsoft.com]
Sent: Wednesday, May 28, 2014 1:40 PM
To: Julie Parent
Cc: public-webapps@w3.org
Subject: RE: [editing] CommandEvent and contentEditable=minimal Explainer

Great idea! If Intention Events (Clipboard, Selection, Command) cover all of 
the editing operations that a site would want to handle themselves, we don’t 
need CE Min as a feature, only a concept that can achieved with 
preventDefault().

From: Julie Parent [mailto:jpar...@gmail.com]
Sent: Tuesday, May 27, 2014 4:40 PM
To: Ben Peters
Cc: public-webapps@w3.orgmailto:public-webapps@w3.org
Subject: Re: [editing] CommandEvent and contentEditable=minimal Explainer

The discussion of which minimal default handling to include with 
contenteditable=minimal makes me wonder if contentEditable=minimal is 
necessary at all.  It quickly becomes a can of worms of *which* default 
handling should be included, and it seems likely to not satisfy every use case 
no matter which decisions are made.  However, minimal is proposed as a 
building block because currently, disabling all default functionality of 
contentEditable=true is difficult/impossible.  But with CommandEvents, 
shouldn't contentEditable=minimal be equivalent to:

// Let editRegion be div contentEditable id='editRegion'

var editRegion = document.getElementById(editRegion);
editRegion.addEventListener(command, handleCommand);
function handleCommand(evt){
  evt.preventDefault();
}

No default actions would be taken, but selection events would still fire and be 
handled.  There would be no ambiguity.  If implementing 
contentEditable=minimal on top of CommandEvents could just be a few lines of 
code, why complicate things by spec'ing another property?

Then, if someone wants a region that just does basic text input, then they 
simply allow it:
function handleCommand(evt){
 switch (evt.commandType){
   case 'insertText':
 // Let the browser do text insertion
 break;
   default:
 // Prevent all other magic
 evt.preventDefault();
}

This hedges on the fact that CommandEvents would capture ALL the cases that 
contentEditable currently handles, and that the event would fire BEFORE the dom 
is modified, and that calling preventDefault would cancel the event, but isn't 
that a goal of this design anyway?

Julie

-- Forwarded message --
From: Ben Peters ben.pet...@microsoft.commailto:ben.pet...@microsoft.com
Date: Thu, May 22, 2014 at 4:56 PM
Subject: [editing] CommandEvent and contentEditable=minimal Explainer
To: public-webapps@w3.orgmailto:public-webapps@w3.org 
public-webapps@w3.orgmailto:public-webapps@w3.org


I have completed a first-draft explainer document [1], taking the generous 
feedback of many of you into account. There are 6 open issues on the document 
currently, and I'm sure there are others that I have missed. It would be great 
to know if this is heading in in the right direction.

My vision is to use this a non-normative Explainer, and create 2 normative 
specs to go with it. The specs for contentEditable=minimal and CommandEvent 
should have first-drafts next week.

Thanks!
Ben

[1] http://benjamp.github.io/commands-explainer.htm



Re: [editing] CommandEvent and contentEditable=minimal Explainer

2014-05-28 Thread Piotr Koszuliński
But what is the default behaviour then? What will we be preventing?
There's no accepted specification for current contentEditable=true AFAIK,
so I thought that the goal of contentEditable=minimal is to avoid the need
to write a specification for contentEditable=true. Otherwise, developers
may demand from browser vendors that they fix their contentEditable=true
implementations and I don't think that anyone wants that. Why not forget
about contentEditable=true, make it deprecated and create specification
only for algorithms needed by contentEditable=minimal and all required
command events?


On Wed, May 28, 2014 at 10:39 PM, Ben Peters ben.pet...@microsoft.comwrote:

  Great idea! If Intention Events (Clipboard, Selection, Command) cover
 all of the editing operations that a site would want to handle themselves,
 we don’t need CE Min as a feature, only a concept that can achieved with
 preventDefault().



 *From:* Julie Parent [mailto:jpar...@gmail.com]
 *Sent:* Tuesday, May 27, 2014 4:40 PM
 *To:* Ben Peters
 *Cc:* public-webapps@w3.org
 *Subject:* Re: [editing] CommandEvent and contentEditable=minimal
 Explainer



 The discussion of which minimal default handling to include with
 contenteditable=minimal makes me wonder if contentEditable=minimal is
 necessary at all.  It quickly becomes a can of worms of *which* default
 handling should be included, and it seems likely to not satisfy every use
 case no matter which decisions are made.  However, minimal is proposed as
 a building block because currently, disabling all default functionality of
 contentEditable=true is difficult/impossible.  But with CommandEvents,
 shouldn't contentEditable=minimal be equivalent to:



 // Let editRegion be div contentEditable id='editRegion'



 var editRegion = document.getElementById(editRegion);

 editRegion.addEventListener(command, handleCommand);

 function handleCommand(evt){

   evt.preventDefault();

 }



 No default actions would be taken, but selection events would still fire
 and be handled.  There would be no ambiguity.  If implementing
 contentEditable=minimal on top of CommandEvents could just be a few lines
 of code, why complicate things by spec'ing another property?



 Then, if someone wants a region that just does basic text input, then they
 simply allow it:

 function handleCommand(evt){

  switch (evt.commandType){

case 'insertText':

  // Let the browser do text insertion

  break;

default:

  // Prevent all other magic

  evt.preventDefault();

 }



 This hedges on the fact that CommandEvents would capture ALL the cases
 that contentEditable currently handles, and that the event would fire
 BEFORE the dom is modified, and that calling preventDefault would cancel
 the event, but isn't that a goal of this design anyway?



 Julie



 -- Forwarded message --
 From: *Ben Peters* ben.pet...@microsoft.com
 Date: Thu, May 22, 2014 at 4:56 PM
 Subject: [editing] CommandEvent and contentEditable=minimal Explainer
 To: public-webapps@w3.org public-webapps@w3.org


 I have completed a first-draft explainer document [1], taking the generous
 feedback of many of you into account. There are 6 open issues on the
 document currently, and I'm sure there are others that I have missed. It
 would be great to know if this is heading in in the right direction.

 My vision is to use this a non-normative Explainer, and create 2 normative
 specs to go with it. The specs for contentEditable=minimal and CommandEvent
 should have first-drafts next week.

 Thanks!
 Ben

 [1] http://benjamp.github.io/commands-explainer.htm






-- 
Piotrek Koszuliński
CKEditor JavaScript Lead Developer


Re: Blob URL Origin

2014-05-28 Thread Arun Ranganathan
On May 22, 2014, at 4:29 AM, Anne van Kesteren ann...@annevk.nl wrote:

 Thanks, I'm convinced.
 
 So now I'd like to know what policy we want so we can carefully define it.


The lastest editor’s draft of the File API specifies what we discussed in this 
email thread as syntax for Blob URLs:

http://dev.w3.org/2006/webapi/FileAPI/#DefinitionOfScheme

and origin, including how to serialize the Blob URL.



 For blob URLs (and prolly filesystem and indexeddb) we put the origin
 in the URL and define a way to extract it again so new
 URL(blob).origin does the right thing.


I wonder if .origin should be static?



 For fetching blob URLs (and prolly filesystem and indexeddb) we
 effectively act as if the request's mode was same-origin. Allowing
 tainted cross-origin requests would complicate UUID (for the UA) and
 memory (for the page) management in a multiprocess environment.


We’re not allowing them.

— A*



CfC: publish Candidate Recommendation of DOM Parsing and Serialization; deadline June 4

2014-05-28 Thread Arthur Barstow

[ Bcc public-webapps; please Reply-to: www-dom]

Two bugs were raised against the May 1 LCWD of DOM Parsing and 
Serialization [LC]. Travis created a tracking document for these Bugs 
[Track] and considers the two patches ([P1] and [P2]) that address the 
comments as non-substantive. As such, he proposes this spec be published 
as a Candidate Recommendation (using the following ED as the basis), and 
this is a Call for Consensus (CfC) to do so:


https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html

This CfC satisfies: a) the group's requirement to record the group's 
decision to request advancement to CR; and b) General Requirements for 
Advancement on the Recommendation Track as defined in [Proc2005].


Travis estimates it will be several months before the [TestSuite] is 
complete and there are at least two implementations that pass each test 
case. Given this, I propose the following CR exit criteria:


[[
This specification will not advance to Proposed Recommendation before 
the spec's a href=test suite/a is completed and two or more 
independent implementations pass each test, although no single 
implementation must pass each test. We expect to meet this criteria no 
sooner than @PubDate+4Months. The group will also create an a 
href=Implementation Report/a.

]]

If anyone has feedback regarding features that should be marked at 
risk, please speak up during this CfC.


Positive response to this CfC is preferred and encouraged and silence 
will be considered as agreeing with the proposal. The deadline for 
comments is June 4 and all comments should be sent to public-webapps @ 
w3.org.


-Thanks, ArtB


[LC] http://www.w3.org/TR/2014/WD-DOM-Parsing-20140501/
[Track] https://dvcs.w3.org/hg/innerhtml/raw-file/tip/LC2_comments.html
[P1] https://dvcs.w3.org/hg/innerhtml/rev/dc7083c47f77
[P2] https://dvcs.w3.org/hg/innerhtml/rev/8dbd8dbdefdc
[TestSuite] http://w3c-test.org/domparsing/
[Proc2005] 
http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs






RE: [editing] CommandEvent and contentEditable=minimal Explainer

2014-05-28 Thread Ben Peters
I don’t think we need to specify the default behavior. We can instead just say 
that all editing behaviors must fire Intention events that are cancellable. Any 
events that are already defined (like Clipboard) will continue to work, and 
others should fire CommandEvents as necessary.

We will likely need to have a list of well-known Command Events (like bold, 
undo, etc) just so we can have a shape for the related CommandData object, but 
we don’t need to specify the default behavior of those events.

From: Piotr Koszuliński [mailto:p.koszulin...@cksource.com]
Sent: Wednesday, May 28, 2014 2:40 PM
To: Ben Peters
Cc: Julie Parent; public-webapps@w3.org
Subject: Re: [editing] CommandEvent and contentEditable=minimal Explainer

But what is the default behaviour then? What will we be preventing? There's 
no accepted specification for current contentEditable=true AFAIK, so I thought 
that the goal of contentEditable=minimal is to avoid the need to write a 
specification for contentEditable=true. Otherwise, developers may demand from 
browser vendors that they fix their contentEditable=true implementations and I 
don't think that anyone wants that. Why not forget about contentEditable=true, 
make it deprecated and create specification only for algorithms needed by 
contentEditable=minimal and all required command events?

On Wed, May 28, 2014 at 10:39 PM, Ben Peters 
ben.pet...@microsoft.commailto:ben.pet...@microsoft.com wrote:
Great idea! If Intention Events (Clipboard, Selection, Command) cover all of 
the editing operations that a site would want to handle themselves, we don’t 
need CE Min as a feature, only a concept that can achieved with 
preventDefault().

From: Julie Parent [mailto:jpar...@gmail.commailto:jpar...@gmail.com]
Sent: Tuesday, May 27, 2014 4:40 PM
To: Ben Peters
Cc: public-webapps@w3.orgmailto:public-webapps@w3.org
Subject: Re: [editing] CommandEvent and contentEditable=minimal Explainer

The discussion of which minimal default handling to include with 
contenteditable=minimal makes me wonder if contentEditable=minimal is 
necessary at all.  It quickly becomes a can of worms of *which* default 
handling should be included, and it seems likely to not satisfy every use case 
no matter which decisions are made.  However, minimal is proposed as a 
building block because currently, disabling all default functionality of 
contentEditable=true is difficult/impossible.  But with CommandEvents, 
shouldn't contentEditable=minimal be equivalent to:

// Let editRegion be div contentEditable id='editRegion'

var editRegion = document.getElementById(editRegion);
editRegion.addEventListener(command, handleCommand);
function handleCommand(evt){
  evt.preventDefault();
}

No default actions would be taken, but selection events would still fire and be 
handled.  There would be no ambiguity.  If implementing 
contentEditable=minimal on top of CommandEvents could just be a few lines of 
code, why complicate things by spec'ing another property?

Then, if someone wants a region that just does basic text input, then they 
simply allow it:
function handleCommand(evt){
 switch (evt.commandType){
   case 'insertText':
 // Let the browser do text insertion
 break;
   default:
 // Prevent all other magic
 evt.preventDefault();
}

This hedges on the fact that CommandEvents would capture ALL the cases that 
contentEditable currently handles, and that the event would fire BEFORE the dom 
is modified, and that calling preventDefault would cancel the event, but isn't 
that a goal of this design anyway?

Julie

-- Forwarded message --
From: Ben Peters ben.pet...@microsoft.commailto:ben.pet...@microsoft.com
Date: Thu, May 22, 2014 at 4:56 PM
Subject: [editing] CommandEvent and contentEditable=minimal Explainer
To: public-webapps@w3.orgmailto:public-webapps@w3.org 
public-webapps@w3.orgmailto:public-webapps@w3.org


I have completed a first-draft explainer document [1], taking the generous 
feedback of many of you into account. There are 6 open issues on the document 
currently, and I'm sure there are others that I have missed. It would be great 
to know if this is heading in in the right direction.

My vision is to use this a non-normative Explainer, and create 2 normative 
specs to go with it. The specs for contentEditable=minimal and CommandEvent 
should have first-drafts next week.

Thanks!
Ben

[1] http://benjamp.github.io/commands-explainer.htm




--
Piotrek Koszuliński
CKEditor JavaScript Lead Developer