Friday, February 13, 2009

How to make a textbox and a textarea same width across browsers

Update: It's been a long while since I've written this post. For a better way to solve this problem, please see http://www.w3schools.com/cssref/css3_pr_box-sizing.asp (http://caniuse.com/#search=box-sizing)

Thanks to the *brilliant* CSS box model, very simple tasks have become a nightmare.

I've been struggling lately to do a very simple thing, which is to make a textbox (ie. <input type="text">) and a textarea same width so that they align nicely.

The problem with making a textbox and textarea same width is that all browsers add 1px padding to textboxes that can't be removed. In other words, setting the padding to 0px won't remove that 1px padding. A common trick to get rid of padding is to float the element but unluckily this doesn't work with textboxes. Well, this means we have extra 2px in the width of the textbox that we simply can't get rid of. Now, this wouldn't be a problem if the same thing applied to textreas as well but unfortunately this is not the case. In most browsers (IE, Safari and Chrome), setting the padding of a textrea to 0px *unfortunately* works. One exception to this is FireFox which applies the 1px non-removable padding to textareas as well. This is why the problem doesn't exist with FireFox. But, should we ignore IE, Safari and Chrome and assume everyone is using FireFox? I guess not, it definitely makes more sense to make it work in those browsers and find a hack for FireFox and actually this is what I did.

Having had a look on mozilla's website, I came across those two extensions to CSS:
-moz-padding-start and -moz-padding-end.

So, to make a textbox and a textrea same width across browsers you can use this code:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<style type="text/css">
*
{
    padding: 0px;
    margin: 0px;
}
#textbox
{
    width: 500px;
    -moz-padding-start: 1px;
    -moz-padding-end: 1px;
}
#textarea
{
    width: 500px;
    padding: 1px;
}
</style>
</head>
<body>
<input type="text" id="textbox" /><br />
<textarea id="textarea"></textarea>
</body>
</html>

Adding 1px to the textrea makes the text look nicer than with no padding at all (with 0px padding, the text sticks to the border which is not visually appealing). In FireFox, we will have 2px padding for the textarea and 2px left and right padding for the textbox, but, visually speaking, it almost looks the same (try to view the code in FireFox).

This code was tested in IE, Safari, Chrome, FireFox and SeaMonkey (which uses the same rendering engine as FF) and worked perfectly. Note that this hack is not perfect. For example, Opera will display the textarea 2px wider than the textbox. For me I don't care about Opera very much (not so many people use it), besides it's only 2px, so, it's not something that will make your site unusable. There could probably be a hack for Opera too but again I'm not interested in Opera, so for me it's not worth the time. It probably won't work with other less popular browsers too. I tested it in the ones I care most about (2 extra pixels in a not popular browser is not a big deal. I can live with that).

In terms of rendering engines (aka layout engines), this will work with Trident based browsers (Internet Explorer), WebKit based browsers (Safari, Google Chrome and other browsers) and Gecko based browsers (FireFox, SeaMonkey and other browsers).

Please note that this won't work if the visual styles are not enabled in Windows XP or Vista (with the exception of FireFox and the other browsers that are based on the same engine), but as very few people (almost none) disable the visual styles so I'm not so worried about that one too.

Finally, if you're a control freak and want it to work in every browser then your last resort is javascript (I was working on that but gave up on it after I came up with this simple hack), but even this won't work if javascript is disabled in the browser.

Saturday, December 27, 2008

How to align checkboxes and their labels consistently across browsers

I was trying today to get a checkbox and its label to look consistent across browsers and finally came up with this solution. I tested it in IE6, FF2 and Chrome and it rendered same pixel by pixel in all the three browsers (also browsershots.org confirmed the result for other browsers). Hopefully this will save time for someone else.

<style type="text/css">
*
{
    padding: 0px;
    margin: 0px;
}
#wb
{
    width: 15px;
    height: 15px;
    float: left;
}
#somelabel
{
    float: left;
    padding-left: 3px;
}
</style>

<div>
<input id="wb" type="checkbox" /><label for="wb" id="somelabel">Web Browser</label>
</div>

* If you don't want to set the padding and margin to zero for all elements as I did here, you could only set them for the label and checkbox.

Wednesday, October 15, 2008

A problem when setting the page title dynamically in ASP.NET

Today I encountered a weird problem with ASP.NET. What I wanted to do was really simple. I wanted to change the page title dynamically in code, that's all. In my scenario I had a page that inherits from a basepage class. In that base page class I append the site name to the page title, e.g. if the page title is 'page title' (without the quotes) and the site name is 'mysite.com', I add the site name to the page title so that it becomes 'page title - mysite.com'

