Re: Directory Upload Proposal
> 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?
> > 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. > -Hallvord > 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
I like the idea of "package" seems all encompassing which captures the requirements nicely. That or perhaps "resource", but then resource seems singular. Or perhaps "component-package" so it is obvious that it's tied to web components? -Ryan On Tue, Mar 26, 2013 at 6:03 AM, Dimitri Glazkov wrote: > Hello folks! > > It seems that we've had a bit of informal feedback on the "Web > Components" as the name for the 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 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 > http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0742.html > > Rules: > > 1) must reflect the intent and convey the meaning. > 2) link type and name of the spec must match. > 3) no biting. > > :DG< >
Re: Sanitising HTML content through sandboxing
> > 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 object. How would this handle sanitising? -Ryan
Sanatising HTML content through sandboxing
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.
e.g.
xhr.responseText = "contentM/h1>";
var div = document.createElement("div");
div.sandbox = ""; // Static content only
div.innerHTML = xhr.responseText;
document.body.appendChild(div);
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
sense.
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.
-Ryan
Re: innerHTML in DocumentFragment
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 > do. 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 = "content"; var frag = document.createDocumentFragment(); frag.sandbox = ""; frag.innerHTML = xhr.responseText; // it's sandboxed so the script(s) will be stripped by the parser. document.body.appendChild(frag); 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. [1] http://community.jboss.org/people/wesleyhales/blog/2011/08/28/fixing-ajax-on-mobile-devices -Ryan
Re: innerHTML in DocumentFragment
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)
On Tue, May 17, 2011 at 2:23 PM, Hallvord R. M. Steen wrote: > text/plain > text/html > image/jpg > image/gif > image/png > application/xhtml+xml > image/svg+xml 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 API? -Ryan Seddon
Re: Offline Web Applications status
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] Cheers, Ryan [1] http://www.w3.org/TR/DataCache/
Re: drop directories/folders
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
functionality.
-Ryan
[1] http://code.google.com/p/chromium/issues/detail?id=58977
On Tue, Mar 15, 2011 at 8:59 PM, Rüdiger Kurz wrote:
> Hi,
>
> 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
> drop.
>
> ###
>
> 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
> directory.
>
> 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'
> otherwise
>
>
> Kind regards
>
> --
> Rüdiger Kurz
>
> ---
>
> Visit OpenCms Days 2011 Conference and Expo
> May 9 to May 10 2011 in Cologne, Germany
> http://www.opencms-days.org
>
> 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
> Email: r.k...@alkacon.com
>
> http://www.alkacon.com
> http://www.opencms.org
>
> Geschäftsführer: Alexander Kandzior, Amtsgericht Köln, HRB 54613
>
>
>
Re: DOM event detection
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. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=195696 [2] http://kangax.github.com/iseventsupported/ -Ryan On Tue, Dec 21, 2010 at 10:44 AM, Robin Winslow wrote: > 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 ( > http://goo.gl/XNSg5 http://goo.gl/rAa5f) 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 (http://goo.gl/TYm2k) 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? > > Cheers, > Robin. >
Re: using BlobBuilder append method with generated binary data
On Tue, Dec 21, 2010 at 4:15 AM, Toni Ruottu wrote: > Could someone point out the exact location that mentions this way of using > Uint8Array? > Mozilla's documentation about handling binary data with XMLHttpRequest[1] shows use of Uint8Array. [1] https://developer.mozilla.org/En/XMLHttpRequest/Using_XMLHttpRequest#Receiving_binary_data_using_JavaScript_typed_arrays
Re: [Notifications] feedback requested on new Editor's Draft
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 > http://dev.w3.org/2006/webapi/WebNotifications/publish/ > 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 > layer? > I also agree that it would make sense to add it to navigator. --Ryan
Re: Proposal for sending multiple files via XMLHttpRequest.send()
Mozilla has something similar already called sendAsBinary though it takes a string not an array https://developer.mozilla.org/en/XMLHttpRequest#sendAsBinary%28%29 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; >>payload.push(header1); >>payload.push(file1); >>payload.push(footer1); >>... >>xhr.send(payload); >> >> 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 > http://annevankesteren.nl/ > >
