Re: Intent to implement: Ability to surpress default contextmenu items
On Wed, 9 Jul 2014, Jonas Sicking wrote: This has been suggested many times, but the reason it's not part of the standard is that it's user-hostile. This argument always comes up, but I don't think this is an entirely accurate statement. This is less user-hostile than the web platform is today. The web platform today enables cancelling the contextmenu attribute which disables the UA context menu. That's why teh spec says: User agents may provide means for bypassing the context menu processing model, ensuring that the user can always access the UA's default context menus. For example, the user agent could handle right-clicks that have the Shift key depressed in such a way that it does not fire the contextmenu event and instead always shows the default context menu. Many website use this feature to replace the UA context menu with their own context menu implemented in HTML. The result is a context menu which is less accessible. It also results in that if the user uses UA features to *not* make the UA context menu cancellable, then the UA context overlays and hides the page provided one, making it inaccessible. Right, that's why contextmenu= exists in the first place. All I'm saying is that we should strive for the ideal middle ground, where the page's context menu is given a strong presence, thus satisfying the author, but where the UA actions are still easily available. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Improved ruby parsing in HTML with new tag omission rules
On Tuesday, July 1, 2014 12:58:45 PM UTC-7, Koji Ishii wrote: Summary: Two recent HTML changes improve ruby support: 1) Addition of the rb and rtc elements (but not rbc); and 2) Matching update to the tag omission rules to make ruby authoring easier. By implementing these changes, Gecko supports the parsing side of all the ruby use cases required for the internationalization of HTML (see use cases document below for details). It also enables the implementation of the CSS Ruby Layout. The Japanese education market strongly requires this and a Mozilla developer has already started working on it. Could you elaborate on why we are using the more complicated W3C rules here instead of the simpler WHATWG rules, given that the WHATWG rules also address the same use cases? See: https://bugzilla.mozilla.org/show_bug.cgi?id=9#c110 -- Ian Hickson ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Ability to surpress default contextmenu items
On Sat, 28 Jun 2014, Dale Harvey wrote: Application developers have the ability to specify additional menuitems for contextmenus via http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#context-menus however they are currently shown in addition to the default items, we are looking to implement an optional attribute that allows authors to disable the default context menu items so only the applications items are shown. This is primarily targeted for Firefox OS, I believe Jonas will be looking to add it to the official spec. The name / value of the attribute is under discussion menu chrome=disabled menuitem label=foo/menuitem /menu looks like the most likely candidate. This has been suggested many times, but the reason it's not part of the standard is that it's user-hostile. I would recommend that instead of letting the author prevent the user from getting to the user's browser's commands, the browser instead simply hide the browser commands behind a disclosure chevron, as in this example: http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#dom-contextmenu -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: intent to ship: drawFocusIfNeeded
On Tue, 6 May 2014, Robert O'Callahan wrote: On Tue, May 6, 2014 at 5:57 PM, Ian Hickson i...@hixie.ch wrote: Just so we're clear, I really don't care what the name is, nor do I have any objection to people having private conversations or whatnot. My point is just that there has not been a conversation in the WHATWG list about this which has resulted in the name being changed. So you're saying that discussions on any forum other than the WHATWG list are ignored for the purposes of you making changes to WHATWG specs? They're not ignored, but I am unlikely to hear about them, and if I don't hear about them, or if they aren't convincing, then they're not likely to result in changes to the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: intent to ship: drawFocusIfNeeded
On Mon, 5 May 2014, Robert O'Callahan wrote: drawSystemFocusRing is a rather bad name since most calls to it will draw nothing. drawCustomFocusRing is an even worse name since it will draw nothing approximately always. drawFocusIfNeeded replaces drawSystemFocusRing, which is the method we expect people to need much more than drawCustomFocusRing. drawCustomFocusRing should change, but I'm not sure what to since its name needs to indicate both that it doesn't usually draw anything and its return value must be checked and properly used. I think it makes sense to use the short name for the method that is both simpler and the API most authors should be using. drawFocusIfNeeded() isn't a particularly good name either, since you're not drawing the focus, you're drawing the focus ring. I suppose if drawFocusIfNeeded() is the best we can come up with for drawSystemFocusRing(), then drawCustomFocusRing() could maybe become shouldDrawFocus(). In any case, the right place for these discussions would be a public standards list, like the WHATWG list, so that all the interested parties (in particular, authors) could have visibility into the discussion. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: intent to ship: drawFocusIfNeeded
On Thu, 1 May 2014, Rik Cabanier wrote: No particular reason. The spec text is identical; just the name of the method changed. Roc suggested the new name and people liked it better. I believe Ian stated that he would update the WHATWG version when there are 2 implementations. There's two methods in the HTML spec, drawSystemFocusRing(element) and drawCustomFocusRing(element). It's not clear to me that the name drawFocusIfNeeded() is an improvement on either. In particular, I can't tell which it's replacing, nor what the other would be called if we followed the same naming scheme. The WHATWG spec is going to follow browsers, but that doesn't mean that the new name is necessarily better. If it was, I would have updated the spec already instead of waiting for multiple UAs to do something else. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: AppCache usage on Alexa top ~50,000 sites
On Thu, 11 Jul 2013, Marcos Caceres wrote: As a result of a discussion a few of us had today at the Toronto work week about the use of appcache on the web (and if we should fix it), I did a quick scan of the sites using appcache in Alexa's top ~50,000 websites (only includes the landing page at a given URL). Of the search, 16 sites were returned - 2 of which have appcache commented out. 1 site only enabled it for Mobile IE. Note that the main use case for appcache is applications, which tend to be behind authentication walls and robots.txt blocks. For example, I would doubt that a grep is going to catch Google Docs' use of appcache. (Not that they want appcache to remain as is, but that's a separate issue.) appcache is, in this respect, similar to keygen (which is almost not used at all on the public web, but is used on intranets and behind paywalls and authentication walls). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cycle collection for workers
On Thu, 7 Feb 2013, David Rajchenbach-Teller wrote: I am curious: does this mean an actual user-visible canvas present on a webpage or just off-main screen canvas? The way it's specced in the HTML spec right now it can involve pushing bits to the screen, but it's modelled in such a way that really that's equivalent to grabbing the bitmap and shipping that over using postMessage() and having the main thread post it to the GPU. (Doesn't have to be implemented that way, but it's not supposed to be distinguishable from that.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cycle collection for workers
On Fri, 8 Feb 2013, Robert O'Callahan wrote: We'd definitely implement it with the goal that the worker can get a canvas update onto the screen even if the HTML event loop is blocked by a long-running task. That's needed to ensure that games can get a stable frame rate. If it turns out that violates the spec (I haven't looked), then we'll lobby for spec change :-). Pretty sure the spec allows that. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
