Web Q&A

Font Sizing, Internationalization in JScript, and More

Edited by Nancy Michell

Q I'm creating new Cascading Style Sheet (CSS) styles for my project. For the best compatibility between several display resolutions and browsers, is it better to use pixels (px) or points (pt)?

Q I'm creating new Cascading Style Sheet (CSS) styles for my project. For the best compatibility between several display resolutions and browsers, is it better to use pixels (px) or points (pt)?

A Font sizes aren't usually specified in px in a production environment—instead, pt or em (a relative size) are generally used. Most sites that really want to control layout and have a target browser in mind (usually Microsoft® Internet Explorer) tend to use pt because they can get something like 8pt Verdana pretty easily and it looks the same way in Word. Sites that focus on accessibility and cross-browser, cross-platform compatibility tend to use em because it gives the user control over the size of the font in his browser (which won't work with either px or pt). The trade-off is that it's actually much harder to get font sizing to come out the way you want it to when you use em because the measurement is based on the current location in the Document Object Model (DOM). Figure 1 shows how this works.

A Font sizes aren't usually specified in px in a production environment—instead, pt or em (a relative size) are generally used. Most sites that really want to control layout and have a target browser in mind (usually Microsoft® Internet Explorer) tend to use pt because they can get something like 8pt Verdana pretty easily and it looks the same way in Word. Sites that focus on accessibility and cross-browser, cross-platform compatibility tend to use em because it gives the user control over the size of the font in his browser (which won't work with either px or pt). The trade-off is that it's actually much harder to get font sizing to come out the way you want it to when you use em because the measurement is based on the current location in the Document Object Model (DOM). Figure 1 shows how this works.

Figure 1 Different Font Specs

<html>
<head>
<style>
     .sizedPt { font-family:verdana; font-size:8pt; color:red; }
     .sizedEm { font-family:verdana; font-size:.68em; color:blue;}
</style>
</head>
<body>

<!-- Note here that with nesting, the TD with the style shows text 
     smaller, but a table with the same style on an internal 
     TD doesn't -->
<table class="sizedEm" border="1">
   <tr>
      <td class="sizedEm">
         <p>Some Text</p>
         <table border="1">
            <tr>
               <td class="sizedEm">
                  <p>Some more text</p>
               </td>
            </tr>
         </table>
      </td>
   </tr>
</table>

<p>&#160;</p>

<!-- Note here that even with nesting, everything is 8pt -->
<table class="sizedPt" border="1">
   <tr>
      <td class="sizedPt">
         <p>Some Text</p>
         <table border="1">
            <tr>
               <td class="sizedPt">
                 <p>Some more text</p>
               </td>
            </tr>
         </table>
      </td>
   </tr>
</table>
</body>
</html>

Figure 2 Large Font Browser Setting

Figure 2** Large Font Browser Setting **

Figure 2 and Figure 3 show how the font size is affected by changing the font settings in the browser. As you see in the bottom table in each figure, the red text size does not change. Having a font size that can't change is good if you must have a degree of control over your layout, but remember, it's very convenient for users to be able to set the type to a size that's comfortable for them to read.

Figure 3 Small Font Browser Setting

Figure 3** Small Font Browser Setting **

Q I've come to the conclusion that there isn't really any international support in JScript®. Is this correct, or am I missing something? For example, on a German locale where the decimal character is a comma instead of a period, the real and expected results of several operations are as follows:

var x = "123,45";
alert(parseFloat(x)); // shows 123, expected be 123,45
alert(parseInt(x));   // shows 123, correct
alert(Number(x));     // shows NaN, expected 123,45
alert(isNaN(x));      // shows true, expected false

Q I've come to the conclusion that there isn't really any international support in JScript®. Is this correct, or am I missing something? For example, on a German locale where the decimal character is a comma instead of a period, the real and expected results of several operations are as follows:

var x = "123,45";
alert(parseFloat(x)); // shows 123, expected be 123,45
alert(parseInt(x));   // shows 123, correct
alert(Number(x));     // shows NaN, expected 123,45
alert(isNaN(x));      // shows true, expected false

Also, what if I want to convert from German to English?

