Re: [whatwg] [proposal] Gallery element

[Hans Schmucker]

> 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 approach situations like this. In that
> spirit, I'll try to respond to what I perceive as the use cases and underlying
> problems you're experiencing.

Thanks for the pointers Domenic, I had not seen this particular document and
there are a lot of valid issues raised in there... specifically a different
approach that puts the actual issue front and center instead of one possible
solution.

> The first problem you describe is trying to add meaning to convey that
> something is a gallery. The idea, presumably, being that you have some
> software in mind that might benefit from knowing about galleries across the
> web as it scrapes web sites. Could you describe this software in more detail,
> and the ways in which it currently tries to search for and present galleries?

> In general the best way to add extended semantics to HTML for these kind of
> less-common use cases is to use something like https://schema.org/. Have you
> considered if there are any structured data vocabularies you could use
> alongside existing markup?

You are correct in that this could be solved via micro-formats. The only real
issue here is that galleries are a very common feature, but this is an edge case
and you are quite correct in that we could and probably should ignore this for
now.

The real issue for me is usability and ease of access for developers. The simple
truth is that most galleries available on the web are a pain to use on mobile
devices. And providing a near-native experience is so much work that even big
players often prefer leaving their web-page in an unsatisfactory state and
encouraging users to install an app instead.

> It sounds like you are hoping to be able to customize the presentation of your
> photo galleries according to who views it. Are existing responsive design
> features (such as , srcset, @media, @viewport, and so on) not meeting your
> needs in some way? Can you describe how you have tried to use them but run
> into cases where they fail?

It's not so much that I wish to customize it. The technology available to do
that is entirely sufficient and with enough time a perfect gallery which detects
the OS and emulates the convention of each platform could be implemented.

What we're missing is a reasonable fallback behavior for when the developer
doesn't possess the skills to implement an acceptable solution. And I feel that
with galleries we currently don't live up to these standards. 

A major platform for perfect gallery hosting could theoretically emerge and fill
this void, much like YouTube did for video, but web pages should at least
function reasonably well on their own and currently that's not really the case
from a mobile user's perspective
when it comes to galleries. 

