[whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests

This problem recently became apparent while trying to process a public video on tinyvid.tv: In article 4.8.11.3 Security with canvas elements, the origin-clean flag is only set depending on an element's origin. However there are many scenarios where an image/video may actually be public and

Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests

Question is: what would be the best way to fix it? Of course the spec could be changed for video and image, but wouldn't it be simpler to update the defintion of origins to include patterns that can represent allow rules?

Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests

useful, but it would avoid a few embarassing moments for people who use access control. On 3/14/09, Robert O'Callahan rob...@ocallahan.org wrote: On Sat, Mar 14, 2009 at 12:53 PM, Hans Schmucker hansschmuc...@gmail.comwrote: Question is: what would be the best way to fix it? Of course the spec

Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests

On Sat, Mar 14, 2009 at 3:11 PM, Anne van Kesteren ann...@opera.com wrote: On Fri, 13 Mar 2009 23:53:36 -, Hans Schmucker hansschmuc...@gmail.com wrote: Question is: what would be the best way to fix it? Of course the spec could be changed for video and image, but wouldn't it be simpler

Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests

Thank you Anne, but I think this has to be dealt with primarily inside the HTML5 spec. Yes, hence me using the word aside... Sorry, I didn't mean to make it sound like an attack, I really just meant to say that this (for me) belongs more into HTML5, which deals primarily with the user agent,

Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests

So, where would you put it? The problem for me is that there's no logical grouping of elements that load offsite resources (like img, script, link, video, ...) where one could add the necessary attributes. All off them descend directly from HTMLElement. So there would be two routes: Either

Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests

On Mon, Mar 16, 2009 at 2:43 PM, Anne van Kesteren ann...@opera.com wrote: On Mon, 16 Mar 2009 14:07:38 +0100, Hans Schmucker hansschmuc...@gmail.com wrote: Why does the DOM need to get involved here? Well it should be involved, although I don't think we can actually do it. I think the CORS

Re: [whatwg] Adding SVG Filter-like functionality to Canvas 2D Context

On Tue, Jul 7, 2009 at 12:15 AM, Robert O'Callahanrob...@ocallahan.org wrote: On Tue, Jul 7, 2009 at 9:21 AM, hansschmuc...@gmail.com wrote: On Tue, Jul 7, 2009 at 2:09 AM, hansschmuc...@gmail.com wrote: SVG Filters are a relatively easy spec, where the most important parts can be

Re: [whatwg] Adding SVG Filter-like functionality to Canvas 2D Context

Doing filters in canvas is an interesting idea, but I think that it is probably too early to add it. We have dozens of feature requests for the next version of canvas already. For what it's worth, you can do filters manually using getImageData() and putImageData(). But if we begin with a

Re: [whatwg] Adding SVG Filter-like functionality to Canvas 2D Context

I think in practice if people have declarative filter needs, they'll just use SVG. But that said, filters are indeed something we should look at in a future version. Right now, though, I'd rather we let the browser vendors get interoperable on what exists already in the spec. Often, you have

Re: [whatwg] Adding SVG Filter-like functionality to Canvas 2D Context

I should really add one point. The Canvas spec, above all, is predictable. You pretty much know exactly what you'll get when you perform certain actions. Relying directly on SVG filters makes things harder to understand and predict. A flat, stripped-down API on the other hand could provide the

Re: [whatwg] Adding SVG Filter-like functionality to Canvas 2D Context

On Tue, Jul 7, 2009 at 1:47 AM, Robert O'Callahanrob...@ocallahan.org wrote: On Tue, Jul 7, 2009 at 11:37 AM, Hans Schmucker hansschmuc...@gmail.com wrote: I should really add one point. The Canvas spec, above all, is predictable. You pretty much know exactly what you'll get when you perform

Re: [whatwg] Adding SVG Filter-like functionality to Canvas 2D Context

*sigh* I hate it when I start sounding whiny and I probably did in the previous posts. I'll try to sum it up again without the whining sound. I simply think that when using SVG filters, we are much more likely to add a lot of these border-cases where browsers behave subtly different. We already

Re: [whatwg] Adding SVG Filter-like functionality to Canvas 2D Context

If we add filters to canvas, I would expect to be defined in a way that doesn't leave edge cases undefined. But for all practical purposes, that would be what we'd do if we just said just use your usual SVG filter system,

Re: [whatwg] Adding SVG Filter-like functionality to Canvas 2D Context

Whatever those issues are that you're referring to, they need to be fixed in SVG already. Creating a new set of well-defined behaviours in canvas can only add more work. If the new well-defined behaviours fail to match the behaviour SVG requires, then the situation will be even worse. feImage

[whatwg] [proposal] Gallery element

The specifics are still very much in flux. Hans Schmucker i...@hansshmucker.de

Re: [whatwg] [proposal] Gallery element

isn't really too complicated, it's more about providing a consistent experience for mobile users. > > On Wed, Jul 13, 2016 at 8:12 AM, Hans Schmucker <i...@hansschmucker.de> wrote: > > > Note: I've already sent this to the W3C public-html list, and while there > > hasn't

Re: [whatwg] [proposal] Gallery element

> Domenic Denicola hat am 13. Juli 2016 um 15:14 geschrieben: > > Thanks for the thoughtful description of the problem! If you haven't seen it > before, > https://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F > has a description of