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 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 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 = script src='malicious.js'/scriptdivh1contentM/h1/div; 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 o...@chromium.org 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 = divscript src=//malicious.site/cookieStealer.js/scripth1content/h1/div; 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 hallv...@opera.comwrote: 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 lrb...@gmail.com ## 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 r.k...@alkacon.com 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 ro...@robinwinslow.co.ukwrote: 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: [Notifications] feedback requested on new Editor's Draft
On Tue, Mar 23, 2010 at 1:06 PM, John Gregg john...@google.com 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 ann...@opera.com wrote: On Thu, 10 Sep 2009 03:12:52 +0200, Jian Li jia...@chromium.org 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/
