the properties on the controls directly as you saw earlier, these properties, like BackColor and
ForeColor, are transformed into client-side HTML and CSS.
Note that this skin markup is similar to the markup of a button. A few differences exist, though.
First of all, the control in the skin file cannot have an ID attribute. The ID is used to uniquely identify
a control in a page, and because the skin is applied to all controls, there’s no point in giving it
an ID. Another difference is the number of attributes you can set in the markup. Not all properties
of a control are skinnable. For example, you can’t set the Enabled property of the Button through a
skin. Microsoft’s MSDN documentation lists for each property whether or not they can be skinned.
Another way to find out if you can skin a certain property is by simply trying it: just set the property
in the skin and if you’re not allowed to set it, you’ll get an error at run time.
Generally speaking, properties that influence the appearance (BackColor, ForeColor, BorderColor,
and so on) can be skinned and properties that influence behavior (Enabled, EnableViewState, and
more) cannot be set.
When you create a new skin file using the Add New Item dialog box, you get a bunch of text
wrapped in a server-side comment block. You can safely remove these comments because they only
give you a short example of how skins work. You can define multiple controls in a single skin file.
However, from a maintainability point of view, it’s often easier to name each skin file after the control
it represents. For example, you would have a file called Button.skin for buttons, Label.skin
for labels, and so on.