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
acti
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?
ribly useful, but it would avoid a few embarassing
moments for people who use access control.
On 3/14/09, Robert O'Callahan wrote:
> On Sat, Mar 14, 2009 at 12:53 PM, Hans Schmucker
> wrote:
>
>> Question is: what would be the best way to fix it? Of course the spec
>> could
On Sat, Mar 14, 2009 at 3:11 PM, Anne van Kesteren wrote:
> On Fri, 13 Mar 2009 23:53:36 -0000, Hans Schmucker
> 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
>> 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
>> 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:
On Mon, Mar 16, 2009 at 2:43 PM, Anne van Kesteren wrote:
> On Mon, 16 Mar 2009 14:07:38 +0100, Hans Schmucker
> wrote:
>>>
>>> Why does the DOM need to get involved here?
>>
>> Well it should be involved, although I don't think we can actually do
>&
On Tue, Jul 7, 2009 at 12:15 AM, Robert O'Callahan wrote:
> On Tue, Jul 7, 2009 at 9:21 AM, 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 implemented in a matter of hours.
>> On J
> Doing filters in 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 already.
>
> For what it's worth, you can do filters manually using getImageData() and
> putImageData().
But if we begin with a more decl
> 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 ha
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 same
On Tue, Jul 7, 2009 at 1:47 AM, Robert O'Callahan wrote:
> On Tue, Jul 7, 2009 at 11:37 AM, Hans Schmucker
> 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
>>
*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
> If we add filters to , 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",
> 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 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.
feImag
this is something that is worth
pursuing. The specifics are still very much in flux.
Hans Schmucker
i...@hansshmucker.de
couple of concepts. Desktop 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 wrote:
>
> > Note: I've already sent this to the W3C public-html list, and while there
> 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 how we try to approa
18 matches
Mail list logo