So, the abstract problem that I was trying to solve would be:
"Make implementing image browsing on mobile platforms so easy to implement that
even smaller players (I'm talking about restaurants or plumbers) can provide an
acceptable experience to their users".

> One thing you describe is customizing according to OS versions. This is
> generally somewhat against the design grain of the web, which tries to present
> a single experience that is responsive to different devices, instead of a
> per-device custom experience. Is there something that makes you think that
> picture galleries should be an exception from that?

You are correct in that it is a relatively uncommon behavior. The video element
is pretty much the only example of an element that (if the developer desires so)
handles its behavior on its own (it's also a pretty bad example in that the
native controls are rarely used as they were not implemented by all major
players for quite some time... also, videos are rarely self-hosted). The main
reason I was thinking about it is the simple experience that images are very
difficult to present in an intuitive format on mobile. But this should probably
take a backseat to implementing a reasonable behavior, whatever that may be.

Thanks VERY much for your feedback Domenic.

Re: [whatwg] [proposal] Gallery element

[Hans Schmucker]

Thanks for the reply Jonathan.

> Jonathan Zuckerman <j.zucker...@gmail.com> hat am 13. Juli 2016 um 14:36
> geschrieben:
> 
> Hi Hans, I'm not an important figure at all in the web world, but my
> intuition is this isn't a good candidate for a new feature in HTML. You've
> done a good job of abstracting the problem and exploring the edge cases but
> the feature is just too specific.
>
> I doubt site owners would want to use it. Most sites have a very distinct
> visual style and falling back to the platform's design patterns might not
> fit with that.

It's definitely a bit problematic. Web developers naturally crave control over
their design. You're probably right in that it's unrealistic to expect authors
to hand over too much control over their design to the UA. On the other hand,
the overview is something that's pretty similar across desktop and mobile
platforms... so maybe there's some common ground if the standard defines a
default style that is  platform-dependent, but can be overridden via CSS. It may
have to be a little less abstract, but I think we could still come up with a
solution that will improve the experience for the user.

> 
> I doubt browser vendors would want to implement it. As you stated, " the
> conventions for displaying a list of images are very different for
> practically every platform". Any browser that operates on different
> platforms (the most popular one operates on practically every platform
> there is) would have a difficult job indeed of making it function
> intuitively in all situations.

I don't think it's much of an issue for browser vendors though. Mobile platforms
usually have some sort of universal gallery routine readily available and the
only real convention on the desktop platform is "don't open another application
without asking", so a lightbox or something like that should be easy to
implement.

I've actually written a little example over at
http://hansschmucker.de/GalleryElement/
in order to explore a 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 <i...@hansschmucker.de> wrote:
> 
> > Note: I've already sent this to the W3C public-html list, and while there
> > hasn't
> > been any response so far, it is possible that issues will be raised on both
> > channels. The original message along with replies is available at
> > http://lists.w3.org/Archives/Public/public-html/2016Jul/0011.html .
> > Although
> > I'll do my best to transport raised issues between both lists.
> > Right now this is little more than a description of a problem with a rough
> > outline how a solution could work, so there are obviously a lot of issues
> > not
> > discussed in this proposal. What I'd like to discuss is whether this has
> > any
> > place in the HTML specification at all. My personal opinion is that it
> > would
> > lend meaning to something that today is mostly tag-soup, but your opinion
> > may
> > differ and that's what I'm most interested in hearing about.
> > 
> > IF there is consensus that this IS worth investigating, then I'd gladly
> > help
> > write up a few proposals and sample implementations.
> > 
> > Maybe I’m overlooking something, but I’m currently writing another JS
> > gallery
> > (there are some special requirements, but that’s beside the point) and
> > there’s
> > one thing that bothers me: There really is no way to write a perfect
> > gallery for
> > all platforms, for the simple reason that the conventions for displaying a
> > list
> > of images are very different for practically every platform.
> > 
> > Desktop users are used to menu-less thumbnail overviews with lightboxes for
> > full-size images, because zooming is not a huge priority. Mobile users
> > prefer
> > full-screen images without any controls, but with appropriate gestures in
> > place.
> > The specifics (like how annotations are presented, which options are
> > present and
> > which animations are expected) even differ between OS versions.
> > 
> > All that combined with the simple fact that there simply is no way to mark
> > up a
> > gallery correctly at this time, while the web is exploding with graphics,
> > makes
> > me think that we should consider adding gallery element.
> > 
> > A gallery should be a _a series of related pictures which have a combined
> > topic,
> > as well as an individual message._
> > 
> > Its content (one figure per item) should be shown to the user in a way
> > which is
> > _appropriate for the platform_, allowing him

[whatwg] [proposal] Gallery element

[Hans Schmucker]

the gallery. So how do we account for all these cases while giving designers
a predictable result that they can incorporate into their design?

Basically, we’ll need an element that will either
a)Cover a specified area or
b)Fit into a column with an intrinsic height
Which additionally
Has a minimum specified size per element.

There’s also the issue to consider that not all images are the same.. Some may
be suitable for cropping, others may be suitable for scaling and so on and so
forth.
Getting the CSS right is obviously an issue, but a solvable one if there's any
interest in doing this.

The basic question that I'm asking is whether this is something that is worth
pursuing. The specifics are still very much in flux.

Hans Schmucker
i...@hansshmucker.de

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

