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 inste
On Tue, May 13, 2014 at 11:26 AM, 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
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
> shoul
I thought I had replied to this. Seems I did not.
On Tue, Apr 29, 2014 at 7:24 PM, Peter Beverloo wrote:
> The Notification specification defines a static Notification.permission
> accessor, which returns one of {granted, denied, default}. This requires
> the browser to synchronously determine wh
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
it's going to show us how often the Notification APIs *in general* are used
in
On Tue, May 13, 2014 at 1:59 PM, Andrew Wilson 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 it's
> going to s
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 abo
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
>
On Mon, 12 May 2014, Eduardo' Vela\" wrote:
> On Mon, May 12, 2014 at 4:17 PM, Ian Hickson 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 typing should
>> 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
> On Fri, May 9, 2014 at 9:56 AM, David Young 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 isn't choppy.
Tha
> 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 signatu
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 muc
On Tue, May 13, 2014 at 1:15 PM, Boris Zbarsky 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
navigator.hardwareConcurre
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 user-
On Tue, May 13, 2014 at 9:38 AM, Ian Hickson wrote:
> On Mon, 12 May 2014, Eduardo' Vela\" wrote:
> > On Mon, May 12, 2014 at 4:17 PM, Ian Hickson 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 Fri, May 09, 2014 at 11:05:03AM -0500, Glenn Maynard wrote:
> On Fri, May 9, 2014 at 9:56 AM, David Young 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 n
On Tue, 13 May 2014, Eduardo' Vela\" 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 i
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 wrote:
> On Tue, 13 May 2014, Eduardo' Vela\" wrote:
> > >
> > > I agree
(for context [tests]
http://philip.html5.org/tests/ie8/cases/content-type-nosniff.html)
On 13 May 2014 17:38, Ian Hickson 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 is what led
m
On Tue, 13 May 2014, Eduardo' Vela\" 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?
On Tue, May 13, 2014 at 1:06 PM, Ian Hickson wrote:
> On Tue, 13 May 2014, Eduardo' Vela\" 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 wrote:
> On Tue, 13 May 2014, Eduardo' Vela\" 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
> > > fi
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 we
On Mon, May 12, 2014 at 4:44 PM, Rik Cabanier 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 display
configurat
> I disagree. Much of the Web actually relies on this today, and for the
> most part it works. For example, when you do:
>
>
>
> ...the Content-Type is ignored except for SVG.
Well, is actually a fairly special case of content that is
difficult for attackers to spoof and that can't be easily
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 bug
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 wrote:
> > I think that's Ian's point, that for those file types, we need CT, but
> for
@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" wrote:
> So today, we need CT for JSONP an
31 matches
Mail list logo
