Re: [whatwg] Should scrollbars move focus?
Wouldn't this be considered a browser-specific implementation bug/inconsistency then? It seems that it's done because the scrollbars have to be in the DOM, and therefore act as elements in the DOM tree (clicking in a random div for instance does change focus, so the implementation is correct in the sense of HTML). However, it doesn't look like this ever was looked at. It's just the bi-product of the way the DOM is typically implemented. Shouldn't it be fixed? Or rather, can it without breaking DOM functionality in the browser? On 2012-11-02 8:02 AM, James Ross sil...@warwickcompsoc.co.uk wrote: From: o...@chromium.org Date: Thu, 1 Nov 2012 10:45:07 -0700 I didn't test nested scrollbars in Windows. I believe Elliott may have. I did test them on Mac and Ubuntu. Clicking on nested scrollbars doesn't move focus even if the scrollable element is focusable. On Ubuntu, clicking on scrollbars doesn't even change window focus if the scrollbar is in a different window. On Windows (tested on 7 using the Resource Monitor and Command Prompt properties windows), interacting with scrollbars will focus the window, but not the scrollable item itself (i.e. preserving the focus within the window). However, Internet Explorer (9, on Windows 7), will move the focus to the scrollable element (for all types in Robert's test page). James
Re: [whatwg] Should scrollbars move focus?
I think Ubuntu has the right behavior, similar to how you can scroll windows in OS X (with the scroll wheel) even if they're not in a focus; a huge usability improvement over Windows when doing side-by-side document editing. If anything, I believe the user agent should never change platform behavior. If platform A has behavior X and platform B has behavior Y, then the user agent should behave as X on A and B on Y. Which is to say: scroll bars should never change focus, regardless of the case (as far as I know all platforms follow this convention) Étienne On 2012-11-01 7:08 PM, Robert O'Callahan rob...@ocallahan.org wrote: It would be trivial to change Gecko so that clicking on scrollbars never moves focus. So I'm on the fence too, although obviously it would be lower-risk for us to not change anything :-). Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28]
[whatwg] Erroneous description of h1, h2, h3, etc. elements on Whatwg.org
Hello Community, I've noticed that under section 4.4.6 of the HTML5 spec on Whatwg.orghttp://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements, the description of h1, h2, h3, etc. is as follows: *These elements have a rank given by the number in their name. The h1 element is said to have the highest rank, the h6 element has the lowest rank, and two elements with the same name have equal rank.* I propose a rewrite to this in order to cover changes in HTML5: *Unless they are contained within a section element, these elements have a rank given by the number in their name. The h1 element has the highest rank while the h6 element has the lowest rank. When used with the section element, the rank is determined by the nesting level of the given heading element within section elements.* * * I think this makes it more explicit for readers of the spec who won't go on section 4.4.11 to know exactly what the semantics mean. Etienne Levesque Guitard
Re: [whatwg] Problem with the blog
Looks like it's you. I just loaded the page on my Android. Etienne On 2011-08-19 11:09 AM, Alexandre Morgaut alexandre.morg...@4d.com wrote: Is it just me or is the WHATWG Blog out of service ? http://blog.whatwg.org/ Alexandre Morgaut Product Manager 4D SAS 60, rue d'Alsace 92110 Clichy France Standard : +33 1 40 87 92 00 Email : alexandre.morg...@4d.com Web : www.4D.com
Re: [whatwg] Outdated Implementation Statuses?
Except that having it not documented might be a good idea in reducing unwanted changes; as in only someone who's really interested will make the efforts of signing up to the mailing list and asking how it's done. ~Pacoup On Fri, Jun 24, 2011 at 13:19, Aryeh Gregor simetrical+...@gmail.comwrote: On Thu, Jun 23, 2011 at 5:55 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: The implementation statuses are not automatically generated - they're updated when someone cares enough to update them. Anyone can do so, though it's not very discoverable. Hold down Ctrl+Alt and double-click the status box, and it'll pop up a login prompt. Make an account, then you can change the statuses however you want. Maybe this should be documented clearly through a how to update link on the status boxes or such?
[whatwg] Outdated Implementation Statuses?
As I mentioned on http://forums.whatwg.org/bb3/viewtopic.php?f=1t=4663, it seems that many of the implementation statuses on the spec documents are outdated. Example: Isn't the header element already supported by many browsers? I can confirm Firefox and Chromium being able to style this element. Anyone has any idea on this? Etienne
