HTML Layout Guidelines for ASP.NET Web Page Globalization

The best practice for HTML layout is to ensure that localizers need to translate only strings, because the user interface sizes all controls to fit the text that the strings contain. This is a benefit because the step of manually resizing controls is removed from the localization process, thereby removing the errors and bugs that can result. However, the layout of the controls changes depending on string lengths, so localized Web sites need to be carefully tested.

The following list provides recommended guidelines for designing ASP.NET Web pages for globalization.

  • Avoid using absolute positions.

    Specifying absolute positions prevents elements from being automatically positioned and sized. The following code example demonstrates what not to do.

    <!-- Do not do this. -->
    <div id = idFindWhatLabel style = "position: absolute; left: 0.98em; top: 1.2168em; width: 4.8em; height: 1.2168em;">
  • Use the available width and height for forms.

    There are two ways to do this, as follows:

    • Size major elements, such as tables, to a width that is equal to 100 percent.

      For example:

      <!-- A table sized to take up entire width of the form.-->
        <table width=100%>
    • Size elements using cascading style sheet expressions based on the overall size of the form.

      For example:

      <!-- A div element sized to take up half the width and height of the form. -->
      <div style=' 
        height: expression(document.body.clientHeight / 2);
        width: expression(document.body.clientWidth / 2); '>
  • Use a separate table cell for each control.

    Doing this allows text to wrap independently and ensures correct alignment for cultures in which text layout flows from right to left.

  • Allow wrapping text and avoid using the nowrap attribute for table cells that contain text.

    Use the nowrap attribute only when you want the text to stay on one line and there is enough room for the text to expand to accommodate any language.

  • Separate check boxes and radio buttons from their label text.

    Place the labels for check boxes and radio buttons in cells that are separate from the controls. This allows the text to wrap correctly when the text expands. However, you should still design the form so that the text has a reasonable chance of staying on one line when it is translated.

  • Leave room for growth and avoid fixed widths.

    Text can expand when translated into other languages. A good rule of thumb is to leave room for 300 percent growth on short strings (less than 10 characters), 200 percent growth on medium strings (from 10 through 20 characters), and 100 percent growth on large strings (more than 20 characters).

    One acceptable solution is to set the table cell width to a percentage of the form width so that the cell can expand relative to the entire table. However, try to specify as few relative sizes (other than 100 percent) as possible, because you want the HTML layout engine to do most of the work for you.

    For example:

    <!-- The table cell is sized to take up one quarter of the width of the table. -->
    <td width=25%>
  • Size buttons in as few places as possible.

    Often there is a set of buttons that should have the same size. Set this size in one place for the entire set of buttons, if possible. Allow room for the text to expand in list boxes and group boxes.

  • Set the height as seldom as possible.

    Do not set the cell height for any table cell or control that contains text. (You can set the line height for cascading style sheet elements.) Otherwise, the look of the page changes, if the user sets the text size in the browser.

  • Do not use left- or right-align in HTML tags.

    In general, avoid setting align="left" or align="right" for any table cell. These settings can interfere with the layout of forms for cultures in which text layout flows from right to left.

  • Avoid inline cascading style sheet values that might need to be changed.

    Keep all cascading style sheet values that localizers might need to change in style sheets, rather than inline. This includes setting the font for a page.

See Also

Other Resources

ASP.NET Globalization and Localization