Premessa: non c'è dubbio che con ASP.NET MVC il markup sia più facilmente controllabile, perchè la cosa è semplicissima, se ci pensate. Con MVC dovete scrivervelo, punto. Non avete tanto da girare intorno, o da prendere per oro colato. Fermo restando che resto un fan di ASP.NET MVC, per le sue caratteristiche e le sue peculiarità, non lo scelgo solo perchè mi fa scrivere tutto il markup a mano. Volendo posso farlo anche con WebForm, con un pizzico di overhead in più, ma se volessi performance assolute dovrei smettere domani di usare un framework, che per definizione è un'astrazione e quindi, come tale, porta overhead.

Comunque, per chi fosse a digiugno di quanto disponibile fino alle 3.5 in fatto di markup generato da ASP.NET (o meglio, dai suoi controlli), consiglio la lettura di questo mio articolo su MSDN.

In pratica, ASP.NET ha un meccanismo, dalla notte dei tempi, per cui il markup generato cambia in base al browser che lo richiede. Si chiama Adaptive Rendering. Se questa feature in teoria è una figata, nella pratica si è mostrata limitata. Tanto per fare un esempio, Chrome ha delle piccole funzionalità che non sono correttamente mappate nelle browser definition (perchè Chrome è uscito dopo il SP 1 della 3.5 e comunque non è "classificato") e quindi l'output prodotto non è perfetto. E' anche per questo che nelle future versioni questo meccanismo è stato reso più facilmente bypassabile.

A partire dalla versione 4.0, comunque, tutti i controlli hanno un meccanismo di opt-out per evitare di inserire tabelle o altri pezzi di markup non voluti. Una maggiore aderenza agli standard web è senza dubbio il filo conduttore della prossima imminente release.

Mentre scrivevo il capitolo 10 del mio prossimo libro "ASP.NET 4.0 in practice" non ho potuto fare a meno di riflettere un po' su questo argomento. Dato che il titolo del capitolo è "Taking control of markup", è ovvio che si parla di adaptive rendering e browser capabilities. Entrambi consentono di adattare il markup alle proprie necessità. Ad esempio, dato che il libro è fatto di esempi pratici, ce ne sono un paio che riguardano l'uso di DataList senza tabelle, con layout fluido, dell'aggiunta degli optgroup a DropDownList, della scrittura di un provider custom per far generare, sempre, output XHTML ai controlli.

In realtà l'output dei controlli è sempre controllabile, probabilmente con un po' di fatica in più, ma con effetti duraturi: fatto l'adapter, registrato, l'effetto è che tutti i controlli di quel tipo ne trarranno beneficio. In certi contesti continuo a preferirlo al dover ripetere il markup localmente. E questo approccio consente di non riscrivere la parte di UI, potendone però migliorare il markup anche in maniera "postuma".

Resto pienamente convinto che probabilmente Repeater (e forse ListView, in certi scenari) dovrebbero essere la scelta di default per l'estrazione dei dati e che pochi altri controlli vadano usati. E, nel mentre, mi domando se non sia che quelli che si lamentano oggi dello scarso controllo dell'output di ASP.NET WebForm non siano in realtà gli stessi che ieri usavano <asp:Image /> perchè il tag <img /> non sapevano che esistesse, o mettevano custom control anche dentro l'insalata, per comodità. Perchè, in realtà, l'output dei controlli si può domare facilmente: basta volerlo. Consiglio di dare un'occhiata ad uno dei pezzi più belli dell'architettura di ASP.NET WebForm, perchè ne vale davvero la pena.