Re: Directory Upload Proposal

2015-04-28 Thread Ryan Seddon
 To enable developers to build future interoperable solutions, we've
 drafted a proposal [4], with the helpful feedback of Mozilla and Google,
 that focuses strictly on providing the mechanisms necessary to enable
 directory uploads.

The use of the dir attribute seems odd since I can already apply dir=rtl
to an input to change the text direction.

Re: [clipboard] Feature detect Clipboard API support?

2015-04-21 Thread Ryan Seddon

 If we did that, authors could not use synthetic clipboard events for
 anything - right? I'm assuming that authors are going to find use cases for
 it - for example a cloud clipboard implementation may want to fire actual
 paste events so that data from the cloud is processed like data from the
 local clipboard.

Yep thats a very valid point I wouldn't want to stop people being able to
trigger synthetic events, not sure of an alternative.

Re: [webcomponents]: Naming the Baby

2013-03-26 Thread Ryan Seddon
I like the idea of package seems all encompassing which captures the
requirements nicely. That or perhaps resource, but then resource seems

Or perhaps component-package so it is obvious that it's tied to web


On Tue, Mar 26, 2013 at 6:03 AM, Dimitri Glazkov dglaz...@google.comwrote:

 Hello folks!

 It seems that we've had a bit of informal feedback on the Web
 Components as the name for the link rel=component spec (cc'd some
 of the feedbackers).

 So... these malcontents are suggesting that Web Components is more a
 of a general name for all the cool things we're inventing, and link
 rel=component should be called something more specific, having to do
 with enabling modularity and facilitating component dependency
 management that it actually does.

 I recognize the problem, but I don't have a good name. And I want to
 keep moving forward. So let's come up with a good one soon? As
 outlined in


 1) must reflect the intent and convey the meaning.
 2) link type and name of the spec must match.
 3) no biting.


Re: Sanitising HTML content through sandboxing

2011-11-10 Thread Ryan Seddon

 DOMParser.parseFromString already takes a content type as the second

 argument. The plan is to support HTML parsing when the second argument
 is text/html.

I quite like this as it keeps it agnostic towards what it is parsing so
other formats like MathML and SVG won't look out of place with HTMLParser

How would this handle sanitising?


Sanatising HTML content through sandboxing

2011-11-08 Thread Ryan Seddon
Right now there is no simple way to sanitise HTML content by stripping it
of any potentially malicious HTML such as scripts etc.

In the innerHTML in DocumentFragment thread I suggested following the
sandbox attribute approach that can be applied to iframes. I've moved this
out into its own thread, as Jonas suggested, so as not to dilute the
innerHTML discussion.

There was mention of a suggested API called *innerStaticHTML* as a
potential solution to this, I personally would prefer to reuse the sandbox
approach that the iframes use.


xhr.responseText = script

var div = document.createElement(div);

div.sandbox = ; // Static content only
div.innerHTML = xhr.responseText;


This could also apply to a documentFragment and any other applicable DOM
API's, being able to let the HTML parser do what it does best would make

The advantage of this over a new API is that it would also allow the use of
the space separated tokens to white list certain things within the HTML
being parsed into the document and open it to future extension.


Re: innerHTML in DocumentFragment

2011-11-07 Thread Ryan Seddon
On Tue, Nov 8, 2011 at 4:30 AM, Ojan Vafai wrote:

 I don't really follow. Script won't execute until you append the fragment
 to the DOM, at which point the fragment itself doesn't go in the DOM, just
 it's children. So, I'm not really sure what sandboxing on fragments would

If I was ajaxing in potentially hostile content that had malicious script
tags in it it would be ideal to sandbox the content so the HTML parser in
the browser would strip the content for me.

xhr.responseText = divscript

var frag =  document.createDocumentFragment();

frag.sandbox = ;
frag.innerHTML = xhr.responseText; // it's sandboxed so the script(s) will
be stripped by the parser.


The following article demonstrates the same concept using an iframe with
the sandbox attribute set[1]. This to me would also make sense to be
extended to fragments.



