Hi Oliver,
I agree as I'm unsure what else *could* be safely exposed
before the drop event -- realistically anything beyond the
types seems risky: ignoring the obvious risks of exposing
actual content, exposing any form of URI may lead to
unintended information leaking (you have to assume
Hi Ian et al,
I've been playing with some of the current implementations of the Drag
and Drop feature described in section 7.10 of the spec. The current
security model seems a bit too strict in my opinion and needs some
tweaking. Please find below my two proposals for changes in section 7.10.3
Hi Ian,
firstly thanks for your comments.
--- Ian Hickson i...@hixie.ch wrote on Tuesday, 28. July 2009:
Whether draggable elements can be focused or not is up to
the user agent.
It's much like links -- in some browsers, whether they are
focusable or
not depends on the operating system
Hi Ian,
--- Ian Hickson i...@hixie.ch wrote on Thu, 16.7.2009:
The drag-and-drop model described in the HTML5 spec is input-device-
agnostic. If implementations don't support keyboard drag-and-drop (e.g.
copy-and-paste) then you should bring this up with the relevant vendors.
I don't think
Hi Christian,
have you ever considered just making the md5 (or maybe just a shorter CRC) part
of the filename of the file you want to cache? Then you can send Expiry headers
for 6 months or a years time for those files and you'll get the same behaviour.
Aron
. If such an attribute existed some elements
like ‘textarea’ or ‘input’ would probably have it set to true (or auto) by
default.
Aron Spohr