In my page, I overrode OnLoad and set the page title in there, but for an unknown reason I always got an empty string for the page title in the basepage class. So, I created a test page, overrode OnLoad() and set the page title in there, surprisingly that worked. I couldn't see any difference between the two pages, I commented all my code and still got a blank title in the basepage class. Finally, I noticed that the only difference between the two pages is that in my page, the title is set to an empty string in the page directive (ie. Title=""). While in the test page, the title is set to the default value (which is "Untitled Page"). By not keeping the title set to an empty string (just put anything in there) it finally worked.

This seems like a bug, I doubt this behavior is by design. Anyway, to sum up. If you want to set the page title dynamically in your code, make sure you have a "non empty string" for the page title, i.e., if you have Title="" in your page directive, replace it with any other value, e.g. Title="some value" (even though you're going to change this value), otherwise, it will not work.

Thursday, September 4, 2008

Are Web Designers Getting too Lazy?!!

Recently, I changed the color scheme on my computer because I was literally starting to look like a raccoon (with incredibly dark circles under my eyes). Anyway, I changed the background color of all windows to black and the text color to light gray. After I made the changes, I started to surf the net to realize that so many websites don't specify the colors for the page background and/or the text. They leave them to the browser's default colors!! I had strange (and ugly) looking websites on my computer (sadly, so many of them for well-known and popular websites). I got some pages with white background (they specified the background color correctly) but with light gray for the text! which is almost unreadable. Some other websites had black for the text color and also black for the background! which is completely unreadable! (they specified the text color but not the background color), and many websites didn't specify both, so you have black background and light gray text with the images having white background which is really ugly!

What the heck is going on?! Are web designers getting so lazy that they decided to depend on the browser's default color settings as if they were hard-coded?!! Didn't it come to their minds that anybody can change the color scheme? It's only two lines in CSS for God's sake!!!!

Tuesday, May 27, 2008

The Myth of for being faster than foreach

You probably, like me, heard this so many times that for is faster than foreach and you should use it whenever you can. Well, today I wanted to know how much this is true so I did a little test (find below the test and results). As you can see in the results of the test they are both identical but as I find using foreach is much more convenient for many reasons (including thread safety in some scenarios) so it makes more sense to use foreach whenever possible.

More details:

The release build was used in the test
Software used in the test:
  • Windows XP Pro SP2
  • .NET Framework 2.0

The specs of my computer (where the test was done) are:
  • CPU Intel 1.6GHz Dual Core
  • 1024 MB RAM


Used Code
using System;
using System.Collections.Generic;
using System.Text;

namespace for_vs_foreach
{
    class Program
    {
        static void Main(string[] args)
        {
            const int LOOP_COUNT = 10000000;
            int myVar;
            MyCustomObject[] customObjects = new MyCustomObject[LOOP_COUNT];
            for (int i = 0; i < LOOP_COUNT; i++)
            {
                customObjects[i] = new MyCustomObject(i);
            }

            System.Threading.Thread.Sleep(1000);

            // foreach
            //
            DateTime beforeForeach = DateTime.Now;
            foreach (MyCustomObject customObject in customObjects)
            {
                myVar = customObject.Var;
            }
            DateTime afterForeach = DateTime.Now;

            // for
            //
            DateTime beforeFor = DateTime.Now;
            for (int i = 0; i < LOOP_COUNT; i++)
            {
                myVar = customObjects[i].Var;
            }
            DateTime afterFor = DateTime.Now;

            Console.WriteLine("{0} (foreach test results)", afterForeach.Subtract(beforeForeach));
            Console.WriteLine("{0} (for test results)", afterFor.Subtract(beforeFor));
            Console.Read();
        }
    }

    public class MyCustomObject
    {
        public MyCustomObject(int var)
        {
            _var = var;
        }

        private int _var;
        public int Var
        {
            get
            {
                return _var;
            }
            set
            {
                _var = value;
            }
        }
    }
}
Results: 00:00:00.0625000 (foreach test results)
00:00:00.0625000 (for test results)

Saturday, May 10, 2008

Efficiently Copying Items from One Array to Another in C# (Also generally in .NET)

I've been searching recently for an efficient way in C# to copy items from an array to another. At first it seemed that efficient way simply didn't exist. In C++ you can do this very easily by copying the memory block using memcpy() or memmove() but in C# you can't do this in a safe way (sure you can write some unsafe code but this is not really what I wanted, I just wanted to do it the 'clean and safe way'). Anyway, my options were to use Array.Copy() or a for loop (iterate through the source array and copy the items to the destination array). Unfortunately the documentation for Array.Copy() clearly states that it's an O(n) operation where n is length, so, it seemed that the for loop and Array.Copy() were almost equivalent so I decided I could use any of them as it wouldn't make any real difference (my decision was based on what's written in the documentation about Array.Copy() being an O(n) operation)

Anyway, today I was using .NET Refelctor to view the code for List<T>.ToArray(), I found that the Array.Copy() was used in the code, see below the code for List<T>.ToArray() copied from .NET Reflector:

public T[] ToArray()
{
    T[] destinationArray = new T[this._size];
    Array.Copy(this._items, 0, destinationArray, 0, this._size);
    return destinationArray;
}

So, I wanted to have a look on Array.Copy(), this is how it shows in .NET Refelctor:

[ReliabilityContract(Consistency.MayCorruptInstance, Cer.MayFail)]
public static void Copy(Array sourceArray, int sourceIndex, Array destinationArray, int destinationIndex, int length)
{
    Copy(sourceArray, sourceIndex, destinationArray, destinationIndex, length, false);
}

The code for Copy(sourceArray, sourceIndex, destinationArray, destinationIndex, length, false); can't be viewed using .NET Reflector, here's what you get:

[MethodImpl(MethodImplOptions.InternalCall), ReliabilityContract(Consistency.MayCorruptInstance, Cer.MayFail)]
internal static extern void Copy(Array sourceArray, int sourceIndex, Array destinationArray, int destinationIndex, int length, bool reliable);

To make a long story short I just was curious to see whether using Array.Copy() is really equivalent to using a simple for loop, so, motivated by my inability to view the code for Array.Copy(),I decided to do my own testing (see the code and results below). Well, despite what's written in the documentation about Array.Copy() being an O(n) operation, Array.Copy() was 10 times faster on my computer! So my guess is that it internally uses some memory copying so it's not really an O(n) operation.

Update:

Just to be clear, when I said the operation is not O(n), I was referring to the implementation not using a for loop to copy the items (ie. from the performance point of view). I realize it's technically incorrect to say it's not O(n). My apology for the confusion.

More details:

The release build was used in the test
Software used in the test:
  • Windows XP Pro SP2
  • .NET Framework 2.0

The specs of my computer (where the test was done) are:
  • CPU Intel 1.6GHz Dual Core
  • 1024 MB RAM


Used Code
using System;
using System.Collections.Generic;
using System.Text;

namespace array_copy
{
    class Program
    {
        static void Main(string[] args)
        {
            const int ArraySize = 5000;
            const int LoopCount = 100000;

            MyCustomObject[] customObjects1 = new MyCustomObject[ArraySize];
            MyCustomObject[] customObjects2 = new MyCustomObject[ArraySize];
            for (int i = 0; i < ArraySize; i++)
            {
                customObjects1[i] = new MyCustomObject(i);
                customObjects2[i] = new MyCustomObject(i);
            }

            // Array.Copy()
            //
            DateTime beforeArrayCopy = DateTime.Now;
            for (int j = 0; j < LoopCount; j++)
            {
                Array.Copy(customObjects1, 0, customObjects2, 1, customObjects1.Length - 1);
            }
            DateTime afterArrayCopy = DateTime.Now;

            // For Loop Copy
            //
            DateTime beforeForLoopCopy = DateTime.Now;
            for (int j = 0; j < LoopCount; j++)
            {
                int length = customObjects1.Length - 1;
                for (int i = 0; i < length; i++)
                {
                    customObjects2[i + 1] = customObjects1[i];
                }
            }
            DateTime afterForLoopCopy = DateTime.Now;

            Console.WriteLine("{0} Array.Copy()", afterArrayCopy.Subtract(beforeArrayCopy));
            Console.WriteLine("{0} For Loop Copy", afterForLoopCopy.Subtract(beforeForLoopCopy));

            Console.Read();
        }
    }

    public class MyCustomObject
    {
        public MyCustomObject(int var)
        {
            _var = var;
        }

        private int _var;
        public int Var
        {
            get
            {
                return _var;
            }
        }
    }
}
Results: 00:00:00.5937500 Array.Copy()
00:00:04.9062500 For Loop Copy

Friday, April 25, 2008

Redirecting The Ouput of a Command to the Clipboard

I very often use the command line to list file names using the dir command (for web design and other purposes). I usually need to have those file names in notepad. One way to do that is to redirect the command ouput to a file (copy the text from the file then delete it) or mark the text in the command line window and press Enter to copy it to the clipboard. A nicer and cleaner way though is to redirect the output of the command to the clipboard. Unfortunately there's no built-in way for doing this in Windows XP, however, it can be added very easily. In Windows 2003 we have a file called clip.exe (under the Windows or system32 directory, not sure, so search for it), which we can use to redirect the output of any command to the clipboard, but first if you're using Windows XP, copy this file to the Windows or System32 directory on your computer (obviously you'll need a computer with Windows 2003 to get this file, you might as well try seraching the internet, it's most probably there).

Now to redirect the output of your command to the clipboad, just use a pipe with clip, for example:

dir /b | clip

* If you're wondering what the /b switch does, it displays the bare file names (only the file names with no headers or any other information)