Re: innerHTML in DocumentFragment

2011-11-05 Thread Ryan Seddon
This would be a great addition, another thought would be the ability to
sandbox the documentFragment. Much the same way you can sanitise
responseText from an XHR using and iframe with the sandbox attribute being
able to do this with fragments would be might handy.

Re: Filtering clipboard MIME types (was: Re: clipboard events)

2011-05-17 Thread Ryan Seddon
On Tue, May 17, 2011 at 2:23 PM, Hallvord R. M. Steen hallv...@opera.comwrote:


 What about image/webp? +1 for being able to copy/paste binary data either
through application/octet-stream or perhaps using blobs with the BlobBuilder

-Ryan Seddon

Re: Offline Web Applications status

2011-03-23 Thread Ryan Seddon
Hi, comments inline

2011/3/24 louis-rémi BABE

 ## Maybe Web devs don't use App Cache because they don't understand
 what it is... ##

I think most webdevs are expecting more than what is offered. It seems like
a half baked solution to a potentially useful requirement.

 ## Can you see other reasons? ##
 Before going back to developers or writing yet another App Cache
 documentation, I wanted to have *your* feelings about this mechanism.
 You might have a different impression about its adoption and be aware
 of successful real-world use-cases.
 You might have asked developers yourself and received a different feedback.
 Maybe you feel that Web advocates are not doing a good enough job at
 documenting this feature, producing demos and clarifying its nature.
 Maybe you think that the problem has to do with the specification itself.
 Maybe there is an evolution of the specification underway that I am
 not aware of.

One thing that really gripes me is the fact that any changes require you to
re-parse and re-download the entire cache again if any changes are detected
to the manifest. I think the API needed more controls for
inserting/updating/deleting single assets, handling offline XHR calls etc.
What I was really hoping for was the DataCache API[1] to take off but this
seems to of stalled and no longer looks like it will be developed further.

I do believe plenty of developers know about the application cache but it's
not exactly a sexy technology that gets huge attention. Perhaps this could
be changed with some compelling use-cases.

 ## Two naive questions ##
 After reading a large amount of documentation, I have to admit that I
 am myself confused about app cache:
 Do you think it *can* be used as an auxiliary cache mechanism, and
 what would be the limitations? The main problem I see is that there is
 no way to white-list the referring document (e.g. index.html).
 Currently, I would advocate *against* using it as an auxiliary cache.
 Why isn't there any DOM API allowing a fine-grained control of the
 application cache?
 applicationCache.cache.add( URI );
 applicationCache.cache.remove( URI );

See DataCache API[1]




Re: drop directories/folders

2011-03-15 Thread Ryan Seddon
WebKit or more specifically Chromium has the webkitdirectory attribute
that can be placed on a file input.

When you choose a directory it populates the FileList object with all the
files within the selected directory, however there is a bug[1] at the
moment. When you drag and drop a directory the FileList object is populated
with the directory name and not the files within it.

This hasn't been defined nor am unaware of any editor draft for this



