Re: [whatwg] Suggestion for HTML5 context menus
On 23/10/2011 08:35, Jonas Sicking wrote: We added support for this in firefox, so you can get the behavior you want there in the meantime (I forget what we called the attribute though). Is there a way for the user to access the regular context menu? I could imagine it being extremely irritating and even frustrating if one can't access familiar and useful items like Copy link location, Bookmark this page or Select all because the author of some element on the page has decided to redesign the context menu. Regards -Mark
Re: [whatwg] Suggestion for HTML5 context menus
On Sun, Oct 23, 2011 at 8:50 PM, Mark Callow callow_m...@hicorp.co.jp wrote: On 23/10/2011 08:35, Jonas Sicking wrote: We added support for this in firefox, so you can get the behavior you want there in the meantime (I forget what we called the attribute though). Is there a way for the user to access the regular context menu? I could imagine it being extremely irritating and even frustrating if one can't access familiar and useful items like Copy link location, Bookmark this page or Select all because the author of some element on the page has decided to redesign the context menu. That would be a decision that the UA can make. In firefox we have forever had an option to control whether websites can disable the built-in context menus or not. Traditionally that has been hooked up to the contextmenu event. We now have the same pref hooked up to honoring this new attribute as well. Another option would be to hide the default context menu items in a sub-menu rather than fully disable them. There's several good choices here. All we need is for websites to be able to signal that they want their options to replace ,rather than add to, the default menu options. What the UA decides to do with that information is a UI decision. / Jonas
Re: [whatwg] [CORS] WebKit tainting image instead of throwing error
To follow up on this thread, this issue should be resolved in http://trac.webkit.org/changeset/98215. Please let me know if further improvements are needed. Adam On Thu, Oct 6, 2011 at 2:54 PM, Adam Barth w...@adambarth.com wrote: On Thu, Oct 6, 2011 at 10:02 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 10/6/11 12:11 PM, Adam Barth wrote: It sounds like you're arguing that it's better for developers if we fail fast and hard In some cases, yes. It's a tradeoff in every case, obviously. A meta-issue: if you disagree with the spec text when implementing something, silently implementing something else seems strictly worse than raising a spec issue (and still implementing something else if desired). I didn't knowingly diverge from the spec. I didn't notice the strict error checking when writing the patch. Especially for things that you're planning to implement unprefixed. We implemented this feature without a prefix at Ian's specific request. Likewise for cases when the spec is unclear, etc. What's the point of having implementations early in the specification process if they don't actually provide feedback and instead only serve to lock in behaviors? I think you're being a big aggressive. In any case, I didn't have any ill intent. I just misunderstood because it never occurred to me that we'd want to fail hard on this sort of error. Adam