A There is some international support in JScript. For example, there's the toLocaleString methods of Number and Date, the toLocaleDateString and toLocaleTimeString methods of the Date object, and the toLocaleLowerCase and toLocaleUpperCase methods of the String object. All are relatively recent additions to the language—with the exception of toLocaleString on Date, which has been around since the beginning, but did not actually output a localized date string! However, there is not much support for going the other way—turning localized strings into dates, numbers, currencies, and so on, which it looks like you want to do. This is unfortunate. For internationalization, use VBScript.

A There is some international support in JScript. For example, there's the toLocaleString methods of Number and Date, the toLocaleDateString and toLocaleTimeString methods of the Date object, and the toLocaleLowerCase and toLocaleUpperCase methods of the String object. All are relatively recent additions to the language—with the exception of toLocaleString on Date, which has been around since the beginning, but did not actually output a localized date string! However, there is not much support for going the other way—turning localized strings into dates, numbers, currencies, and so on, which it looks like you want to do. This is unfortunate. For internationalization, use VBScript.

In Andrew Clinick's MSDN® Library article "It's All Greek to Me", the following code sets the locale to German, converts the value, multiplies it by the exchange rate, and converts it into a currency variant. After the conversion, the locale is set back to UK English and the currency is formatted in UK English format.

sub button2_onclick
   dim original
   original = setlocale("de")
   myvalue = CCur(GermanNumber.value * 2.89)
   original = setLocale("en-gb")
   USNumber.value = formatCurrency(myvalue)
end sub

Q How can I make the contents of a <td> element in an HTML table clickable? Currently, my code looks something like this:

<td><a href="https://somewhere"><img src=blah></a></td>

The problem with this is that the image inside the <td> is relatively small, while the cell is much bigger. Is it possible to make the whole <td> clickable, including the blank area around the small image? Here's my idea:

<td href="https://somewhere"><img src=blah></td>

Q How can I make the contents of a <td> element in an HTML table clickable? Currently, my code looks something like this:

<td><a href="https://somewhere"><img src=blah></a></td>

The problem with this is that the image inside the <td> is relatively small, while the cell is much bigger. Is it possible to make the whole <td> clickable, including the blank area around the small image? Here's my idea:

<td href="https://somewhere"><img src=blah></td>

A There are a couple of ways to do this, depending on your application. You could pad the image with a transparency or background color to fill the table cell. If the image is a GIF, it will add hardly anything to the size. But if you enlarge the image this way, the table containing it will not scale well with the user's changing font settings—it will be either too big or too small.

A There are a couple of ways to do this, depending on your application. You could pad the image with a transparency or background color to fill the table cell. If the image is a GIF, it will add hardly anything to the size. But if you enlarge the image this way, the table containing it will not scale well with the user's changing font settings—it will be either too big or too small.

If you want to use an image and don't have any other content in your <td>, you can always scale it to the size of the cell:

<td><a href="https://somewhere"><img src="img.gif" width="100%" height="100%" /></a></td>

If you have other content in the table cell and you want it all to be clickable but still use an anchor tag <a>, then you can use that same code and just wrap all of the content in the anchor tag. If you want to make the <td> clickable and don't mind using JScript, you can do this:

<script language="javascript">
  function elementClicked(oElement) {
       if (oElement == tdClick) {
           location.href = "somewhere";
       }
   }
   </script>
   <td id="tdClick"
    onclick="elementClicked(this)">
    HTML content here</td>

You can also put the script in the tag:

<td id="tdClick" onclick="javascript:location.href='somewhere';"> HTML content here</td>

However, the onclick event won't work in Netscape (because of limited DHTML support). The earlier suggestion

<td><a href="https://somewhere"><img src="img.gif" width="100%" height="100%" /></a></td>

will work just fine in both Internet Explorer and Netscape, but you'll get those weird scaling issues if the image actually has content (rather than a blank GIF).

Q I have two ASP files: input1.asp and input2.asp. Input1.asp is:

<%
  Dim sInput
  sInput = Request.Form("txtFile")  
%>
 
<HTML>
  <BODY> 
    <form name="frmProcess" method="post" action="input1.asp">
      <input type="text" name="txtFile" value="<%=sInput%>">
      <input type="submit" value=Submit>
    </form>
  </BODY> 