[Hans Schmucker]

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 implemented in a matter of hours.
 On Jul 6, 2009 10:54pm, Robert O'Callahan rob...@ocallahan.org wrote:
  Speaking as an implementor of SVG filters, I don't believe you :-).

 I said most parts (by which I meant the actual image manipulations, which
 are defined pretty well in the SVG spec, not the surrounding issues of when
 to do drawing updates and so on that wouldn't apply to a Canvas anyway) :) .
 OK, I made it sound simpler than it is, but when you get right down to it,
 just the drawing code isn't terribly complicated.

 Some of the filters aren't complicated, but some are. You're also talking
 about duplicating the object model. And looking forward, if we do some
 JIT-based or GPU-based filter acceleration, duplicating that work would
 really suck. I would say the drawing code has to be shared even if the
 object model is not.

 On Jul 6, 2009 10:54pm, Robert O'Callahan rob...@ocallahan.org wrote:
  I agree that we need a convenient way to use filters with canvas. But I
  would rather not create an entirely new object model.
  How about a drawImageWithFilter method that takes the same set of
  parameters as drawImage plus a reference to an SVG element? The image is
  used for Source/SourceAlpha and the size of the image establishes the 
  object
  bounding box for filter and filter primitive units. Since drawImage can 
  draw
  a canvas, this seems completely flexible.

 I'm fearing that the dependency on SVG would bring a lot of problems if a
 browser vendor wants to include just Canvas, like WebKit on the Palm Pre.

 Webkit on iPhone and I think Android, and Fennec too, support SVG. If Palm
 decides differently, that's their call and they can take the consequences. I
 am deeply averse to duplicating functionality across specs just in case
 someone implements one but not the other. It punishes authors and vendors of
 full-function browsers.

It may just be me, but I think that the success of Canvas, which is
way ahead of HTML5 in general, is largely due to the fact that it's
pretty much standalone. You don't have to read through hundreds of
pages of other documentation, you just read the Canvas spec and that's
pretty much it. Same for parties who want to implement it, there's
virtually no big dependency.

Of course, how you actually implement it (i.e. by sharing code with
the SVG filters) is not even something a spec is supposed to dictate,
you can share as much code as you want as long as the result is what
the spec says.

 Also, the SVG model is pretty complex when you include all the ways to
 cross-reference data. What would happen if a filter would want to load an
 image? Canvas can't work asyc, so either the whole call would fail or we'd
 lock up the browser for ages.

 You'd just use whatever image you've got, just like SVG filter drawing does
 normally. It's no different from doing drawImage with a partially loaded
 image.
Is this really useful for Canvas? Partial results are fine when all
you do is filter, but if the filter is part of a larger drawing
routine, then the result could be pretty undesirable. And since
there's no direct way to check for the status of the resource, all the
Canvas user could do would be trying again and again until it works
should we decide that methods should throw an error if a resource
isn't loaded yet.

 Security issues would also increase tenfold as Canvas has a pretty simple
 security model. If we'd allow normal SVG filters, we'd probably need to flag
 the Canvas as dirty, since SVG flters allow for loading of data from many
 sources, including what's currently on the screen.

 You mean BackgroundImage? That makes no sense for canvas usage anyway, we'd
 just ignore it. Foreign image usage would taint the canvas, that's easy to
 do.
Nope, I meant the filter loading an SVG, loading a HTML via
foreignElement, loading another SVG via iframe, loading an image from
another server. BackgroundImage is of no use for Canvas anyway.

 Including a dedicated filter API for Canvas would keep it simple and
 self-contained, allowing for much easier implementation, wouldn't it?
 No, not really. Duplicating code is evil. Adding layers of abstraction so
 that the same code can be used through different interfaces is less evil,
 but it's still bad.
I think that abstraction would provide an OK compromise, but that's up
to the implementing parties.

 It would also give us a chance to strip out SVG stuff that doesn't make
 any sense for Canvas or is too complicated for too little benefit.
 You see that as a chance. I see it as an opportunity for endless arguments.
 And experience suggests that over time both sets of functionality will grow
 to meet all users' requirements.
But do you really 

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

[Hans Schmucker]

 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 more declarative approach now, we can actually
encourage browser vendors to include the functionality if they want
greater speed. Fallbacks to putImageData would provide basic
functionality anywhere, but if a vendor wants to access greater speed
for say, photo editing or games, he can chose to add filter support
and see an immediate speed increase.

Basically, filters for Canvas would provide new functionality through
speed. Responsiveness would increase dramatically for certain kinds of
applications.

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

[Hans Schmucker]

 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 need for both. Right now it's either fast,
declarative, but limited OR slow, but customizable.

About interoperability: At least for me Canvas support seems very
stable across browsers, which is why I'm comfortable asking for the
next step, as long as including it doesn't change compatibility with
existing JS code and wouldn't require needlessly complicated
fallbacks. Both fallbacks and support would be pretty straight-forward
for this.

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

[Hans Schmucker]

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 amount of predictability that we're
used to from Canvas,

If you directly include SVG, a developer who wants to use it has to
understand all of SVG, which is a pretty big spec, with lots of
unexpected behaviour. And as a result, often incorrect behaviour in
implementations.

--hans

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

[Hans Schmucker]

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 certain actions.

 Like arcTo?

OK, there may be some border cases. But in general Canvas is a whole
lot more predictable than anything else you'll find in a browser.



 Relying directly on SVG filters makes things
 harder to understand and predict. A flat, stripped-down API

 APIs don't remain stripped-down for long.

They can, if the individual modules are specific enough. Future
versions may add more filters, but the basic API would stay the same.
When you use SVG filters, there are lots of question marks in the
equation. Like, how will it render dynamic content loaded from inside
the current document, how an animation from an outside document, how
will it deal with foreignContent, how with form data inside it? All
this is largely irrelevant for Canvas, but it would still have to be
considered. A simple API could get rid of such cases straight away.



 If you directly include SVG, a developer who wants to use it has to
 understand all of SVG,

 That is completely untrue.

That was a bit over-dramatic. But try to learn SVG filters without an
in-depth knowledge of SVG first. There are many points that you can
trip over. Stuff that your garden-variety HTML/JS developer would just
understand differently (color spaces, units, rectangles, ...).

 which is a pretty big spec, with lots of
 unexpected behaviour. And as a result, often incorrect behaviour in
 implementations.

 Yet you're asking us to duplicate code, which inevitably leads to even more
 bugs.

Again, you can share as much drawing code as you like, but after all,
how the filter is applied to Canvas would have to be written from
scratch anyway,

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

[Hans Schmucker]

*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 have that problem with SVG in general and it's
really holding SVG back. If at all possible, I'd like to avoid that
with Canvas filters. A lot of functionality offered by SVG filters is
either already included elsewhere in the Canvas spec or simply not
relevant. I think if we strip the filter API of these cases we can
make using it a lot more stable, predictable and attractive to
developers.

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

[Hans Schmucker]

 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

[Hans Schmucker]

 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 is my problem case #1. There's some other odd stuff, but
feImage is really my top concern.
Anything else will have to wait till tomorrow: I'm off to bed.

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

[Hans Schmucker]

 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 making all elements that load offsite data
 descend from a common HTMLRemotelyFedElement interface (which seems
 like the right way to do things, but it's also IMHO completely
 unrealistic as it would either require reworking the DOM top to bottom
 or including ugly hacks) or adding the necessary attributes to
 HTMLElement itself... which seems like asking for trouble.

 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 header response should be stored and be available
the same way across all DOM elements that can load data. If that would
be provided by a special interface from which all elements that load
data descend, it would not only make the whole thing cleaner in the
spec, but also in the implementations. Instead of an UA supporting
first XHR, then image, then video, then XY, the status of the
implementation would be identical in all parts of the UA. Basically,
it would force implementations to create the CORS dom support with a
common codebase for all elements that use it, instead of having
duplicate code which might behave differently.


 Then there's the (IMHO) despicable way of just writing a random
 chapter about it and referencing that chapter in the spec wherever
 appropriate. Feels very, very wrong, but I don't think we have much
 choice here.

 I don't see how this is wrong. Since the exact semantics of a cross-origin
 request vary per API anyway grouping the common things somewhere makes sense
 to me. (E.g. EventSource would completely fail in case the resource sharing
 check fails where as an image would still be displayed.)

Reading this again the next morning I really should have worded that
differently. Sorry about that. But I'm really afraid JS developers, in
addition to catching different behaviours in different UAs would also
have to deal with different behaviour inside the same UA. Yes, the
actual use would be different across different cases, but at least the
raw data would be readable the same way and the parts that implement
the different uses would have a standardized to where to get their
data from.

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

[Hans Schmucker]

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 header response should be stored and be available
 the same way across all DOM elements that can load data. If that would
 be provided by a special interface from which all elements that load
 data descend, it would not only make the whole thing cleaner in the
 spec, but also in the implementations.

 If the specifics are not exposed to authors the DOM does not need to get
 involved.

Correct. I'm not a browser maker, so my perspective is probably a bit
different than yours. I just write JS. The problem for me is that if
such data is not available, I would be forced to basically do a lot of
try/catch or other form of error catching just to find out what
exactly I can do when I could just look it up in the elements
attributes.

 Instead of an UA supporting
 first XHR, then image, then video, then XY, the status of the
 implementation would be identical in all parts of the UA. Basically,
 it would force implementations to create the CORS dom support with a
 common codebase for all elements that use it, instead of having
 duplicate code which might behave differently.

 I don't think we should be in the business of enforcing how implementations
 implement things. We can certainly encourage things by re-using algorithms,
 indicating things are identical, etc., but if there is no author-observable
 difference we cannot test it.

Well, a bit. We do that all the time when we specify inheritance. At
least we encourage it and plant the idea that this really should be in
a common spot.

 Then there's the (IMHO) despicable way of just writing a random
 chapter about it and referencing that chapter in the spec wherever
 appropriate. Feels very, very wrong, but I don't think we have much
 choice here.

 I don't see how this is wrong. Since the exact semantics of a
 cross-origin request vary per API anyway grouping the common things
 somewhere makes sense to me. (E.g. EventSource would completely fail in case
 the resource sharing check fails where as an image would still be
 displayed.)

 Reading this again the next morning I really should have worded that
 differently. Sorry about that. But I'm really afraid JS developers, in
 addition to catching different behaviours in different UAs would also
 have to deal with different behaviour inside the same UA. Yes, the
 actual use would be different across different cases, but at least the
 raw data would be readable the same way and the parts that implement
 the different uses would have a standardized to where to get their
 data from.

 Consistency is enforced by tests and proper specifications. Currently HTML5
 has not integrated support for CORS (yet) so it seems a bit early to
 complain :-)

