Asp.net e Web Standards
Este artigo é uma tradução deste artigo “Asp.net & Standards Part II” disponível em: http://www.webstandards.org/2004/10/08/aspnet-standards-part-ii/. Algumas partes foram modificadas, adicionados ou removidas.
O tal do Form
Phil Baines notou que mesmo não havendo necessidade para que toda a página esteja em um <form>, há uma limitação no Asp.net que apenas um <form> na página pode conter Custom Validators.
De acordo com Rick Mason, gerente técnico web da East Essex County, isto se dá pelo maneira encontrada pela Microsoft para manter o ‘estado’ da página durante seus posts. Quando um usuário envia um <form> com um erro, o Asp.net, automagicamente, retorna o <form> para o usuário com a mensagem de erro e também os dados inseridos.
Esta é uma grande vantagem para a usabilidade de um <form>. O que talvez não seja tão interessante é o fato da Microsoft ter adicionado um <input> oculto chamdo _VIEWSTATE. Da maneira que foi implemantada, não é possível adicionar mais de um <form> por página, pois os campos que se deseja manter o estado devem estar inseridos em um único <form>.
Mesmo esta não sendo uma boa característica para a semântica do documento, onde o <form> só deveria estar presente no trecho do (X)HTML onde existem campos de formulário, também não é o fim do mundo.
Validadores Inválidos
Milan Negovan, do Asp.net Resources, um site dedicado ao uso de Asp.net e Web Standards, dá um excelente exemplo dos problemas dos controles prontos do Asp.net quando se tenta criar uma página XHTML, ou mesmo HTML, válida.
Isto fica pior. De acordo com Milan, o Asp.net tem um recurso chamado Renderização Adaptativa. A idéia é que o Asp.net irá automágicamente gerar a marcação de acordo com o user agent que está acessando a página. (Vide exemplo neste post, nele informamos ao .Net como deve se comportar com o agente de validação do W3C). Deixando de lado a estupidez de um código gerado baseado no user agent, ainda há um problema de implementação: Ele considera que qualquer navegador, que não seja o Internet Explorer com Windows, é de baixo nível e então um HTML 3.2 é gerado.
Para ser sincero, o Asp.net começou a ser desenvolvido proximo à virada do século e naquela época o principal concorrente do IE era o Netscape 4.x, que era realmente de baixo nível.
Então, o que fazer? No artigo citado acima, Scott Mitchell do site 4 Guys from Rolla sugere editar alguns arquivos de configuração do Asp.net, em HTML 4.
Resolvido? Não! Depois de escrito o código atualizado, o Asp.net insite em utilizar as coleções proprietárias Microsoft.
Por essa razão, Rick tocou os sentimentos de Nick Vrillo para criação de Custom Controls como solução e note que o HtmlGenericControl pode ajudar muito nisto.
O que o HtmlGenericControl faz é manipular o conteúdo de um elemento via Asp.net. Tudo que é preciso fazer é adicionar um id e o atributo runat=server (Vide este post).
Útil, porém, isto seria muito mais útil se não dependesse do id e pudesse ser usado em mais de um controle por página.
Resumindo
Enquanto o Asp.net é poderoso, de várias maneiras convenientes em seu script server-side, ele também se torna mais difícil para os desenvolvedores preocupados com os padrões web.
Para os iniciantes, A Microsoft integrou a linguagem de marcação (XHTML, HTML…) com a programação utilizando atributos como id e a tag <form>. Isto é bem melhor que a mistura de código e programação como no Asp clássico e muitas vezes no PHP também, mas às vezes isto acaba atrapalhando muitos desenvolvedores aos quais ela devia ajudar.
Fundamentalmente, o Asp.net continua a ver o código de marcação apenas como uma forma de apresentação. Mesmo quando gerando código para navegadores de alto nível, ela substitui <span> por <font> e <div> por <table>. Isto faria sentido a muito tempo atrás, quando ainda não havia preocupação com a semântica do código, mas atualmente há maneiras bem melhores. Mantendo a estrutura do documento separada do seu estilo ajuda muito no tamanho da página em kb’s, flexibilidade e manutenção.
O Asp.net tenta uma alternativa para incompatibilidade entre navegadores através deu ma falha identificação de user agent. Isto pode ser útil em alguns casos, porém, CSS Hack são uma alternativa muito mais sofisticada. Entretanto, o fato é que da maneira como foi feito, acaba por quebrar, a medida que novos navegadores são lançados. E mais, você acaba por aumentar drásticamente a complexidade do seu código para tentar mante-lo compatível com todos navegadores. Uma abordagem muito mais robusta seria gerar o código de acordo com as capacidades e características do navegador. Isto é mais fácil de se fazer no lado cliente que no lado servidor, logicamente. Porém, boas praticas na codificação como no projeto WaSP liderado por Steven Champeon’s progress enhacement pode minimizar esta frustração.