Eu sou uma desenvolvedora de front e back-end e, no edgeofmyseat.com, trabalho principalmente em projetos em que temos que controlar tudo – desde a configuração do servidor, via PHP e banco de dados, até o HTML, o CSS e o JavaScript. No entanto, as vezes nós trabalhamos em projetos onde focamos apenas no desenvolvimento do front end, e então gastamos um tempo árduo construindo cuidadosamente uma marcação semântica e otimizando o JavaScript para descobrir que o back end esta injetando marcações HTML adicionais e colocando estilos inline que substituem o nosso CSS.

Por outro lado, o nosso produto Perch é um pequeno sistema de gerenciamento de conteúdo que visa facilitar para não-desenvolvedores a implementação de um site. Nessa situação, temos que tentar e ficar fora da marcação dos nossos clientes. Ao fazer isso, aprendemos muito sobre como nos manter fora do código de front-end, enquanto ainda possibilitamos uma funcionalidade poderosa.

Não presuma um tipo de HTML

Atualmente, as pessoas estão usando diferentes tipos de linguagens de marcação. Você pode encontrar desenvolvedores front end usando HTML4 (que permite tags abertas, atributos sem aspas, e tags maiúsculas ou minúsculas) XHTML ( que requer um documento bem formatado, atributos com aspas, tags fechadas, e as tags tem que ser minúsculas), e, cada vez mais, HTML5 ( que pode ser escrito no estilo HTML ou XML).

Essa variedade de linguagem de marcação significa que se seu PHP está emitindo qualquer linguagem de marcação, ele pode muito bem invalidar os documentos criados pelos desenvolvedores front-end. Se eles forem bons desenvolvedores, é provável que isso vá irritá-los. Isso também tornará o seu trabalho mais difícil, pois, cada vez que validarem um documento, eles verão os erros para o estilo de marcação incorreto, o que torna difícil ver os erros que eles podem ter introduzido.

Atributos entre aspas são opcionais no HTML4 e HTML5 quando escritos na forma de HTML. No entanto, eles são válidos em HTML4, XHTML e HTML5 (independentemente de como você codá-lo). Então, garantir que você coloque entre aspas quaisquer atributos que tem de produzir (por exemplo, ao exibir elementos de formulário) significará que são válidos para todos os DOCTYPES. Da mesma forma, XHTML e XML exigem que elementos sejam corretamente aninhados e que as tags estejam em letras minúsculas, e enquanto estes não são requisitos para HTML, garantir que as coisas sejam aninhadas corretamente, que as tags estejam em letras minúsculas, e que o documento seja “bem formado” será válido em todos os tipos.

Isso realmente só deixa a difícil questão de elementos de fechamento automático. Elementos que têm uma tag de fechamento separada – por exemplo, parágrafos ou itens de lista – são opcionalmente encerradas em DOCTYPES HTML, mas seu encerramento é válido em todos os tipos. No entanto, os elementos com fechamento automático (por exemplo, imagens <img> e  quebras de linha <br>) são inválidos em HTML se tiverem o fechamento com barra, e inválidos em XHTML sem. Se precisar exibir esses elementos, que incluem elementos de entrada para os formulários, bem como imagens, você deve idealmente permitir que os desenvolvedores de front-end definam sua preferência quanto ao que eles usam.

Em Perch, temos uma série de opções que podem ser definidas pelo designer implementando o CMS. Elas incluem se as tags deveriam ser fechadas e usar HTML5 para que possamos utilizar os novos elementos de formulário HTML5, se for esse o caso. Podemos, então, seguramente exibir os elementos de formulário usando a sintaxe correta do nosso mecanismo de templates.

Exibindo apenas elementos únicos

Mesmo quando se utiliza um mecanismo de templates, há momentos em que você pode ter que exibir algumas linguagens de marcação. Se esse for o caso, uma boa regra a seguir é a de que só se deve exibir um único elemento de cada vez. Isso permite que os desenvolvedores front-end façam um wrap na linguagem de marcação em algum outro elemento, se necessário. Por exemplo, se você está gerando uma lista e precisa dar saída aos elementos li, evite também a saída da lista em si. Encontre uma maneira de permitir que o desenvolvedor front-end decida se essa deve ser uma lista ordenada ou não ordenada.

Evite estilos inline

Tente evitar a tentação de exibir qualquer CSS inline. Devido às regras de cascata, estilos inline têm precedência sobre os configurados no arquivo CSS, portanto, seus estilos substituirão aqueles criados pelo desenvolvedor front-end. Isso irá desagradá-los muito, e também significa que eles precisam entrar em contato com você para obter esses estilos inline alterados caso haja necessidade. Se você precisar adicionar algo para mostrar que um determinado item é diferente dos outros, seria preferível que você adicionasse uma classe ao elemento e dissesse ao desenvolvedor front-end o que é e em que circunstância ela vai aparecer. Dessa forma, o desenvolvedor front-end mantém o controle sobre como o elemento aparece.

Permita que os atributos da classe HTML sejam passados

Se precisar gerar linguagem de marcação, como um elemento de imagem, permita que o desenvolvedor front-end passe uma string que será adicionada ao elemento como um atributo de classe HTML. Isso os ajuda a adicionar o seu CSS necessário sem a necessidade de uma linguagem de marcação adicional em torno do elemento e colocar uma classe sobre isso.

Use sintaxes amigáveis para templates

Muitos web designers e desenvolvedores front-end não estão familiarizados com PHP, por isso, ao implementar qualquer tipo de template que será usado por programadores não-PHP, pode fazer toda a diferença usar uma sintaxe que pareça amigável e familiar para eles.

Fazemos isso em Perch usando tags XML dentro de nossos templates. Para os nossos clientes de design, muitos que nunca instalaram um CMS antes – essas tags e atributos são similares a coisas que eles entendem. Para ver como o uso da sintaxe familiar pode promover o uso de um sistema, você só precisa dar uma olhada para jQuery, que se tornou a biblioteca JavaScript escolhida por muitos designers devido ao seu uso de seletores CSS para atingir elementos no DOM. A sintaxe familiar percorre um longo caminho para ajudar os desenvolvedores de front-end e designers se sentirem confiantes de que podem trabalhar com o back-end sem quebrar nada.

Permita que desenvolvedores front-end controlem sua área de especialização

Bons desenvolvedores front-end estarão tão preocupados com o desempenho do seu código como você está com o back end. Por razões de desempenho, é visto como uma boa prática incluir JavaScript no final da página em vez de na parte superior. Garantir que os desenvolvedores têm o controle sobre esse tipo de coisa significa que eles podem colocá-las lá, se for o caso.

Ao entregar o controle do desenvolvimento front-end para os desenvolvedores front-end, você permite que eles façam seu trabalho com o melhor de sua capacidade, sem interferência de coisas que aparecem na sua linguagem de marcação que eles não estavam esperando. Você também transfere a responsabilidade para essa área do site para eles. Se você gerar um monte de linguagens de marcação via PHP, então toda vez que isso precisar ser mudado, ou se houver um problema com a validação ou quaisquer questões de CSS, o pedido voltará para você.

***

Texto original disponível em http://phpadvent.org/2011/keep-the-front-in-the-front-by-rachel-andrew