HTML Layout Direction

Posted on

Not every language uses a layout direction of left-to-right (LTR). Some use right-to-left (RTL). This is also known as the “reading direction” or “writing direction”.

At this time, browsers do not automatically apply dir=”ltr” nor dir=”rtl” to the HTML element for the appropriate layout direction. Adding this will change things like HTML tables re-ordering their cells horizontally and can be used in CSS files to apply alternative background images, flipped padding, margins, etc. using CSS selectors like this:

.foo {
  position: absolute;
  top: 10px;
html[dir=ltr] .foo {
  left: 10px;
html[dir=rtl] .foo {
  right: 10px;

There is no HTML5 API to to use the layout direction that comes from system settings. Strangely this HTML5 doc tells developers that they must manually add the direction even though in my opinion, the default should be that it comes from the system settings:

There is a dir=”auto” option:
but it has a few issues:

  1. Microsoft doesn’t support it.
  2. This is dependent on your page’s content instead of the system settings.
  3. This will prevent you from making CSS attribute selectors that resolve to “ltr” and “rtl” (it’ll be “auto” instead which defeats the purpose). There is a proposed CSS4 :dir(…) pseudo-class which would resolve auto to “ltr” and “rtl” but it is currently experimental and browser support is very weak.

Android 4.2 added support for right-to-left (RTL) layout:

iOS also has its own mechanism for this:

I was not able to find any Microsoft documentation that says whether UWP has anything equivalent to Android and iOS.

Unfortunately these disparate mechanisms are not abstracted into a unified, built-in Cordova API, the Cordova globalization plug-in, nor from what I can tell, any 3rd party plug-in.

This means you’ll either have to write your own Cordova plug-in using platform-specific code or alternatively add your own JavaScript code that uses the locale’s language code to determine whether you need to add dir=”ltr” or dir=”rtl” on your page’s HTML element.

Here is some sample JavaScript code to run when your page initially loads:

// Apply a "dir" attribute to the HTML element:
var bcp47Tag = ...; // e.g. "en-us", etc.
var scriptIndex = bcp47Tag.indexOf("-");
var language =
    scriptIndex == -1 ? undefined : scriptIndex).toLowerCase();
if (language == "ar" || // Arabic
 language == "dv" || // Divehi
 language == "ha" || // Hausa
 language == "he" || // Hebrew
 language == "iw" || // Hebrew (legacy code)
 language == "ps" || // Pashto, Pushto
 language == "fa" || // Persian (Farsi)
 language == "ur" || // Urdu
 language == "ji" || // Yiddish (legacy code)
 language == "yi") // Yiddish
  document.documentElement.setAttribute("dir", "rtl");
  document.documentElement.setAttribute("dir", "ltr");

Mobile Web Inspector Developer Tools

Posted on Updated on

What is a web inspector?

A web inspector is a developer tool that allows you to debug JavaScript, CSS, and HTML. You’ll usually get a file resource browser, performance monitoring tools, the ability to set code breakpoints (although in my experience breakpoints are somewhat flaky depending on which version of the mobile OS and desktop browser you are using–so often I resort to using the JavaScript “debugger” keyword to act like a breakpoint), the ability to edit HTML, and a tool for visualizing, resolving, and changing style properties–all without having to redeploy your application.

Apple introduced the ability to use the desktop Safari web inspector developer tools with iOS application WebViews and mobile Safari back in iOS 6 and Safari 6. Each new release of iOS has required that you use a corresponding version of desktop Safari so beware of this if you are planning to upgrade one device but not the other.

Google introduced the ability to use the desktop Chrome web inspector developer tools with Android application WebViews and mobile Chrome in Android 4.4 when the Chrome WebView was introduced. Many legacy Android devices are still being sold (let alone in use) but unfortunately, it is not compatible with the web inspector. For situations like that, there are some third party techniques available that require you to inject code into your application in order to send messages back and forth with a server. Those solutions have much fewer abilities than a formal web inspector. To combat this legacy issue, Google introduced a Google Play-updatable WebView in Android 5 Lollipop so your application can take advantage of new technologies even if the OS is not upgradeable.

Regardless of the platform, it is important to note that the WebView and the mobile browser are not equal. If something works in the browser, you cannot always expect it to work exactly the same way in the WebView. For example, on Android, I have seen as much as a major version number difference of 3 between the two. On iOS (prior to WKWebView), JavaScript performance was severely throttled compared to what mobile Safari had.

This post only discusses web inspectors. If you are interested in debugging Java code for your application, refer to the Oracle MAF developer guide for instructions.

Setting up your Oracle MAF Application

For iOS, there is no property to edit, you either need to use a debug deployment or use Xcode to run the application. For Android, you must edit the src/META-INF/maf.properties file of your application so that it defines:


You can only use a web inspector with development (aka non-production) applications.

If you want to connect the web inspector before the first screen loads, will need to edit your run configuration’s “Application Arguments” to specify the following which allows you to configure how many seconds before the WebView will get populated with content.

-featureContentDelay 20

If doing this in an already-generated Xcode project, this setting goes in the Run Scheme’s “Arguments Pass On Launch” field.

Setting up your Desktop Browser

I assume that you already have your device set up for development so I won’t cover it here (e.g. Android needs development mode and USB debugging turned on via tapping the build number 7 times, iOS needs the device set up as “Use for development”, etc.).

Desktop Chrome doesn’t require anything special but I use this optional “ADB” Chrome extension as a convenience since I find it easier to click an icon vs. typing a special URL in the address bar.

Desktop Safari requires you to enable the “Develop” menu in its Advanced Preferences dialog:

Safari Preferences Advanced Settings

Using the Safari Web Inspector

From the Safari Develop menu, your connected devices and iOS Simulator will display as submenus. Each submenu will list all of the WebViews that you are allowed to inspect (if you are not sure which one you want, a light blue highlight will appear on your device or in the simulator as you hover over each menu item).

Open an iOS WebView inspector

A web inspector window will open once you select that menu item:

Safari Web Inspector

The UI varies across versions of desktop Safari but I’ll describe one here as an example. The “Resources” tab (1) is where you can browse the DOM, look at scripts, style sheets, etc. When the HTML resource is selected, the main panel will show you the DOM tree (3) which you can manually browse for an element. Alternatively, you can use the crosshairs tool (2) to click on the screen (of the actual device or the simulator) to pick an element that you want to inspect.

With an element selected, you can then use the “Styles” tab (4) of the right panel to view the element’s style properties. This will show you the exact selectors that are providing each style to the inspected element (5). This is incredibly valuable, particularly when multiple selectors are competing (a line will strike out any styles that lose out due to some other more specific selector). You can also edit those values directly or add additional properties and see the change immediately take effect on the screen. Beware changes made in the inspector do not get saved permanently into your application. If you are trying to create a custom style sheet, you’ll need to jot down elsewhere the changes you’ve made; if you leave the page or close the app, you’ll lose your changes.

Using the Chrome Web Inspector

First, visit Chrome’s “chrome://inspect/#devices” page to see a list of your connected and debuggable Android devices. Each will appear with all of the WebViews that you are able to inspect. An icon will appear with a darker gray and the WebView listed towards the top will be what is currently visible on the Android screen.

Chrome Devices

A web inspector will open once you click the “inspect” link.

Chrome Web Inspector

The UI varies across versions of desktop Chrome but I’ll describe one here as an example. The “Elements” tab (1) is where you can browse the DOM. The main panel will show you the DOM tree (3) which you can manually browse for an element. Alternatively, you can use the magnifying glass tool (2) to click on the screen (of the actual device or the emulator) to pick an element that you want to inspect.

With an element selected, you can then use the “Styles” tab (4) of the right panel to view the element’s style properties. This will show you the exact selectors that are providing each style to the inspected element (5). This is incredibly valuable, particularly when multiple selectors are competing (a line will strike out any styles that lose due to some other more specific selector). You can also edit those values directly or add additional properties and see the change immediately take effect on the screen. Beware changes made in the inspector do not get saved permanently into your application. If you are trying to create a custom style sheet, you’ll need to jot down elsewhere the changes you’ve made; if you leave the page or close the app, you’ll lose your changes.

Further Reading


Blurry Graphics in ADF Faces

Posted on Updated on

Ever since Apple introduced the Retina Display in 2010, modern devices have changed to display content at twice (@2x), three times (@3x), four times (@4x) [or even fractions in-between] the resolution that we have been used to in the past.

For app developers using bitmap graphics, this can be a bit of a nightmare to support. You have to generate graphics at multiple resolutions and change your application to reference different sizes of graphics. Unless you are using photographic content, you may find it easier to deal with SVG (vector graphic) images instead.

In ADF Faces applications, there are at least 3 categories of ways to display images:

  1. Image components
  2. Components that have an image somewhere inside of it (and that don’t offer a style attribute explicitly for that image)
  3. CSS background-image styles



For all 3 use cases, simply use the .svg file as you have been accustomed to using for .png files. Just make sure the graphic was well-designed to look good on an @1x display if legacy support is important to you.

PNG (or other bitmap graphic)

For use case 1, you specify your image in the “source” attribute then the dimensions in the “inlineStyle” attribute.

For use case 2, you specify your image in the appropriate image attribute, e.g. “icon” and specify a marker “styleClass” that you’ll need to make a style block definition for (e.g. via an af:resource tag). This block will use that marker then space then “IMG” for its selector and then in the body of the block, specify the width and height.

For use case 3, you are dealing with CSS styles (e.g. in an af:resource). Since browser support is not universal, you will need to specify 3 kinds of selectors: (a) the default fallback for legacy browsers–where you define your @1x graphic, (b) the WebKit @2x override, (c) the modern @2x override. You can make additional blocks for @3x, @4x, etc. (You may optionally use this technique to hide/show specific component instances for use cases 1 & 2 too if you really want your app to display resolution-specific graphics.)

Sample code

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1"
  <jsp:directive.page contentType="text/html;charset=UTF-8"/>
    <af:document id="d1" title="Blurry Graphics" inlineStyle="padding:10px;">
      <f:facet name="metaContainer">
        <af:resource type="css">
          /* Dimensions for bitmap graphics on components that don't have
             style attributes for internal image elements. */
          .MyIconHolder IMG {
            width: 24px;
            height: 24px;
          /* Example of background-image graphics */
          .MyBackgroundPNGImage {
            background-repeat: no-repeat;
            width: 24px;
            height: 24px;
            background-image: url(images/image@1x.png);
          @media only screen and (-webkit-min-device-pixel-ratio: 2) {
            .MyBackgroundPNGImage {
              background-image: url('images/image@2x.png');
              -webkit-background-size: 24px 24px;
          @media only screen and (min-resolution: 2dppx) {
            .MyBackgroundPNGImage {
              background-image: url('images/image@2x.png');
              background-size: 24px 24px;
          .MyBackgroundSVGImage {
            background-repeat: no-repeat;
            width: 24px;
            height: 24px;
            background-image: url(images/image.svg);
      <af:form id="f1">
        <trh:tableLayout id="tl1" borderWidth="1">
          <trh:rowLayout id="rl1">
            <trh:cellFormat id="cf1" header="true">
              <af:outputText id="ot1" value="Use Case"/>
            <trh:cellFormat id="cf2" header="true">
              <af:outputText id="ot2" value="@1x PNG"/>
            <trh:cellFormat id="cf3" header="true">
              <af:outputText id="ot3" value="@2x PNG"/>
            <trh:cellFormat id="cf4" header="true">
              <af:outputText id="ot4" value="SVG"/>
          <trh:rowLayout id="rl2">
            <trh:cellFormat id="cf5" halign="center">
              <af:outputText id="ot5" value="af:image"/>
            <trh:cellFormat id="cf6" halign="center">
              <af:image id="i1" source="/images/image@1x.png"/>
            <trh:cellFormat id="cf7" halign="center">
              <af:image id="i2" source="/images/image@2x.png"
            <trh:cellFormat id="cf8" halign="center">
              <af:image id="i3" source="/images/image.svg"/>
          <trh:rowLayout id="rl3">
            <trh:cellFormat id="cf9" halign="center">
              <af:panelGroupLayout id="pgl1" layout="vertical">
                <af:outputText id="ot6" value="af:commandToolbarButton"/>
                <af:outputText id="ot7" value="(no style attribute for dimensions)"/>
            <trh:cellFormat id="cf10" halign="center">
              <af:commandToolbarButton id="ctb1" icon="/images/image@1x.png"/>
            <trh:cellFormat id="cf11" halign="center">
              <af:commandToolbarButton id="ctb2" icon="/images/image@2x.png"
            <trh:cellFormat id="cf12" halign="center">
              <af:commandToolbarButton id="ctb3" icon="/images/image.svg"/>
          <trh:rowLayout id="rl4">
            <trh:cellFormat id="cf13" halign="center">
              <af:panelGroupLayout id="pgl2" layout="vertical">
                <af:outputText id="ot8" value="af:panelGroupLayout"/>
                <af:outputText id="ot9" value="(background-image styling)"/>
            <trh:cellFormat id="cf14" halign="center" columnSpan="2">
              <af:panelGroupLayout id="pgl3" layout="vertical"
            <trh:cellFormat id="cf16" halign="center">
              <af:panelGroupLayout id="pgl4" layout="vertical"

iOS Web Inspector

Posted on Updated on

The content of this post has been updated with additional detail at:


CSS Shorthand Tokens

Posted on

In CSS, you will come across some shorthand notation for the margin, border-color, border-style, border-width, and padding properties. It isn’t obvious or easy to remember which token in the value applies to which side of the element so here’s a handy list of the 4 possible varieties:

  1. One token — all-sides-use-the-same-value
  2. Two tokens — top-and-bottom right-and-left
  3. Three tokens — top right-and-left bottom
  4. Four tokens — top right bottom left

At least the four-token example can be remembered by associating the element with a clock where time progresses clockwise.

HiDPI Images in MAF or ADF Mobile Applications

Posted on Updated on

Whether you are developing a MAF (or ADF Mobile) application or a classic ADF Faces application, it is becoming more and more important to support HiDPI screens (high resolution or “retina” displays). There is no easier way to make your application look out-dated than to use grainy, unprofessional image assets or use them improperly.

In HTML, the “px” unit (sometimes referred to as a “dp” or density-independent pixel) corresponds to the same amount of space regardless of the DPI of your screen (however, the number of screen pixels may vary). The original iPhone models did not have HiDPI displays. Each point of color on those screens corresponds to one HTML CSS “px” unit. Newer iPhone models introduced a HiDPI (or “retina”) display that has 4 screen pixels in the same amount of space that 1 screen pixel used to take up (2 screen pixels wide by 2 screen pixels tall); on these new screens, the width and height “px” values use twice the amount of screen pixels.

Why is this a common problem? Since MAF (or ADF Mobile) uses HTML, displaying an image is not as simple as just specifying the source path and magically hoping the browser will know that you are using a high resolution image. You must specify dimensions to go along with the source path.

Let’s work with an example. You have an image named “image-64.png”. This image has a size of 64 by 64 individual dots of color (individual points of color information). If you coded your page like the following, the image will be shown with a width of 64px and a height of 64px (one color dot per “px”):

<amx:image id="i1" source="images/image-64.png"/>

This would look just fine on a classic low-DPI display. However, on a HiDPI display, it still takes up the same space but since there are more screen pixels, the image will look very grainy.

In order to look crisp and professional, you need to set a size so that each dot of color corresponds to at least one screen pixel. For a HiDPI display, this means your image needs a width and a height specified such that you use 2 dots of image color information per HTML CSS “px” unit (e.g. a 64 by 64 sized image should be specified to use a width of 32px and a height of 32px. In code, your page should look like this:

<amx:image id="i1" inlineStyle="width:32px;height:32px" source="images/image-64.png"/>

Even if you still want to support legacy screens for your application, this same image (with the same specified width and height) will look beautiful on low-DPI screens because of how images are processed modern browsers.

If for some reason you really needed or wanted to specify alternate images for each kind of screen, you have the option to use a screen properties EL variable to toggle the rendered state of alternate amx:image components or simply use that EL to alter the inlineStyle and the source path as desired.

PNG vs. SVG?

Consider whether using PNG is really the right choice to begin with. SVG (scalable vector graphics) files tend to be smaller file sizes when created without excessive anchor points, no embedded bitmap data, reduced decimal number precision, excess whitespace removed, and comments removed. If the resolution of your display gets better, the SVG will look that much better; you don’t need multiple resolution versions of the same image resources. If the SVG was given the proper width/height to begin with by its creator, you won’t even need to muck with inlineStyles since the image will naturally be displayed at the proper size.

One-off ADF component skin appearance

Posted on Updated on

Have you ever wanted to make an ADF Faces Rich Client component have a unique appearance but not change all other instances of that component? You can as long as the things you want to change are not skin properties or skin icons (server-side aspects like properties and icons are not part of the client-side generated style sheet so this client-side solution will not allow you to change them).

Let’s start with an interactive example; the skinning demo pages for the ADF Faces Rich Client:

On this page, there is a right-hand side where you can see some example inputText components.  When you click on the checkboxes on the left-hand side of this page, the appearance of those start to change.  However, the inputText for the find field at the top of the page does not change.  This is because of some containment selector definitions in the skin used on this page that confines the custom styling to instances of the inputText that are contained in another component that has a particular style class.  Since the find field is not inside of that container, these custom styles do not apply to that field.

Let’s say your page has a structure like this:

<af:panelGroupLayout id="pgl1" layout="scroll" styleClass="SpecialMarker">
  <af:inputText id="it1" label="Name"/>

To style that inputText specially in this container, you would create skinning definitions like this:

.SpecialMarker af|inputText {background-color:pink}
.SpecialMarker af|inputText::access-key {color: aqua;}
.SpecialMarker af|inputText::content {background-color:red}
.SpecialMarker af|inputText::label {font-weight: bold}

Alternatively, you could put your marker directly on the inputText like this:

<af:inputText id="it1" label="Name" styleClass="SpecialMarker"/>

and have skinning definitions like this:

af|inputText.SpecialMarker {background-color:pink}
af|inputText.SpecialMarker af|inputText::access-key {color: aqua;}
af|inputText.SpecialMarker af|inputText::content {background-color:red}
af|inputText.SpecialMarker af|inputText::label {font-weight: bold}