Neil's Place

July 30, 2009

Removing chromedir for right-to-left UI

Filed under: Mozilla — enndeakin @ 9:20 am

I just checked in a patch which eliminates uses of the chromedir attribute in Firefox. This was previously a way in which right-to-left user interfaces were handled. Essentially, various elements and parts of the UI had a chromedir attribute set which retrieved either the value ‘ltr’ or ‘rtl’ from a localized DTD file. Stylesheets could then be modified based on the value. Since it was effectively a global state, it wasn’t very flexible, and required the use of hundreds of extra attributes. This was a very ineffective way to handle this.

Instead, I have replaced this with a pseudoclass:

:-moz-locale-dir(ltr) { ... }
:-moz-locale-dir(rtl) { ... }

The former matches when the user interface is using a locale displayed left-to-right, and the latter matches when the user interface is in a locale displayed right-to-left.

Locales which are right-to-left are controlled by a preference of the form ‘intl.uidirection.<locale>’, where <locale> is a language code such as ‘en’ or ‘ar-QA’. The value of the preference should be either ‘ltr’ or ‘rtl’.

This means that someone can transform their user interface into a right-to-left mode simply by changing the preference. The user interface will  redisplay immediately without having to restart. For instance, I might set ‘intl.uidirection.en’ to ‘rtl’. This means that the ForceRTL extension is no longer needed for this purpose.

Those creating localizations in left-to-right languages, or localizations in right-to-left localizations of Arabic, Farsi or Herbew need do nothing special. The preferences are set accordingly already (even in browsers using other locales). Extra style rules in intl.css for Firefox are no longer needed as these are already handled automatically

Also, the direction can be different for each window. For instance an Ararbic browser user can install an English-only extension and have a window with English-only UI displayed left-to-right. Naturally, this is only window specific, so wouldn’t apply to overlaid UI.

An author can override the UI direction for a window by setting the localedir attribute on a <window> or <dialog>, and other toplevel elements.

Advertisements

July 3, 2009

What’s Next for Focus

Filed under: Mozilla — enndeakin @ 3:52 pm

Now that the focus work has been completed, I’ve been looking at some follow up focus work to finish up. There have been a number of regressions and crashes found but they were all fixed very easily. I think the new focus code is much easier to work with, enough such that each regression was easily fixed in under an hour or so of work, except for one which took a few hours. That’s much better than the two weeks it took before to investigate a bug, try to fix it and then fail at it.

There’s still some issues surrounding plugins on Linux but Karl knows quite a bit about how focus should work on GTK so I’m confident we’re going to have something working there.

There’s a push to get bug 418521 fixed which affects which elements should be focused on mouse clicks and when they should draw focus rings. The idea here is that focus rings shouldn’t be drawn in some cases. In others, such as Mac, elements shouldn’t even be focused when clicking them.

The -moz-user-focus property is currently used in XUL to identify if an element may be focused or not. This doesn’t belong as a style property. The logical choice is to use an attribute instead. That can be used, but I’m currently leaning towards a feature added to XBL which lets one set default focusability behaviour for an element. This would possibly be combined with some ideas I have about how to combine accessibility with XBL. I’ll revisit this when the XBL2 implementation is further along. This may also help with some issues where certain elements have special-cased focus behaviour, for instance, those that need to retarget focus when clicked, or when an accesskey is pressed.

There’s still some modules which are caching focus, accessibility and I think the IME code might be but haven’t investigated it too closely. Focus shouldn’t be cached anywhere but the focus system.

Also, I want to get rid of nsFocusController.cpp, which doesn’t do much focus related anymore. I tried to do that before the focus work was completed but ended up needing to create a chain of other patches to fix various other issues. I need to go back and finish that up.

I think my goal for the next little while is to just finish up all the patches and partially completed work I have had sitting around for a while. I’ll write more about those things later.

Blog at WordPress.com.