On Tue, Mar 25, 2014 at 1:10 AM, Si Robertson retromodu...@gmail.com wrote:
Ideally, the File API would provide a way for users to save a file, and I'm
surprised this is still an issue. Writing a file to a user selected location
is no less secure than allowing a user to download a file with an
* Si Robertson wrote:
The problem that this new event would solve is this - when using a
temporary object URL (blob) for the file data, e.g. programmatically
generated content, there is currently no way of knowing when that file data
has been written to disk, therefore there is no reliable way of
On Mon, Mar 24, 2014 at 8:10 PM, Si Robertson retromodu...@gmail.comwrote:
Allowing users to save/download a runtime-generated file with the use of
object URLs and the anchor download attribute is the only viable way of
doing things at the moment. Bouncing the file through a server isn't
Looking into selection in this brave new world (Shadow DOM for sure, but
there are issues as well with flexbox if I'm not mistaken), is definitely
something we are interested in.
I also agree with moving selection to its own spec. Solving selection first
opens the door to solving editing.
Hi Daniel,
I'm trying to make sure I correctly understand how the IE11 version of this
works. From the sample
(http://msdn.microsoft.com/en-us/library/ie/dn254935(v=vs.85).aspx), it looks
like if a user pastes in some HTML that references local images, IE11
automatically captures the
* Bjoern Hoehrmann write:
That something has been written to disk does not make destryoing data
safe. It is not unsual, for instance, to expect that data can be saved
more than once, and invalidating such expectations can lead to catas-
trophic data loss. I think
WebApps was asked to review the Last Call Working Draft of the Web
Crypto API:
http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/
Individual WG members are encouraged to provide individual feedback.
If anyone in WebApps wants to propose an official WG response, please do
so ASAP, in reply
I'm working with several individuals of varying skillsets on using/making
custom elements - we are using a way cut-back subset of what we think are
the really stable just to get started but I had an observation/thought that
I wanted to share with the list based on feedback/experience so far...
It
Do custom elements present any new challenges in comparison to non-custom
elements here? I feel like you have the same issue with filling a select with
data from a remote source.
From: Brian Kardell bkard...@gmail.com
Sent: Tuesday, March 25, 2014 17:31
To:
Let me try and repeat this back to you, standards-nerd-style:
Now that we have custom elements, there's even more need for notifying a
style engine of a change in internal elements state -- that is, without
expressing it in attributes (class names, ids, etc.). We want the ability
to make custom
On Tue, Mar 25, 2014 at 6:10 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Do custom elements present any new challenges in comparison to
non-custom elements here? I feel like you have the same issue with filling
a select with data from a remote source.
Only really the fact that
On Tue, Mar 25, 2014 at 6:27 PM, Dimitri Glazkov dglaz...@chromium.orgwrote:
Let me try and repeat this back to you, standards-nerd-style:
Now that we have custom elements, there's even more need for notifying a
style engine of a change in internal elements state -- that is, without
It seems to me you probably should have just not included :unresolved in your
very small subset. In reality, it seems, :unresolved for existing elements is
just { display: none; }. That is, if you do
`selectoptiona/option/select` you don't see the unstyled string a on
the page, only later
13 matches
Mail list logo
