Re: [HTML Imports] What is the imagined work flow?

2014-05-21 Thread Scott Miles 
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:


...


Is  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  wrote:

> Some of the ways Polymer team uses imports are as follows:
>
> - aggregating

RE: where do tests for window.opener go?

2014-05-21 Thread Zhang, Zhiqiang 
> From: Hallvord R. M. Steen [mailto:hst...@mozilla.com]
> Sent: Wednesday, May 21, 2014 4:22 AM
> To: public-webapps
> Subject: [web-platform-tests] where do tests for window.opener go?
> 
> Hi,
> we have a window.opener issue and would like to have some tests for it. I'm
> planning to write some and thought I might as well add them to the web-
> platform-tests suite. Where? Would this be a suitable location:
> https://github.com/w3c/web-platform-
> tests/tree/master/html/browsers/the-window-object/security-window ?
> -HR

For security, yes.

For navigating auxiliary browsing contests in the DOM, better to 
https://github.com/w3c/web-platform-tests/tree/master/html/browsers/windows/auxiliary-browsing-contexts

CfC: to create a new developer's list for WebApps' specs; deadline May 28

2014-05-21 Thread Arthur Barstow 

Hi All,

About two years ago I proposed in [1] creating a new list (f.ex. 
public-webapps-devs) that is targeted toward developers using WebApps' 
specs. Such a list would be used by developers using the APIs (as 
opposed to implementers) as well as other related purposes such as 
announcing relevant meetups, events, conferences, etc.


WDYT?

My personal take is that public-webapps is a bit of a "fire hose" for 
many people that use WebApps' specs so I think a developer oriented list 
would be useful.


All feedback is welcome including explicit signs of support (even just a 
+1 would be helpful and if you don't want to reply to this list that's 
fine, just reply to me and Cc www-arch...@w3.org).


-Thanks, ArtB

[1]

Re: Blob URL Origin

2014-05-21 Thread Anne van Kesteren 
On Tue, May 20, 2014 at 9:24 PM, Jonas Sicking  wrote:
> I think you are confusing issues. Or at least talking about two
> separate issues at once in a way that I'm not sure what you are
> talking about. The issue of "is there an XSS issue with treated blob:
> like we treat data:" is a separate issue from "should we treat
> cross-origin blob: like cross-origin http:, i.e. should we allow
> pointing an  to a cross-origin blob:".

Sure, I'm still at the "is there an XSS issue" here given that we can
pass Blob objects around without restrictions.


> I had hoped that we had settled the former and decided that blob:
> should not be treated as data:. And I think we've also decided that we
> should use the explicit origin syntax, i.e. something like
> "blob:http://example.com/uuid";

I'm not quite there yet. In part it seems this design stems from the
fact that we cannot create unique enough IDs. My question was if
things change if we did create unique enough IDs as it seems we are
designing something around a rather artificial limitation.


-- 
http://annevankesteren.nl/

Re: CfC: to create a new developer's list for WebApps' specs; deadline May 28

2014-05-21 Thread Anne van Kesteren 
On Wed, May 21, 2014 at 12:56 PM, Arthur Barstow  wrote:
> WDYT?

Developers seem to complain about us using mailing lists to
communicate rather than GitHub or some other centralized platform that
is not email. Might be worth checking with them first.


-- 
http://annevankesteren.nl/

Re: where do tests for window.opener go?

2014-05-21 Thread Simon Pieters 
On Wed, 21 May 2014 17:54:44 +0900, Zhang, Zhiqiang  
 wrote:



From: Hallvord R. M. Steen [mailto:hst...@mozilla.com]
Sent: Wednesday, May 21, 2014 4:22 AM
To: public-webapps
Subject: [web-platform-tests] where do tests for window.opener go?

Hi,
we have a window.opener issue and would like to have some tests for it.  
I'm

planning to write some and thought I might as well add them to the web-
platform-tests suite. Where? Would this be a suitable location:
https://github.com/w3c/web-platform-
tests/tree/master/html/browsers/the-window-object/security-window ?
-HR


For security, yes.

For navigating auxiliary browsing contests in the DOM, better to  
https://github.com/w3c/web-platform-tests/tree/master/html/browsers/windows/auxiliary-browsing-contexts


Alternatively, if there are multiple plausible places, and you want some  
related tests to be in the same place but still annotate some of them as  
being a test for another section, you can do that with .


--
Simon Pieters
Opera Software

Re: CfC: to create a new developer's list for WebApps' specs; deadline May 28

2014-05-21 Thread Arthur Barstow 

On 5/21/14 7:02 AM, Anne van Kesteren wrote:

