Hi,
contentEditable can be fairly useful in SVG as well. It partly works for inline
SVG content in web browsers today.
The question is, should SVGElement add support for
contentEditable/isContentEditable and add it to its interface? Or should both
attributes move to the Element interface
On Tue, May 13, 2014 at 11:26 AM, Dirk Schulze dschu...@adobe.com wrote:
contentEditable can be fairly useful in SVG as well. It partly works for
inline SVG content in web browsers today.
The question is, should SVGElement add support for
contentEditable/isContentEditable and add it to its
On 13/05/2014 10:26, Dirk Schulze wrote:
Hi,
contentEditable can be fairly useful in SVG as well. It partly works
for inline SVG content in web browsers today.
The question is, should SVGElement add support for
contentEditable/isContentEditable and add it to its interface? Or
should both
I thought I had replied to this. Seems I did not.
On Tue, Apr 29, 2014 at 7:24 PM, Peter Beverloo bever...@google.com wrote:
The Notification specification defines a static Notification.permission
accessor, which returns one of {granted, denied, default}. This requires
the browser to
On Tue, May 13, 2014 at 1:59 PM, Andrew Wilson atwil...@google.com wrote:
Just out of curiosity, what are we hoping that the use counter will show?
I'm presuming that every single app that uses the notification API will make
at least some use of Notification.permission, so it mostly seems like
Based on Anne's Reviving Notification Objects thread from last year, I
would like to propose an alternative solution.
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-March/251058.html
There are known lifetime issues with Notifications, and rather than tying
them all to the page, how
On Tue, 13 May 2014, Dirk Schulze wrote:
contentEditable can be fairly useful in SVG as well. It partly works for
inline SVG content in web browsers today.
The question is, should SVGElement add support for
contentEditable/isContentEditable and add it to its interface? Or should
both
On Mon, 12 May 2014, Eduardo' Vela\ Nava wrote:
On Mon, May 12, 2014 at 4:17 PM, Ian Hickson i...@hixie.ch wrote:
Note that there _is_ still a content type check with appcache, it's
just done on the first few bytes of the file instead of on the
metadata. (This is IMHO how all file
Yup, from the perspective of a significant proportion of modern
websites, MIME sniffing would be almost certainly a disaster.
I'm not suggesting sniffing, I'm suggesting having a single well-defined
algorithm with well-defined fixed signatures.
For formats that don't have signatures, this
On Fri, May 9, 2014 at 9:56 AM, David Young dyo...@pobox.com wrote:
The algorithms don't have to run as fast as possible, they only have to
run fast enough that the system is responsive to the user. If there is
a motion graphic, you need to run the algorithm fast enough that the
motion
We probably can't support a well-defined algorithm for detecting
documents that have distinctive signatures while safely supporting
formats that don't have them (because there is always a possibility
that the non-structured format with user-controlled data could be used
to forge a signature).
On 5/13/14, 10:11 AM, James Graham wrote:
I think the problem that I have with this API is the number of cores
that exist isn't obviously a good proxy for the number of cores that
are available. It I have N cores and am already using M cores for e.g.
decompressing video, N-M is probably a much
On Tue, May 13, 2014 at 1:15 PM, Boris Zbarsky bzbar...@mit.edu wrote:
this proposal seems to assume that the UA itself is using a very
few cores
The proposal does not assume anything regarding current system load.
If the UA is using every core for some CPU-intensive operation, then
On Tue, 13 May 2014, Michal Zalewski wrote:
We probably can't support a well-defined algorithm for detecting
documents that have distinctive signatures while safely supporting
formats that don't have them (because there is always a possibility that
the non-structured format with
On Tue, May 13, 2014 at 9:38 AM, Ian Hickson i...@hixie.ch wrote:
On Mon, 12 May 2014, Eduardo' Vela\ Nava wrote:
On Mon, May 12, 2014 at 4:17 PM, Ian Hickson i...@hixie.ch wrote:
Note that there _is_ still a content type check with appcache, it's
just done on the first few bytes of
On Fri, May 09, 2014 at 11:05:03AM -0500, Glenn Maynard wrote:
On Fri, May 9, 2014 at 9:56 AM, David Young dyo...@pobox.com wrote:
The algorithms don't have to run as fast as possible, they only have to
run fast enough that the system is responsive to the user. If there is
a motion
On Tue, 13 May 2014, Eduardo' Vela\ Nava wrote:
I agree that you're less likely to be able to control the headers. But
I don't think that's enough. A big part of the reason that authors
find it hard to set HTTP headers is that doing so is technically
complicated, not that it's
Thanks!
Just to ensure this wasn't lost in the thread.
What about X-Content-Type-Options: nosniff?
Could we formalize it and remove the X and disable sniffing all together?
On Tue, May 13, 2014 at 12:06 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 13 May 2014, Eduardo' Vela\ Nava wrote:
(for context [tests]
http://philip.html5.org/tests/ie8/cases/content-type-nosniff.html)
On 13 May 2014 17:38, Ian Hickson i...@hixie.ch wrote:
Are the lessons learnt here being reported to the Service Worker team?
Yes, I've been discussing this with them in
https://github.com/slightlyoff/ServiceWorker/issues/224 and
https://github.com/slightlyoff/ServiceWorker/issues/253, which
On Tue, 13 May 2014, Eduardo' Vela\ Nava wrote:
Thanks!
Just to ensure this wasn't lost in the thread.
What about X-Content-Type-Options: nosniff?
Could we formalize it and remove the X and disable sniffing all
together?
Do you mean for manifests specifically, or more generally?
For
On Tue, May 13, 2014 at 1:06 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 13 May 2014, Eduardo' Vela\ Nava wrote:
Thanks!
Just to ensure this wasn't lost in the thread.
What about X-Content-Type-Options: nosniff?
Could we formalize it and remove the X and disable sniffing all
(for the sake of completeness)
On Tue, May 13, 2014 at 12:06 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 13 May 2014, Eduardo' Vela\ Nava wrote:
I agree that you're less likely to be able to control the headers. But
I don't think that's enough. A big part of the reason that authors
Hello,
While looking at implementing the new autocomplete attribute syntax, I was
wondering about the driver for section-* tokens. The example in the spec[1]
with multiple shipping addresses for one checkout isn't something I've seen
done in the wild in one flow. In the example, how did the
On Mon, May 12, 2014 at 4:44 PM, Rik Cabanier caban...@gmail.com wrote:
Can you give an explicit example where browsers are having different
behavior when using drawImage?
I thought I was pretty clear about this... colorspace conversion and
alpha conversion happen here depending on the user's
I disagree. Much of the Web actually relies on this today, and for the
most part it works. For example, when you do:
img src=foo ...
...the Content-Type is ignored except for SVG.
Well, img is actually a fairly special case of content that is
difficult for attackers to spoof and that
If CSS, JS and plugins had magic numbers at the beginning of the file, then
that would prevent the issues that you are discussing right?
I think that's Ian's point, that for those file types, we need CT, but for
others, like manifest files, and image and plugins we shouldn't need.
PDFs, and JARs
I think that's Ian's point, that for those file types, we need CT, but for
others, like manifest files, and image and plugins we shouldn't need.
If we take this route, I think we'd be essentially making sure that
many web applications that are safe today will gradually acquire new
security bugs
So today, we need CT for JSONP and CSV. Those are the ones we *need* CT.
The idea is to train the browser to recognize the CTs of formats that are
ambiguous.
On Tue, May 13, 2014 at 8:26 PM, Michal Zalewski lcam...@coredump.cxwrote:
I think that's Ian's point, that for those file types, we
@Ian, is there a way to find out what was the Content-Type that the authors
that complained were getting?
Hopefully we can figure out a list of Content-Types that are unlikely to
cause security problems?
On Tue, May 13, 2014 at 8:32 PM, Eduardo' Vela Nava e...@google.comwrote:
So today, we
30 matches
Mail list logo