Better now than when the damage is done, right?

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

[Hans Schmucker]

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 to
 update the defintion of origins to include patterns that can represent
 allow rules?

 Aside: You might want to take a look at a later version of the specification
 (the one that is being implemented):

  http://dev.w3.org/2006/waf/access-control/

Thank you Anne, but I think this has to be dealt with primarily inside
the HTML5 spec. The Access Control spec is already pretty clear on how
things are supposed to work on the server and from the server to the
client and it's probably mostly enough to say that Image and Video
elements in addition to cross-origin linking also allow for
cross-origin use as described in Cross-Origin Resource Sharing. Me
and Chris actually assumed it would work that way until we tried it.
The main question for me (aside from the question if
image/video/canvas elements should retain all necessary information to
check for valid origins that are allowed access again or just be
marked standard/public) is where to put it in the spec. It's an
issue that applies to pretty much anything that allows access to the
raw data (which is just canvas now, but nobody knows what the future
will bring) and to make matters worse its nature not only requires
changes to canvas itself, but also to the elements that are drawable,
like img or video. So to me it would make the most sense to put this
as far away as possible from Canvas and make it more into a generic
item how DOM elements are supposed to hold data about cross origin
headers. Then the canvas description would need virtually no changed
beyond obeys cross-origin rules for pixel access.

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

