dudas con los h1

[vantivati]

Hola a todos!

Una preguntilla es posible darle a un h1 creado dentro de un nuevo div, otros valores diferentes al resto de los h1 de la página.

Muchas gracias

[kseso?]

Sólo debería tener uno y sólo un <h1> en cada página.

[vantivati]

Entoces, no se puede crear un h1 diferente (al resto de los h1) para una página en concreto

Muchas gracias

[kseso?]

Sí, claro que se puede. Sólo necesita diferenciarlo del resto de h1 de las otras páginas.
O bien asignándole una clase o id a él mismo o al /body/ donde se encuentre y definirlas en su css:

html:
<h1 id="identificador"...
css:
h1#identificador {...

[ArturoGallegos]

yo optaría por asignar una clase al h1 que quiero diferenciar por aquello de que después necesite asignar los mismos atributos a otro h1 u otro elemento.

por otro lado:

Iniciado por kseso?

Sólo debería tener uno y sólo un <h1> en cada página.

compañero kseso? en que se basa para afirmar tal situación?

no veo porque esa limitante, en un html es posible tener tantos h1 como nos sean necesarios. no es obligatorio solo tocar un tema por pagina o si?

[abimaelrc]

Es más bien cuestión de semántica, o estructura del documento. Además te doy a leer estos artículos

Iniciado por http://www.webmasterworld.com/forum3/24174.htm

The h1 tag is [supposed to be] the heading or topic of the entire page. I've seen several mentions on the W3C that having more than one <h1> is considered an error. Although it's not invalid code, strictly speaking, it is a poorly structured document.
The W3C is creating an accessibility checker -- multiple h1 tags are one of the errors that it will flag, along with skipping from <Hn> to <Hn+2>, instead of following <Hn> with <Hn+1>

Iniciado por http://www.webmasterworld.com/forum3/24174.htm

Document structure is what it's all about and it's been around since before the net.

Document structure lends semantic meanin to a doc so that I, you, or a parser (Google?) can see quickly, the main topic discussed and the associated sub-topics (headers h2...h6). It enables us to get a general "feelin" about what we're gonna find, for instance, by skim-readin... which we all do.

The hx tags are like a directory tree, with your C-drive being h1 - If you orgainse your folders logically, you should be able to navigate quite easily by "followin the story" of the directory titles.

A good way to witness the semantic meanin is, if ya have Opera, to use the mobile device function on a properly structured (HTML) doc and compare to one without... you'll quickly see how important, and easy, it is to better feel what the doc is about.

I contend that hx tags do play an important role with G, though more than one will most likely be ignored... similarly, an overly long one too.

Iniciado por http://www.webmasterworld.com/forum3/24174.htm

If you don't use hx tags, but instead use large (now deprecated) <font> tag attributes and/or <strong> tags to achieve the same visual effect, then, as the document isn't semantically structured in the eyes of a computer, a parsing algo - any parsing algo - will miss the importance and relevancy of what's being said - In the hierarchy of the document tree, the font and strong tag are amongst the lower echelons.

Consider also, accessibility: Blind users can't see headers or differences of font. They will rely on text-to-speech apps. They in turn will seek "guidance" from the author as to how to navigate the document lest the user is forced to waste time readin it all through without findin what they want... a parser is "blind" too don't forget, ie... Google etal.

Web-enabled devices are also expanding beyond the PC-based browser - Now the font tag is deprecated, your text will appear unorganised and consequently harder to read should you wish to stylise headers using this method.

By using an h1 tag, I'm tellin the user/parser that this document is all about x - A font tag doesn't have that semantic power - It's just an instruction.

If you use multiple h1 tags within one doc, you, in effect, confuse and distort the true document meaning - You're cuttin short the discussion and starting a new one midflow in essence. In SEO terms, this can only work against you; It's as if you were nicely buildin-up points (relevancy to the topic) and then you reset the counter to zero again... even though it's the same topic.

Headers act as a path to the info we want. Just study your own actions when browsin a newspaper, thumbing through a book, viewing a website or planning a long journey even. We look at it top down (topology), each step gettin more detailed until we "arrive". If your headings are not labelled correctly, or misused, you basically don't arrive or at best, "arrive" the long way.

Those that doubt the wisdom of the (w3c) intentions of this schema seem to object on the basis of (artistic) presentation and webmastery skills. Well, we're talkin about blind algos here. All algo calculations have rules and must first assume that those rules are adhered to (We can build-in error-handling but first we must establish the axiom to base that error-handling on)...

Because headers have a semantic meaning, it's entirely appropriate to look for it, and take the appropriate action based on it's meaning. It's not the job of the algo to teach the webmaster how to write a page. Nor does the algo care for how your doc looks... and what does that matter if your user views your doc through a device that's stripped away superflous tags anyway? (Try the Opera mobile thingy test).

At the end of the day, I don't know with official certainty that G makes a judgement on hx tags. My subjective research (strongly) suggests it does and it makes perfect sense that it should because appropriate headers help define what's being discussed.

If you don't use them, or use them incorrectly, then you run the risk of a myriad of operations, now and in the future, making unintentional decisions based on it. For instance, I have an app that generates a sitemap. It does this by parsing folder names, file names as well as the document title and all headings within the document. It even indents those headers on the sitemap based on the hx values so that what you end up with appears like a directory tree. This is extremely useful both for me and my users.

If you need another argument: There are, as we know, more than 8 billion documents on the web. To index all these appropriately requires huge processing power as it is. Now, based on the principles of document structure and retrieval, do you think a document with no semantic structure requires more, or less processin?

[ArturoGallegos]

Gracias abimaelrc, y claro entiendo muy bien los puntos de estos artículos ya había escuchado algo al respecto... y como dices es mas por semántica que el hecho de que no se pueda.

aunque sinceramente nunca me he topado con alguna mención de esto en la W3C, que nos lleve a considerarlo como un error, lo comento por lo que menciona la primera cita que hiciste.

[kseso?]

Más que por semántica (que también) lo es por sintaxis.
Si es cierto que h1 define el título principal de la página, es un contrasentido y nada funcional la existencia de múltiples y diferentes títulos para un mismo documento.

Y si toca varios temas diferentes por página, siempre habrá un título que la pueda identificar. Si son churras, pues eso, si son merinas, lo mismo, y si mezcla churras con merinas con titularla "ovejas" ya lo resuelve.

No obstante toda info que le facilita Abimaelrc (gracias por evitarme el buscarla), fíjese en el tiempo verbal que utilicé. No fue precisamente un imperativo.

[VTacius]

Lo que te dicen que el objetivo de H1 es ser el titulo de mayor jerarquía en la maqueta de contenido, lo que pasa es que de poner varios todos van a competir por la atención de visitante.

Recuerda caballero que hay otros, tales como h2, que aún puede dar buenos resultados en oposición al texto normal...