On Tue, Mar 15, 2011 at 8:59 PM, Rüdiger Kurz wrote:


 this is Rüdiger I’m a developer from Alkacon Software GmbH in Cologne,
 Germany. This year we are planning to release our new version 8 of OpenCms.
 Therefore we want to support our customers with a File API / FormData based
 upload functionality. This new upload feature should also provide drag and


 Context: HTML5 - File API in combination with Drag and Drop

 Problem: If you drop directories/folders on to a defined dropzone, I
 assume that it is not possible to detect that the dropped file is a

 Target: When a user drops a directory, I want to inform the user in some
 way that directories can't be handled by the program.

 Note: I know that it should not be possible to read a whole directory
 structure for security reason and that is not the point I want to make.

 Suggestion: Extend the File Interface for a attribute called directory

 interface File : Blob {
  readonly attribute DOMString name;
  readonly attribute DOMString directory;
  readonly attribute DOMString lastModifiedDate;

 directory: Has the value 'true' if the file is a directory, 'false'

 Kind regards

 Rüdiger Kurz


 Visit OpenCms Days 2011 Conference and Expo
 May 9 to May 10 2011 in Cologne, Germany

 Alkacon Software GmbH - The OpenCms Experts
 Rüdiger Kurz
 An der Wachsfabrik 13
 50996 Koeln, DE

 Tel: %2B49%20%280%292236%203826-16+49 (0)2236 3826-16
 Fax: %2B49%20%280%292236%203826-20+49 (0)2236 3826-20

 Geschäftsführer: Alexander Kandzior, Amtsgericht Köln, HRB 54613

Re: DOM event detection

2010-12-21 Thread Ryan Seddon
It's actually a bug in Firefox[1] which unfortunately been around for a very
long time, since 2003, and isn't isolated just on the input event it also
affects the invalid event. For detecting events kangax has created a handy
method called isEventSupported[2] which will detect 99% of events
successfully, albeit not input or invalid events in FF due to the above
mentioned bug.



On Tue, Dec 21, 2010 at 10:44 AM, Robin Winslow

 After a brief correspondence with Robin Berjon he suggested I post this
 suggestion here.

 After having problems with detecting support for the HTML5 'input' event ( I started wondering if there was
 a DOM specification for detecting support for DOM events in browsers.

 After a brief email correspondence with Robin Berjon, and looking around a
 bit myself, it appears that there is no specific mention of this in the
 current HTML5 or DOM specifications. There is some mention of DOM events
 being exposed as methods ( but this may not
 necessarily apply to all DOM elements.

 Therefore, I'd like to suggest that we try to come up with a standard way
 of suggesting that support for DOM elements be exposed, to enable developers
 to tell which events are supported.

 One method that works in Webkit and Gecko for many methods, although I
 don't think it's in any W3C specification, is to include methods for each
 event them in the Event object, e.g.:

 'CLICK' in Event; // true
 'CHANGE' in Event; // true
 'INPUT' in Event; // false

 Does that seem like a reasonable method of DOM event support detection?
 Could it be included as a recommendation in the specification somewhere?


Re: [Notifications] feedback requested on new Editor's Draft

2010-03-23 Thread Ryan Seddon
On Tue, Mar 23, 2010 at 1:06 PM, John Gregg wrote:

 After the extensive discussion several weeks ago, I've been working on a
 new draft for Web Notifications which is now available at

Not sure if this has been asked before but what about an optional property
to position it elsewhere beside the bottom left.

Something like:

createNotification(in DOMString iconUrl, in DOMString title, in DOMString
body[, in DOMString position])

Where it can take 4 possible values: topleft, topright, bottomleft,
bottomright. Bottomright being the default.

 Should we really put another interface on the global object? Can we not
 put these on window.navigator like other APIs that integrate with the system

I also agree that it would make sense to add it to navigator.


Re: Proposal for sending multiple files via XMLHttpRequest.send()

2009-09-11 Thread Ryan Seddon
Mozilla has something similar already called sendAsBinary though it takes a
string not an array

On Thu, Sep 10, 2009 at 7:28 PM, Anne van Kesteren wrote:

 On Thu, 10 Sep 2009 03:12:52 +0200, Jian Li wrote:

 There has already been a discussion on extending XMLHttpRequest.send() to
 take a File object. Could we also consider enhancing it further to support
 sending multiple files, like a FileList from the drag and drop.

 We could make XMLHttpRequest.send() take a FileList object and let the
 browser add multipart boundary separators automatically.

 Or, the other simpler way, thanks to Darin's suggestion, is to
 extend XMLHttpRequest.send() to take an array of items. Each of item could
 be either a string or a file reference strictly. The web application is
 responsible to generate the multipart enevelop like the following:

var payload = new Array;

 How do you guys think about these approaches?

 The first seems a lot less error-prone for authors. I think we should go
 with that.

 Anne van Kesteren