Let's design UI elements correctly

    Not so long ago, my patience ran out. At first, all sorts of plugins, and then various frameworks, begin to "force" HTMLDocument . To understand whether the element has lost focus or not, they track the onclick event on HTMLBodyElement or on HTMLDocument . And if some of them pay attention to pressing Tab a while losing focus, then most of them ignore this fact altogether.


    Focus / blur

    There are 4 “magic” DOM events:
    • focus
    • blur
    • focusin
    • focusout

    Ordinary DOMElements do not generate them, however, if you use the magic attribute tabindex , then we have such an opportunity.
    When creating my own UI element for jQuery, I had to deal with 2 problems related to the fact that HTMLInputElement is used inside my element (hereinafter I mean the same HTMLSelectElement and HTMLButtonElement ).

    Problem number one is the lack of focus and blur event popups . And here focusin and focusout come to our aid. Now we can operate on focus events at the level of the parent element.
    Problem number two is the generation of blur and focusout events in the parent when a click occurs on a child HTMLInputElement (the tabindex attribute only affects focus using Tab a). Which in turn "breaks" us the whole logic of working with the developed UI element. At the moment, I haven’t found a “decent” solution to this problem (tracking the onclick event on a document or body is also not “decent”)
    The first possible solution is to broadcast keyboard events to “children” while holding the focus on the “parent”, but at the moment, none of the browsers supports the correct generation of events of this type (Fx supports its own interface. IE9 and Chrome adhere to the standard , but they have a bug when transmitting the code of a pressed key is always transmitted zero. Opera cannot generate keyboard events at all)
    The second is checking document.activeElement for events of loss of focus (and not without troubles, in Fx and Chrome, activeElement becomes a link to new the first element to receive focus, only after the completion of the blur event ).
    And since none of these methods works, I had to resort to a "dirty hack." Instructions events blur pass from the general flow, in other words, use setTimout .
    >>> UPD
    It turns out that we and jQuery developers went the same way to solve this problem ( autocomplete )
    <<<


    CSS System Colors

    For some reason, few people remember (know) about system colors . Dear developers, let's respect the desire of the user and use the colors that he prefers to see in his OS. After all, not everyone wants to read on a white background and, accordingly, do not use blue to highlight text.

    >>> UPD
    Of course, if you create a button for your stylized application, then using system colors is stupid. I mention cases when a system GUI element or its variation is emulated. For example, in Sencha (formerly ExtJS), white is used for the background of elements instead of Window . Here is an example .
    In jQuery, the default color for all UI solutions is orange. Why they decided to do so is still a mystery to me. They would make life easier for many if they used the default system colors (Admit who started to suffer with jQuery UI styles when fastening the calendar? :))
    <<<


    event.stopPropagation ()

    An instruction to interrupt an event stream is the biggest evil that I have encountered on web pages. If suddenly some element is not working correctly for you, links stop working under strange circumstances, then you should know that this is the result of the presence of this instruction.
    It can only be used gently where you are certain that you cannot do without it. Where an alternative solution will cost you too much. But as a rule, if you used “this”, then architectural miscalculation in your decision.
    A banal example, intercepting mouse clicks on your element with interrupting the flow of messages. Everyone - now everyone who is tied to receiving this event (see all plugins that “close” when clicking outside of them) will not work correctly.
    Or minimize the popup by pressingEscape will not work if your element intercepts keystrokes and is in focus.


    WAI-ARIA

    And finally, the standard I learned about after the release of IE8. It defines approaches to the content of the site and / or Internet application from the side of the device (browser). The standard was developed and presented as a mechanism that allows people with disabilities to fully use your online project.
    But it seems to me that this standard will be actively applied in mobile browsers. Because the use of UI elements supporting WAI-ARIA will make them more convenient. For example, the opened HTMLSelectElement looks like this in the mobile version of IE9:


    Agree, choosing from such a list on a mobile phone is much more convenient and pleasant than from a small, albeit “cute” one made using JS and HTML


    Instead of an afterword

    By and large, I decided to write this note in order to ask the habro-community for help with solving the focus / blur problem . I’ve been looking for it for more than 1 month, and even thinking of contacting either browser developers to standardize activeElement changes or in w3c.


    "It is interesting".

    The most well-formed UI elements are implemented by Google in Gmail. These are the buttons above the list of letters.

    Also popular now: