我们知道制作一个控件，一般比只实现同样功能的模块要复杂，因为我们需要考虑更多的异常和适应性，才能达到我们整合和复用代码的效果。而当我们开发一个ASP.NET控件时，不管我们的控件有多么复杂的功能和UI表现，我们最终在客户端浏览器里得到的都只是HTML代码和脚本的组合。

    而就是这些控件生成的HTML代码，它们的格式是不是就可以随意处理呢。那么不能随意又是什么意思？难道我们必须要保证HTML代码的排版，并保持HTML良好的层次缩进什么的吗？这里刚刚相反，我们因该尽量去掉和控件HTML代码没有关系的任何东西，包括"无用的"空格和回车。为什么要强调无用的呢？我们知道浏览器在处理HTML源代码时，对于其中连续的空格和回车，都是按一个空格来处理并显示的。所以，似乎我们并不用在意ASP.NET控件在Render时，HTML代码前后或中间多出的无用空格或回车。那么我们来看一下下面这个示例： 

    ...

    上面这个代码片断是Dundas Web Controls中的Web Chart控件输出的HTML代码。这个带有hot area的Chart图片在使用时似乎没有什么问题，如果就是普通的单独使用这个Chart，确实是没有问题。可是当我们把Dundas Chart组合到自定义的WebControl中时，它这种带有换行和缩进的HTML代码就带来问题了。由于布局的需要，我需要把这个Chart放入一个表格之中，并让表格显示一个像素的border紧密包围Chart。本来这个Chart的外观就只是一个图片而已，这样的组合似乎应该没有任何问题，可实际情况是那个Chart的图片始终不能撑满外面的表格(如下图)，而在图片底部和表格底边上总是有3-4个像素的间隙。而这个间隙就是由于和

   由于Dundas Web Chart是发布的已经编译好的dll，所以要删除它输出的HTML中无用的空格和回车就变的比较麻烦了。我们只能从它的Render流中把HTML代码取出，然后手动的去掉tags之间的空格和回车，再输出到新控件的输出流中去。这样的方法虽然可以解决一部分问题，可是如果遇到内部控件过于复杂，这时不管在正确性还是效率上就都是额外的负担。

    所以从上面的问题我们看出，当我们制作一个ASP.NET控件时，因该让最后呈现的HTML代码遵循"代码紧凑原则"，以提高控件的适应性。在这样的原则下先前那个示例就应该这样：
...
    这样一来Chart图片就和包围它的表格边框紧密挨在一起了