</HTML>

Q I have two ASP files: input1.asp and input2.asp. Input1.asp is:

<%
  Dim sInput
  sInput = Request.Form("txtFile")  
%>
 
<HTML>
  <BODY> 
    <form name="frmProcess" method="post" action="input1.asp">
      <input type="text" name="txtFile" value="<%=sInput%>">
      <input type="submit" value=Submit>
    </form>
  </BODY> 
</HTML>

The content of input2.asp is the same except that action is now set equal to input2.asp and the input type is file. The problem is that when I enter something in input1.asp and hit submit, the value of the textbox is retained even after the page is refreshed.

As you can see, I am taking advantage of the "value" attribute on the element. Why can't I do that to the <input type="file"> object? In MSDN Library documents I don't see a "value" attribute available for type="file". Is this by design? I don't want the user to have to fill in the path every time the submit button is clicked. It would be good if the value could be retained in the input field.

A This question has come up before, so here's the overview. Security reasons dictate the fact that you cannot modify the value attribute of <input type="file" /> elements. If that were possible, then you could completely script the uploading of documents from a user's machine without their knowledge. For the value of the input to be modified, users are required to do it themselves.

A This question has come up before, so here's the overview. Security reasons dictate the fact that you cannot modify the value attribute of <input type="file" /> elements. If that were possible, then you could completely script the uploading of documents from a user's machine without their knowledge. For the value of the input to be modified, users are required to do it themselves.

Q What is considered correct behavior for generating UTF-8 files? Should HTML files have Byte Order Marks (BOMs)? If a file is marked as charset=utf-8 must it have a BOM or not? Is it acceptable to have one? What about UTF-8 text files and XML files? The problem that prompted this question was that some of my Japanese UTF-8 pages were not displaying in Internet Explorer unless the BOM was present. It turns out that the behavior was caused by the Title tag preceding the charset=utf-8 meta tag. Apparently, the initial scan for the meta tag stopped when it hit the non-ASCII characters and the auto-detect didn't identify the page as UTF-8. Moving the Title tag after the charset=utf-8 meta tag resolved it, but left me wondering about when to use a BOM.

Q What is considered correct behavior for generating UTF-8 files? Should HTML files have Byte Order Marks (BOMs)? If a file is marked as charset=utf-8 must it have a BOM or not? Is it acceptable to have one? What about UTF-8 text files and XML files? The problem that prompted this question was that some of my Japanese UTF-8 pages were not displaying in Internet Explorer unless the BOM was present. It turns out that the behavior was caused by the Title tag preceding the charset=utf-8 meta tag. Apparently, the initial scan for the meta tag stopped when it hit the non-ASCII characters and the auto-detect didn't identify the page as UTF-8. Moving the Title tag after the charset=utf-8 meta tag resolved it, but left me wondering about when to use a BOM.

A It used to be thought that placing a UTF-8 BOM at the beginning of a file was undesirable, but should be respected if it's present. However, this has been challenged recently. Browsing the Web to find discussions on this issue led to this: https://www.unicode.org/unicode/faq/utf_bom.html#29, which asks if a UTF-8 data stream can contain the BOM character (in UTF-8 form) and, if so, whether you can still assume that the remaining bytes are in big-endian order.

A It used to be thought that placing a UTF-8 BOM at the beginning of a file was undesirable, but should be respected if it's present. However, this has been challenged recently. Browsing the Web to find discussions on this issue led to this: https://www.unicode.org/unicode/faq/utf_bom.html#29, which asks if a UTF-8 data stream can contain the BOM character (in UTF-8 form) and, if so, whether you can still assume that the remaining bytes are in big-endian order.

Yes, UTF-8 can contain a BOM. But it doesn't affect the order of the byte stream. UTF-8 always has the same byte order. So, UTF-8 BOMs are acceptable, but don't indicate byte-ordering.

One bad thing is that old browsers display garbage when the BOM is at the beginning of an HTML file. How old those browsers have to be for this to happen is uncertain, so if you have to support every old browser, test on your targets or leave it out.

Some used to think that placement of a BOM at the start of a UTF-8 file was a nonstandard Notepad-specific behavior. UTF-8 BOMs do, however, allow parsers to recognize the encoding of files more efficiently and unambiguously.

