Eu estou criando um documento de padronização de HTML e CSS aqui na
empresa, ele vai ser usado para orientação dos clientes. Mas as vezes
da um branco no que vou falar na documentação, por isso vim aqui pedir
ajuda a vocês para ver o que mais eu posso falar para que o documento
possa ter mais qualidade.
Eu falei sobre:
1) Modelo de css estrutura
2) Um exemplo de código CSS padronizado:
3) Corte do site ( Tableless ) [Explica e mostra as vantagens de
cortar em tableless]
4) Regras padrões de CSS
5) Compatibilidade com navegadores
6) Indentação do código
O que mais posso falar?
Se quiserem ver o que já fiz, mande um e-mail que te mando o
documento.
mas pra que tipo de cliente vai chegar essa documentação....?? Quem são os clientes da sua empresa ??
Por exemplo pros meus clientes (que são os caras que pedem sites) não sei se teria alguma vantagem em passar essas informações pra eles, pelo menos pra início de trabalho..
Comente sobre SEO. Para fazer o básico, é preciso ter o código semântico,
para que ajude o site do cliente ser bem indexado. Todo cliente fica
contente nessa parte.
> Eu estou criando um documento de padronização de HTML e CSS aqui na
> empresa, ele vai ser usado para orientação dos clientes. Mas as vezes
> da um branco no que vou falar na documentação, por isso vim aqui pedir
> ajuda a vocês para ver o que mais eu posso falar para que o documento
> possa ter mais qualidade.
> Eu falei sobre:
> 1) Modelo de css estrutura
> 2) Um exemplo de código CSS padronizado:
> 3) Corte do site ( Tableless ) [Explica e mostra as vantagens de
> cortar em tableless]
> 4) Regras padrões de CSS
> 5) Compatibilidade com navegadores
> 6) Indentação do código
> O que mais posso falar?
> Se quiserem ver o que já fiz, mande um e-mail que te mando o
> documento.
> Comente sobre SEO. Para fazer o básico, é preciso ter o código semântico,
> para que ajude o site do cliente ser bem indexado. Todo cliente fica
> contente nessa parte.
> 2008/8/18 Roberto Bino <robertobinosilve...@gmail.com>
>> Prezados colegas,
>> Eu estou criando um documento de padronização de HTML e CSS aqui na
>> empresa, ele vai ser usado para orientação dos clientes. Mas as vezes
>> da um branco no que vou falar na documentação, por isso vim aqui pedir
>> ajuda a vocês para ver o que mais eu posso falar para que o documento
>> possa ter mais qualidade.
>> Eu falei sobre:
>> 1) Modelo de css estrutura
>> 2) Um exemplo de código CSS padronizado:
>> 3) Corte do site ( Tableless ) [Explica e mostra as vantagens de
>> cortar em tableless]
>> 4) Regras padrões de CSS
>> 5) Compatibilidade com navegadores
>> 6) Indentação do código
>> O que mais posso falar?
>> Se quiserem ver o que já fiz, mande um e-mail que te mando o
>> documento.
2008/8/18 Roberto Bino <robertobinosilve...@gmail.com>:
> Eu estou criando um documento de padronização de HTML e CSS aqui na > empresa, ele vai ser usado para orientação dos clientes.
Cuma?
E lá o que o cliente quer saber sobre mark up?
> Eu falei sobre: > 1) Modelo de css estrutura > 2) Um exemplo de código CSS padronizado: > 3) Corte do site ( Tableless ) [Explica e mostra as vantagens de > cortar em tableless] > 4) Regras padrões de CSS > 5) Compatibilidade com navegadores > 6) Indentação do código > O que mais posso falar?
Transar com camisinha. Não que tenha algo a ver, mas sempre é bom lembrar.
Você pode trocar estes seis itens num só: W3C. Ponto. Usar como referência a documentação (e validação) do site. Isto inclue tudo, do ultrapassado tableless (ainda ainda usa este termo?) a guias de acessibilidade.
Não há relevância no resto. Claro que as diferenças entre os navegores é, mas você irá se deter em descrever cada item deste infinito problema? KISS e beijos.
Agora, demais mesmo é criar regras para indentar o código. Você irá criar o guideline de acordo com suas preferências, não supostamente para algum método padronizado de indentação.
> Comente sobre SEO. Para fazer o básico, é preciso ter o código semântico, > para que ajude o site do cliente ser bem indexado. Todo cliente fica > contente nessa parte.
Mas se pratica semântica pelo SEO?
O W3C prega a semântica, inventou o HTML, décadas antes que os web crawlers começassem a entender que o <title> era relevante.
Oriente o seu código para SEO, que ele ficará amigável aos web crawlers... Mas não aos seus usuários.
Não que diminui a genialidade da coisa. A questão é que não acharam uma viabilidade prática para o formato. E duvido que esta primeira viabilidade, será comercial.
Se vier a ser, vai ser social.
On Mon, Aug 18, 2008 at 9:00 PM, Perroud <perr...@gmail.com> wrote: > Acho que é por que todos estes derivam do XML.
XML é o monolito preto de "2001". Belo, misterioso, achamos que contém a chave da vida... Mas estamos insistindo em martelá-lo com ossos.
""Você pode trocar estes seis itens num só: W3C. Ponto. Usar como
referência a documentação (e validação) do site. Isto inclue tudo, do
ultrapassado tableless (ainda ainda usa este termo?) a guias de
acessibilidade.""
Irapuam,
w3c tem muita informação, poderia especificar quais páginas da W3C que
vc esta falando?
porque o documento tem que ser claro e direto.
Obrigado pelas palavras
Roberto
On 18 ago, 16:49, "Irapuan Martinez" <irap...@gmail.com> wrote:
> 2008/8/18 Roberto Bino <robertobinosilve...@gmail.com>:
> > Eu estou criando um documento de padronização de HTML e CSS aqui na
> > empresa, ele vai ser usado para orientação dos clientes.
> Cuma?
> E lá o que o cliente quer saber sobre mark up?
> > Eu falei sobre:
> > 1) Modelo de css estrutura
> > 2) Um exemplo de código CSS padronizado:
> > 3) Corte do site ( Tableless ) [Explica e mostra as vantagens de
> > cortar em tableless]
> > 4) Regras padrões de CSS
> > 5) Compatibilidade com navegadores
> > 6) Indentação do código
> > O que mais posso falar?
> Transar com camisinha. Não que tenha algo a ver, mas sempre é bom lembrar.
> Você pode trocar estes seis itens num só: W3C. Ponto. Usar como
> referência a documentação (e validação) do site. Isto inclue tudo, do
> ultrapassado tableless (ainda ainda usa este termo?) a guias de
> acessibilidade.
> Não há relevância no resto. Claro que as diferenças entre os navegores
> é, mas você irá se deter em descrever cada item deste infinito
> problema? KISS e beijos.
> Agora, demais mesmo é criar regras para indentar o código. Você irá
> criar o guideline de acordo com suas preferências, não supostamente
> para algum método padronizado de indentação.
Passou por aqui, algo da natureza do mark up passa a ser compreendido.
O W3C não é propriamente um local para tutoriais. É de onde emanam as padronizações de tecnologias para a web. É referência, mas a linguagem de tutoriais é um tanto distante.
O que um web designer precisa saber? Eu destacaria duas coisas: 1) A natureza do mark up; 2) Rewritebility.
O primeiro versa que o HTML não é uma linguagem visual, mas estrutural. Como ensinar alguém a diferença? Mande-o usar Lynx, browser de texto. O Opera tem um modo de visualização que o emula. Ou simplesmente, mande-o usar browsers que permitam desligar os estilos.
Então a natureza do mark up saltam aos olhos. Acessibilidade e SEO inclusos.
"Reescrevibilidade" (caceta, nunca consegui conjugar este nome, em português ou inglês) é a segunda. É a capacidade de terceiros assumir o código e não achar que aquilo é um criptograma. Como se consegue isto? Simplicidade, essencialmente. Via uma noção que o HTML não é uma coisa autoral, uma rosa dentro duma redoma. Estamos criando para a internet, não para nós mesmos (o que reside 99% dos problemas dos web designers: O ego do próprios).
O que, afinal de contas, os dois itens são a mesma coisa. A natureza do mark up era a possibilidade de terceiros pudessem ter acesso ao source, hackear, adaptar, processar, dar novos usos.
Não criamos sites para nós. Nós estruturamos informações. Quem vai dar uso é o usuário. Por isto o ambiente é essencialmente, social. Por isto Flash é um contrasenso na web. Por isto quando inventamos de controlar que fim darão ao conteúdo, esbarramos sempre na questão da acessibilidade.
> On 8/19/08, Roberto Bino <robertobinosilve...@gmail.com> wrote: > > w3c tem muita informação, poderia especificar quais páginas da W3C que > > vc esta falando? porque o documento tem que ser claro e direto.
> Ótimo então, você pode navegar dentro da miríade de informações dentro > do W3C, apontando para o tom que você quer dar ao documento.
> Passou por aqui, algo da natureza do mark up passa a ser compreendido.
> O W3C não é propriamente um local para tutoriais. É de onde emanam as > padronizações de tecnologias para a web. É referência, mas a linguagem > de tutoriais é um tanto distante.
> O que um web designer precisa saber? Eu destacaria duas coisas: 1) A > natureza do mark up; 2) Rewritebility.