[Hans Schmucker]

 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, than into the CORS spec, which more or
less focuses on the server side and the communication between server
and client.

 No, currently you actually have to state which algorithm you use in CORS and
 how. Otherwise CORS does not apply (at least not from a specification
 standpoint).
Yes, we pretty much assumed that HTML5 had already adapted to CORS. It
was an assumption, but it's an assumption many people are bound to
make as other HTML5 features depend on CORS.


 It's an
 issue that applies to pretty much anything that allows access to the
 raw data (which is just canvas now, but nobody knows what the future
 will bring) and to make matters worse its nature not only requires
 changes to canvas itself, but also to the elements that are drawable,
 like img or video. So to me it would make the most sense to put this
 as far away as possible from Canvas and make it more into a generic
 item how DOM elements are supposed to hold data about cross origin
 headers. Then the canvas description would need virtually no changed
 beyond obeys cross-origin rules for pixel access.

 That does sound nice yes.

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 making all elements that load offsite data
descend from a common HTMLRemotelyFedElement interface (which seems
like the right way to do things, but it's also IMHO completely
unrealistic as it would either require reworking the DOM top to bottom
or including ugly hacks) or adding the necessary attributes to
HTMLElement itself... which seems like asking for trouble.

Then there's the (IMHO) despicable way of just writing a random
chapter about it and referencing that chapter in the spec wherever
appropriate. Feels very, very wrong, but I don't think we have much
choice here.

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

[Hans Schmucker]

Doesn't that kind of defeat the purpose of access control to have fine
grained control over who is allowed access? Public resources are a
quick fix for most scenarios that I can imagine, but I think using
patterns would appear more consistent and logical to most users. It
may not be terribly 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
 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?


 I don't think changing the definition of origins is the right way to go. It
 seems better to define a category of public resources, specify that a
 resource served with Access-Control-Allow-Origin: * is public, and have
 canvas. treat public resources specially.

 Rob
 --
 He was pierced for our transgressions, he was crushed for our iniquities;
 the punishment that brought us peace was upon him, and by his wounds we are
 healed. We all, like sheep, have gone astray, each of us has turned to his
 own way; and the LORD has laid on him the iniquity of us all. [Isaiah
 53:5-6]

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

[Hans Schmucker]

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
actively allowing processing on other domains (as indicated by
Access-Control-Allow-Origin).

Is this an oversight or is there a specific reason why Access Control
for Cross-Site Requests should not work for Canvas?

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

[Hans Schmucker]

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?