Explicações Décimo Segundo Menu - Repente CSS

[William Bruno 1501]

Boa noite galera dos padrões web!!

 

Abri este tópico exclusivamente para discutirmos as soluções apresentadas para o Décimo Segundo Menu.

http://forum.imasters.com.br/topic/354140-repente-css-menus/page__st__80__p__1829686#entry1829686

 

 

Todos os menus são atemporais. Você pode postar a solução de qualquer um deles a qualquer hora.

O que realmente importa, é o desafio de conseguir fazer. Comparar oque você fez, com oque o outro fez. Assim, dessa forma, poder melhorar o seu próprio código.

 

 

Até o momento temos 6 soluções bem interessantes desse menu.

 

 

Apenas o João e eu mesmo, declaramos o font-family em ancestrais como body ou html. Para assim, nos valer da cascata, e criar uma menor dependência do código.

O menu era super simples. Mas ainda assim, todos usaram UL > LI. Estão 'viciados' nessa marcação ?

Para chegar no efeito que apresentei, e para garantir semântica, bastava usar NAV > A. O que acham ?

[JCMais 75]

O menu era super simples. Mas ainda assim, todos usaram UL > LI. Estão 'viciados' nessa marcação ?

Para chegar no efeito que apresentei, e para garantir semântica, bastava usar NAV > A. O que acham ?

 

Discordo.

 

Se você olhar a especificação mais atentamente verá que o elemento NAV também pode conter outros elementos, como elementos de heading (h1, h2, etc), definir os links dentro de uma lista adiciona mais semântica aos mesmos.

 

Mas isso vai do uso de cada um, eu prefiro usar ul > li > a, porque para mim têm uma semântica melhor, e não por eu está "viciado". :thumbsup:

[William Bruno 1501]

o elemento NAV também pode conter outros elementos,

eu conheço a especificação e já sabia disso.

 

 

eu prefiro usar ul > li > a, porque para mim têm uma semântica melhor, e não por eu está "viciado". :thumbsup:

"semântica melhor" ?

É uma navegação. Precisamos de links. Onde está a "semântica melhor"?

 

 

Na minha opinião, usar: NAV > UL > LI > A, neste caso, é desperdício de marcação.

[Mateus Avila Isidoro 8]

nav ul li a, nav>ul>li>a, nav p a, nav a

(why not?) podem servir de links. É possivel fazer o layout acima usando as marcações que eu botei aqui.

 

Mas dentro de nav entupir de texto, acho desnecessário.

 

nav id="main"

 

e

 

nav id="secondary_nav"

 

são igualmente válidas. O problema é que tendemos a usar apenas um nav para a navegação mais importante da página.

[angelorubin 142]

Bom dia,

 

Até agora nenhum abriu borda arredondada no safari, porque será?

[William Bruno 1501]

qual versão de safari @angelo ?

 

provavelmente você não conseguiu reduzir para 300px de largura o teu browser(alguns SOs e navegadores impedem isso).

 

 

Convém lembrar que o principal motivo de usarmos @media-queries, é tornarmos nossos frontends compatíveis com dispositivos que tenham telas "apertadas", tais como tablets e smartphones.

Por isso, que creio que não seja "requisito" fazer as media queries funcionarem no IE6~7.. estes browsers são de pcs. E hoje em dia, já consideramos mais de 1024 para produzirmos layouts para eles.

 

 

Por exemplo, olha como o meu ficou no iOS Simulator: (x-code)

 

[JCMais 75]

eu conheço a especificação e já sabia disso.

 

 

"semântica melhor" ?

É uma navegação. Precisamos de links. Onde está a "semântica melhor"?

 

Estou declarando explicitamente que ali tem uma lista de links através do UL > LI e que estes links fazem parte da navegação principal através da NAV, para mim isto é semanticamente melhor.

 

Na minha opinião, usar: NAV > UL > LI > A, neste caso, é desperdício de marcação.

Para mim, "desperdício de marcação" não é um argumento válido para deixar de usar UL > LI, para definir uma lista de links que fazem parte da navegação principal do site.

 

Se "desperdício de marcação" fosse um argumento válido, porque os próprios exemplos da especificação, usam UL > LI > A?

[Evandro Oliveira 331]

Safari no Windows XP também rolou suave

 

Eu estava pensando em declarar a fonte fora do A, mas não no BODY|HTML e sim no LI.

Depois mando aqui uma atualização. O text-align está desnecessário, eu ganharia umas 2 linhas. Outra coisa que eu não conhecia era o valor CurrentColor que também me salvaria outras duas linhas.

 

Vou procurar um polyfill decente pro IE. O que eu utilizei dá prioridade pra exibição e matou completamente a usabilidade.