Q Is there a technique (either ASP.NET or plain DHTML) that can produce a multicolumn page, similar to a newspaper? Specifically, the effect I'm looking for is that content would be rendered in column1, and when the bottom of column1 is reached, it would continue at the top of column2. When the bottom of column2 is reached, it would continue on top of column3, and so on. I need to apply this effect to the way cells are rendered in a <TABLE>. An ASP.NET solution is preferred, but I'll take DHTML as well. The text for the columns is based on a SQL Server™ query result.

Q Is there a technique (either ASP.NET or plain DHTML) that can produce a multicolumn page, similar to a newspaper? Specifically, the effect I'm looking for is that content would be rendered in column1, and when the bottom of column1 is reached, it would continue at the top of column2. When the bottom of column2 is reached, it would continue on top of column3, and so on. I need to apply this effect to the way cells are rendered in a <TABLE>. An ASP.NET solution is preferred, but I'll take DHTML as well. The text for the columns is based on a SQL Server™ query result.

A There is no easy or effective way to do this with ASP.NET, HTML, or DHTML. You could do it with System.Drawing in ASP.NET, but that is probably not what you're looking for. The only way this would ever change is if the general HTML specs were enhanced. If you can figure out how many rows will fit on the client page, you should be able to data-bind a DataList or dynamically render an HTML table with just the rows you want.

A There is no easy or effective way to do this with ASP.NET, HTML, or DHTML. You could do it with System.Drawing in ASP.NET, but that is probably not what you're looking for. The only way this would ever change is if the general HTML specs were enhanced. If you can figure out how many rows will fit on the client page, you should be able to data-bind a DataList or dynamically render an HTML table with just the rows you want.

Assuming you can grab the size of the viewable space on the client and can calculate the number of rows that would fit there, you should be able to render each column and just show the appropriate "window" of data for each row. The other hard part about doing this type of layout is changing the rows when the user resizes the page. An alternate method might be to return XML to the client and populate the page via the DHTML DOM and JavaScript on the client. This way, the page could re-render itself dynamically if the user resized. This will take some work to accomplish. However, if you really are considering formatting your pages this way, remember that reading columns on the screen is difficult for users.

Q When I set Internet security to high (disable Active Scripting) and also block all cookies from Internet Explorer, and then go to Expedia.com, I see that Expedia.com can detect that Active Scripting is disabled. I checked out the NetMon trace, but still can't figure out how the information is passed around.

Q When I set Internet security to high (disable Active Scripting) and also block all cookies from Internet Explorer, and then go to Expedia.com, I see that Expedia.com can detect that Active Scripting is disabled. I checked out the NetMon trace, but still can't figure out how the information is passed around.

A Take a look at https://www.w3schools.com/asp/asp_browser.asp. When a browser connects to a server, an HTTP User Agent Header is also sent to the server. This header contains information about the browser (such as browser type and version number). The BrowserType object then compares the information in the header with information in a file on the server called Browscap.ini.

A Take a look at https://www.w3schools.com/asp/asp_browser.asp. When a browser connects to a server, an HTTP User Agent Header is also sent to the server. This header contains information about the browser (such as browser type and version number). The BrowserType object then compares the information in the header with information in a file on the server called Browscap.ini.

While the User Agent identifies the browser, it does not indicate whether the user of the browser has disabled script. There are several, completely client-side ways you can detect it, though. Most common is the use of the <noscript> tag. For example:

<script language="javascript">
  document.write("You have script enabled");
</script>
<noscript>You do not have script enabled</noscript>

The contents of the noscript tag are only rendered when script is not available.

Got a question? Send questions and comments to webqa@microsoft.com.

Thanks to to the following Microsoft developers for their technical expertise: Peter Averill, Dan Battagin, Mike Bizub, Daniel Boerner, Jerry Bryant, Andrew Clinick, Bryant Fong, Davide Garghentini, Pranav Kandula, Michael Kaplan, Michael Kung, Eric Lippert, Kirk Marple (Volt), Sajee Mathew, Harley Rosnow, Murray Sargent, Sean Shi, Chad Shurtz, Tommy Unger, Steve Van Dongen, Joel Varland