Developers seem to complain about us using mailing lists to
communicate rather than GitHub or some other centralized platform that
is not email. Might be worth checking with them first.


Yes, good point Anne. I tweeted this Q with some tags that were intended 
to extend the reach. If others would also reach out, I would appreciate it.


I realize mail lists are a tool and there could be better ones to 
reach/engage the developer audience.


-Thanks, AB

IndexedDB >> Proposed API Change: cursor.advance BACKWARD when direction is "prev"

2014-05-21 Thread Arthur Barstow 

[ 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. 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: Blob URL Origin

2014-05-21 Thread Glenn Maynard 
Hmm.  One factor that might change my mind on this: If I pass a blob URL,
revoking the URL appropriately becomes hard.  Even if it gets implemented,
auto-revoke can't help with this.  That brings back all of the problems
with non-auto-revoking blob URLs, and adds a new layer of complexity, since
I have to coordinate between the site creating the blob URL and everyone
receiving it to figure out when to revoke it.

On the other hand, I can just post the blob itself.  That avoids all of
that mess, and the other side can just create a blob URL from it itself if
that's what it needs.

That suggests that it's not worth trying to make blob URLs more accessible
cross-origin.  I can't think of any case where I'd rather pass a blob URL
instead of just posting the Blob itself.

-- 
Glenn Maynard

Re: CfC: to create a new developer's list for WebApps' specs; deadline May 28

2014-05-21 Thread Brian Kardell 
On May 21, 2014 10:29 AM, "Arthur Barstow"  wrote:
>
> On 5/21/14 7:02 AM, Anne van Kesteren wrote:
>>
>> Developers seem to complain about us using mailing lists to
>> communicate rather than GitHub or some other centralized platform that
>> is not email. Might be worth checking with them first.
>
>
> Yes, good point Anne. I tweeted this Q with some tags that were intended
to extend the reach. If others would also reach out, I would appreciate it.
>
> I realize mail lists are a tool and there could be better ones to
reach/engage the developer audience.
>
> -Thanks, AB
>
>
+ public-nextweb...

I've kind of thought of Web Platform Docs as the developer end of things
and w3c specs for implementers and wgs - is it possible to set something up
under that banner? As a developer, i like the push orientation of mailing
lists too, but they suck for lots of other reasons too.

Re: CfC: to create a new developer's list for WebApps' specs; deadline May 28

2014-05-21 Thread Charles McCathie Nevile 
On Wed, 21 May 2014 16:27:36 +0200, Arthur Barstow   
wrote:



On 5/21/14 7:02 AM, Anne van Kesteren wrote:

Developers seem to complain about us using mailing lists to
communicate rather than GitHub or some other centralized platform that
is not email. Might be worth checking with them first.


Yes, good point Anne. I tweeted this Q with some tags that were intended  
to extend the reach. If others would also reach out, I would appreciate  
it.


I realize mail lists are a tool and there could be better ones to  
reach/engage the developer audience.


I don't object to creating a list enough to block the consensus, but as  
well as Anne's point, I wonder if we should be doing this in webapps or if  
we should be trying to support W3C's more general Dev Rel efforts instead.  
Which is partly a question to us, about the easiest way for us to provide  
any "helping others" capacity, and partly a question about how developers  
want help to get to them…


cheers

--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
  cha...@yandex-team.ru Find more at http://yandex.com

Re: CfC: to create a new developer's list for WebApps' specs; deadline May 28

2014-05-21 Thread Robin Berjon 

Hi Art, all,

On 21/05/2014 12:56 , Arthur Barstow wrote:

About two years ago I proposed in [1] creating a new list (f.ex.
public-webapps-devs) that is targeted toward developers using WebApps'
specs. Such a list would be used by developers using the APIs (as
opposed to implementers) as well as other related purposes such as
announcing relevant meetups, events, conferences, etc.

WDYT?


I've been in several discussions on this topic over the past months, a 
good example of which is:


https://twitter.com/tobie/status/457075677851037696

In reaction to that, I'm running an experiment to hold such discussions 
in a manner that may prove more usable: Discourse. It is being used by a 
growing number of open source projects and is under active development.


You are more than welcome to discuss WebApps related topics there, and 
I'm happy to add relevant categories, make tweaks that may be needed, etc.


See:

http://discourse.specifiction.org/

Feedback welcome!

--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: CfC: to create a new developer's list for WebApps' specs; deadline May 28

2014-05-21 Thread Arthur Barstow 

On 5/21/14 11:17 AM, Robin Berjon wrote:
I've been in several discussions on this topic over the past months, a 
good example of which is:


https://twitter.com/tobie/status/457075677851037696

In reaction to that, I'm running an experiment to hold such 
discussions in a manner that may prove more usable: Discourse. It is 
being used by a growing number of open source projects and is under 
active development.


You are more than welcome to discuss WebApps related topics there, and 
I'm happy to add relevant categories, make tweaks that may be needed, 
etc.


See:

http://discourse.specifiction.org/


Thanks for this information Robin. This could certainly be one way forward.

-AB

[Bug 23780] Check XMLHttpRequest and Notification don't break given the new script settings object stuff

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

Anne  changed:

   What|Removed |Added

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

--- Comment #12 from Anne  ---
Finally fixed comment 8!

https://github.com/whatwg/xhr/commit/848b22e99f36cb4a4481b77c382a1fd484ddf737

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

[Bug 21264] referrer source is wrong

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

Bug 23780 Summary: Check XMLHttpRequest and Notification don't break given the 
new script settings object stuff
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23780

   What|Removed |Added

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

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

Re: Blob URL Origin

2014-05-21 Thread Arun Ranganathan 

On May 21, 2014, at 10:47 AM, Glenn Maynard  wrote:

> Hmm.  One factor that might change my mind on this: If I pass a blob URL, 
> revoking the URL appropriately becomes hard.  Even if it gets implemented, 
> auto-revoke can't help with this.  That brings back all of the problems with 
> non-auto-revoking blob URLs, and adds a new layer of complexity, since I have 
> to coordinate between the site creating the blob URL and everyone receiving 
> it to figure out when to revoke it.
> 
> On the other hand, I can just post the blob itself.  That avoids all of that 
> mess, and the other side can just create a blob URL from it itself if that's 
> what it needs.
> 
> That suggests that it's not worth trying to make blob URLs more accessible 
> cross-origin.  I can't think of any case where I'd rather pass a blob URL 
> instead of just posting the Blob itself.


I agree with this.

Blobs themselves can be used in a cross-origin way, provided there’s 
caller-callee understanding (w.r.t. postMessage).

It’s easy to work with Blob URLs in the context of the script origin of 
URL.create*, since then Blob URLs can be used within that origin as an 
additional convenience. Keeping Blob URL origin as a script origin concept 
rather than a UUID concept makes sense to me. Also, that’s how they’re already 
implemented. The only thing missing is a formalization of syntax that’s closer 
to what’s already implemented.

— A*

[Bug 25854] New: Throwing an error in XHR.setRequestHeader for forbidden headers

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

Bug ID: 25854
   Summary: Throwing an error in XHR.setRequestHeader for
forbidden headers
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: XHR
  Assignee: ann...@annevk.nl
  Reporter: manishea...@gmail.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

http://xhr.spec.whatwg.org/#the-setrequestheader()-method

[[
Terminate these steps if name is a forbidden author header name.


]]

Perhaps we should throw a SecurityError or similar here?

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

[Bug 25853] New: "intentionally constraints"

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

Bug ID: 25853
   Summary: "intentionally constraints"
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: XHR
  Assignee: ann...@annevk.nl
  Reporter: ms2...@gmail.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

http://xhr.spec.whatwg.org/#the-setrequestheader()-method

[[
intentionally constraints
]]

Should be "constrains"

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

[Bug 25854] Throwing an error in XHR.setRequestHeader for forbidden headers

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

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Anne  ---
This is a very old API, we can't.

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

Re: IndexedDB >> Proposed API Change: cursor.advance BACKWARD when direction is "prev"

2014-05-21 Thread Joshua Bell 
On Wed, May 21, 2014 at 7:32 AM, Arthur Barstow wrote:

> [ 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: CommandEvent for user intentions

2014-05-21 Thread Ben Peters 
Great to hear! I’m working on an explainer document that will be more 
descriptive than the short wiki docs I wrote a couple weeks ago. My thoughts on 
your questions should be made clearer there. I’ll update this thread by the end 
of the week with more details, and my initial thoughts are below.

> I strongly agree that something like CommandEvents is necessary: a web 
> developer should be able to respond to the user’s intent, aka “selectAll”, 
> rather than enumerating, listening to, and responding to each and every 
> platform specific way that the intention to selectAll can be communicated.

> How encompassing do you envision CommandEvents?  Would it only cover well 
> known keyboard shortcuts and actions like those currently used by execCommand?

I see this as being more than just well-known keyboard shortcuts. I would like 
web developers to be able to extend it for their own purposes.

> What about taking this further and providing better events in two distinct 
> areas: those involving selections (intents like selectAll, but also selection 
> modifications like caret movement by keyboard or gestures, selection changes, 
> etc) and those involving input (including paste/drop/cut/formatting, but also 
> basic text insertion via keyboard/voice/etc).

This is a great idea! I'll include it in my spec. 

> I’m not sure an extra event type is necessary here though: why not use 
> beforeinput for the input events, and selectionchange for selection events?  
> Ryosuke’s selection spec currently has a placeholder for selectionchange, and 
> seems like the right place and timing to work this in?

My current thought is that Selection events should be used for selection, and 
CommandEvent for things that would be in a toolbar or context menu. I think the 
design should make it easy to create and style toolbars based on the available 
commands and their state. Input events don't cover everything that would be in 
a toolbar, and they fire for things that already have events for user 
intentions (like Clipboard Events).

Re: CommandEvent for user intentions

2014-05-21 Thread Julie Parent 
Have you seen the recent post about the rich text editor that Medium uses?
 It is a somewhat cheeky essay, including a mathematical proof, about how
contentEditable is broken.  The conclusion is that in order to move
forward, we need to treat contentEditable as an API, rather than as a
standalone component that tries to do everything itself.  It discusses the
idea of an "edit intent API", which is very in line with this proposal for
CommandEvents. https://medium.com/medium-eng/122d8a40e480


On Wed, May 21, 2014 at 11:51 AM, Ben Peters wrote:

> Great to hear! I’m working on an explainer document that will be more
> descriptive than the short wiki docs I wrote a couple weeks ago. My
> thoughts on your questions should be made clearer there. I’ll update this
> thread by the end of the week with more details, and my initial thoughts
> are below.
>
> > I strongly agree that something like CommandEvents is necessary: a web
> developer should be able to respond to the user’s intent, aka “selectAll”,
> rather than enumerating, listening to, and responding to each and every
> platform specific way that the intention to selectAll can be communicated.
>
> > How encompassing do you envision CommandEvents?  Would it only cover
> well known keyboard shortcuts and actions like those currently used by
> execCommand?
>
> I see this as being more than just well-known keyboard shortcuts. I would
> like web developers to be able to extend it for their own purposes.
>
> > What about taking this further and providing better events in two
> distinct areas: those involving selections (intents like selectAll, but
> also selection modifications like caret movement by keyboard or gestures,
> selection changes, etc) and those involving input (including
> paste/drop/cut/formatting, but also basic text insertion via
> keyboard/voice/etc).
>
> This is a great idea! I'll include it in my spec.
>
> > I’m not sure an extra event type is necessary here though: why not use
> beforeinput for the input events, and selectionchange for selection events?
>  Ryosuke’s selection spec currently has a placeholder for selectionchange,
> and seems like the right place and timing to work this in?
>
> My current thought is that Selection events should be used for selection,
> and CommandEvent for things that would be in a toolbar or context menu. I
> think the design should make it easy to create and style toolbars based on
> the available commands and their state. Input events don't cover everything
> that would be in a toolbar, and they fire for things that already have
> events for user intentions (like Clipboard Events).
>

RE: CommandEvent for user intentions

2014-05-21 Thread Ben Peters 
That is a great article! “A good WYSIWYG editor of arbitrary HTML is just as 
impossible as the halting problem is impossible... we have to treat it as an 
editor platform and API, rather than as a standalone component that tries to do 
everything itself.”

Let’s build a platform!

From: Julie Parent [mailto:jpar...@gmail.com]

Have you seen the recent post about the rich text editor that Medium uses?  It 
is a somewhat cheeky essay, including a mathematical proof, about how 
contentEditable is broken.  The conclusion is that in order to move forward, we 
need to treat contentEditable as an API, rather than as a standalone component 
that tries to do everything itself.  It discusses the idea of an "edit intent 
API", which is very in line with this proposal for CommandEvents. 
https://medium.com/medium-eng/122d8a40e480

On Wed, May 21, 2014 at 11:51 AM, Ben Peters 
mailto:ben.pet...@microsoft.com>> wrote:
Great to hear! I’m working on an explainer document that will be more 
descriptive than the short wiki docs I wrote a couple weeks ago. My thoughts on 
your questions should be made clearer there. I’ll update this thread by the end 
of the week with more details, and my initial thoughts are below.

Re: contentEditable=minimal

2014-05-21 Thread Julie Parent 
I question whether contentEditable=minimal should actually handle text
input.  If the idea is to provide the base platform on which a developer
can build the editing product of their dreams, isn't text insertion just
another behavior they could potentially need to disable?

Stepping back, there are distinct concepts that all combine to form the
current editing environment:

   1. Selections: Enable selections, perform cursor movement, scoping the
   boundaries on which the selection can operate.
   2. Input: Perform dom modifications, dispatch events, not limited to
   keyboard input, also includes IME, paste, drop, etc.
   3. Spell check: Enable spell check, modify the dom (or dispatch an
   event) when the user selects a replacement
   4. Formatting magic: bold when the user hits control + b, change
   directionality on Ctrl+LeftShift , etc.

It sounds like contentEditable=minimal as proposed would only enable #1 and
#2, and perhaps allow for #3? To break editing down into true building
blocks, I think we need to provide developers a way to explicitly enable
each of these systems separably, and not require the element to be
contentEditable.



On Mon, May 12, 2014 at 9:26 AM, Robin Berjon  wrote:

> On 12/05/2014 00:46 , Johannes Wilm wrote:
>
>> Also this looks good. There seems to be consensus that contenteditable
>> is just not going o get fixed, and so removing the faulty behavior
>> entirely and replacing it with this would be almost as good.
>>
>
> It depends on what you mean by "fixed". It is conceivable that given
> enough time and energy the current contentEditable behaviour could be made
> interoperable, but the problem is that even if that happened it seems clear
> from developers' feedback that it wouldn't do what they want. A lot of the
> time you would still want to disable a lot of what it does by default and
> handle it yourself. This is therefore just intended as a way of providing
> developers with primitives for editing.
>
>
>  Intercepting key strokes is already now possible and probably the best
>> one can do. The one thing where this gets complicated is when typing
>> characters using more than one key stroke. such as ~ + n to make ñ. I am
>> not sure if you include that under the "Some keyboard input handling".
>>
>
> Yes, text input is a hard problem and you can't get away without solving
> it. We are talking about providing primitives here, so things can be
> expected to be a little bit hairy though.
>
> DOM 3 Events has something called composition events for the example you
> bring up (which can get a whole lot more complicated, notably with things
> like Kotoeri and such). On the face of it it would seem to be the needed
> part but I've never used them (or seen them used) in the real world. (The
> quality of browser support is also unclear at this point.) Some cases also
> require the IME API.
>
> Developers relying on the bare bones cE would probably have to handle the
> rendering of ongoing composition themselves (which isn't the end of the
> world, but you need to think about it or you are guaranteed to mess things
> up). This is probably acceptable at this level, libraries can make it
> easier.
>
> --
> Robin Berjon - http://berjon.com/ - @robinberjon
>
>

Re: Blob URL Origin

2014-05-21 Thread Jonas Sicking 
On Wed, May 21, 2014 at 3:59 AM, Anne van Kesteren  wrote:
> On Tue, May 20, 2014 at 9:24 PM, Jonas Sicking  wrote:
>> I think you are confusing issues. Or at least talking about two
>> separate issues at once in a way that I'm not sure what you are
>> talking about. The issue of "is there an XSS issue with treated blob:
>> like we treat data:" is a separate issue from "should we treat
>> cross-origin blob: like cross-origin http:, i.e. should we allow
>> pointing an  to a cross-origin blob:".
>
> Sure, I'm still at the "is there an XSS issue" here given that we can
> pass Blob objects around without restrictions.

The fact that we allow passing blobs around is no different from the
fact that we allow passing an ArrayBuffer or a string around. Once a
page knows that it has the blob/arraybuffer/string the only way to
have it XSS you is to eval() it. Hopefully pages know not to do that
when receiving a blob/arraybuffer/string from an untrusted party as it
pretty obviously will enable that party to XSS you. eval() always
*explicitly* runs code in your origin.

Likewise, if you receive a blob from an untrusted party, and then do
myscriptelement.src = URL.createObjectURL(blob), then that very
explicitly will run code in your origin. It should be no surprise that
that will cause an XSS risk and so hopefully pages know not to do
that.

URLs are different though. If you receive a URL from an untrusted
party you can generally do window.location = url. Or you can do
myiframeelement.src = url and the worst thing you need to worry about
is that the contained page can navigate the top frame. And that you
can protect against by using a sandbox attribute.

It is not at all obvious that this can suddenly run code in your own origin.

Designing a secure platform doesn't mean forbidding any action that
can cause bad things to happen. Doing that might create a secure
platform, but one that probably can't do anything interesting.

Designing a secure platform is done by making things that can be
insecure be very explicit about what they do. So if someone wants to
do something that might be insecure that they have to very explicitly
ask for that. Hopefully that will cause them to think twice about it
and take any necessary precautions first.

/ Jonas