homepage Welcome to WebmasterWorld Guest from 54.237.78.165
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Pubcon Platinum Sponsor 2014
Home / Forums Index / Google / Google SEO News and Discussion
Forum Library, Charter, Moderators: Robert Charlton & aakk9999 & brotherhood of lan & goodroi

Google SEO News and Discussion Forum

This 59 message thread spans 2 pages: < < 59 ( 1 [2]     
Trick to Google Ranks - Using Semantic Best Practices
goodroi

WebmasterWorld Administrator goodroi us a WebmasterWorld Top Contributor of All Time 10+ Year Member Top Contributors Of The Month



 
Msg#: 4631473 posted 2:05 pm on Dec 17, 2013 (gmt 0)

If you don't have the time to learn or follow the best practices for semantic searching, you might want to rethink your priorities.

It is not glamorous to talk about things like schema markup & HTML 5 but these boring and annoying newer issues are what can give your site the winning edge.

Some of you are probably thinking that using schema or HTML 5 simply makes it easier for the all-evil Google to steal your content. I'll be honest you do have a valid concern but if you ignore it, it will not go away. Your competition will do it and Google will get the content from them and give them the traffic. You need to figure out a new strategy for your site to deal with the current situation so you can incorporate these best practices and still profit. Maybe something like putting the best content behind a paid wall? Get creative!

Holding on to old techniques and technology is not a smart idea. It is like insisting on only selling printed newspapers and ignoring the fact that the world has changed and now people like to get their news online. Change is not fun but staying up to date on best practices is vital to success.

How do you use semantics? or How do you suggest others use it?

 

graeme_p

WebmasterWorld Senior Member 5+ Year Member



 
Msg#: 4631473 posted 8:46 am on Dec 22, 2013 (gmt 0)

I just mentioned some of this on another thread, but its worth repeating here.

Semantic HTML is quite complex, and often not very intuitive. For example the W3C HTML5 spec for article sales:

This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content.


<section> is complex as the thread linked above makes clear, and correctly using H1 to H6 should have the same effect in a most cases: [developer.mozilla.org ]

I can see that <main>, <nav> and maybe <header> and <footer> are useful, but the <article>, <section> and <aside> seem to add complexity for little gain, and seem to be quite ambiguous.

schema.org seems better. It allows clear indications of different types of content such as articles and comments - and products and places. It looks more complex, but at least some of it is know to be supported by search engines right now, and it is very clear and well documented.

JD_Toims

WebmasterWorld Senior Member Top Contributors Of The Month



 
Msg#: 4631473 posted 10:12 am on Dec 22, 2013 (gmt 0)

Semantic HTML is quite complex, and often not very intuitive. ... correctly using H1 to H6 should have the same effect in a most cases... <section> and <aside> seem to add complexity for little gain, and seem to be quite ambiguous.

They're actually very easy to use once you get used to them, and how many people do you think know they have to put the same or higher level hN to stop "sub-sectioning" a preceding section?

<h1>
<h2>
<h2>
<h3>
<footer>

Does *not* say: "H1 is the most important heading on the page. The two H2's are the second most important. H3 is the 4th most important. Footer relates to the page," in a document outline.

It says: "H1 is the main topic > H1 has two subsections starting at the H2's >> The second H2 has a subsection starting at the H3 >>> H3 has a footer."

Assuming no sections, in outline form it would look like:

> H1 [relates to <body>]
>> H2 [relates to H1]
>> H2 [relates to H1]
>>> H3 [relates to the 2nd H2, not the H1 or 1st H2]
>>> Footer [relates to H3]


To be able to use hN as an "importance indication", <section> must be used, because then it can be coded like this:

<h1>
<section><h2></section>
<section><h2></section>
<section><h3></section>
<footer>

Assuming no other explicit sections, in outline form it would look like:

> H1 [relates to <body>]
>> H2 [relates to H1]
>> H2 [relates to H1]
>> H3 [relates to H1]
> Footer [relates to the H1's section: <body>]


An alternative to using <section>s and having the same outline as above isn't even possible, because not only does someone have to use 3 H2's, there's no way to "close" the 3rd sub-section of the H1 started by the 3rd H2 and get back to "the same level" as the initial H1 without using an H1, so the footer would be associated with the 3rd H2 -- To get close, it would have to be done something like this:

<h1>
<h2>
<h2>
<h2>
<h1>Footer</h1>
<footer>

Assuming no sections, in outline form it would look like:

> H1 [relates to <body>]
>> H2 [relates to H1]
>> H2 [relates to H1]
>> H2 [relates to H1]
> H1 [relates to <body>]
> Footer [relates to the 2nd H1]




If one or more of the above <section>s is an article [basically: the topic is completely contained within], then it's called an <article> rather than <section>.

If one or more of the above <section>s is "a tangent to the main topic" rather than part of the main topic [eg: you might also be interested in blah], then it's called an <aside> rather than a <section> or <article>.

What's more confusing or less intuitive about explicit sections and what they're called than the examples above not using sections?

graeme_p

WebmasterWorld Senior Member 5+ Year Member



 
Msg#: 4631473 posted 11:41 am on Dec 22, 2013 (gmt 0)

The extra complexity comes from the extra markup, and the fact that you have both headings and sections conveying much the same information, and the potential inconsistency between the outline and default visual appearance.

For example, consider:


<section>
<h1>Widgets</h1>
<p>....</p>
<section>
<h1>Red Widgets</h1>
</section>
</section>
<section>
<h1>Gadgets</h1>


The outline is:

1. Widgets
1.1 Red Widgets
2. Gadgets

but the visual appearance will show headings with the same appearance unless you add CSS to make
section h1 different from section section h1

If one or more of the above <section>s is an article [basically: the topic is completely contained within], then it's called an <article> rather than <section>.


Is a topic completely contained in a comment? Or a forum post? They often do not make sense without the article or thread. They are, nonetheless, supposed to be marked up as articles.

The schema.org markup, which allows you to mark the main article as an article and comments as comments seems preferable to me.

As far as I can see you do not need section for your example. You can do:


<main>
H1
H2
H2
H2
</main>
<footer>
H1
</footer>


I also find <aside> rather confusing. The spec says:


The element can be used for typographical effects like pull quotes or sidebars, for advertising, for groups of nav elements, and for other content that is considered separate from the main content of the page.


Quotes, sidebars, and advertising have very different relationships to the rest of the page. Again, schema.org has specific markup for ads and sidebars, and we already have
blockquote.

Also, how do you integrate <section>, <article>, <aside> etc. into a CMS? Every user needs to understand semantic markup? No chance. On the other hand headings and sub-headings are very familiar.

You could use <aside> if you have a CMS with separate boxes in which to enter main and sidebar content for each page, but that is going to be rare for a long time.

At the template level, you will probably wrap the page heading and content in <main> and use <nav>, <header> and <footer> for the rest.

JD_Toims

WebmasterWorld Senior Member Top Contributors Of The Month



 
Msg#: 4631473 posted 11:45 am on Dec 22, 2013 (gmt 0)

The schema.org markup, which allows you to mark the main article as an article and comments as comments seems preferable to me.

Schema.org, microformatting, rDFA, etc. *do not* impact the document outline.

If someone thinks it's a waste of time to create an accurate document outline that's easily and accurately interpreted by an outlining algorithm and then add "granularity" to the content within that outline via microdata, then that's fine and their prerogative, but I'd call it "a bit on the lazy side" personally and I also don't have too much question why search engines "get it wrong" sometimes.



I don't find the definition of an aside nearly as confusing as you make it sound when I read the first paragraph that leads into the one you cited:

The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography.



I don't find the definition of article very confusing either:

[Emphasis Added]
The article element represents a complete, or self-contained, composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content.

The first sentence explains it. The second is examples of where it might apply. I think one key to understanding is where it says: "in principle" relating to independently distributable or reusable.

It doesn't say, "Must be able to be reused independently from the surrounding content and still make sense to anyone who reads or uses it," it says, "In principle". -- It's really simple, imo.

graeme_p

WebmasterWorld Senior Member 5+ Year Member



 
Msg#: 4631473 posted 12:37 pm on Dec 22, 2013 (gmt 0)

Schema.org, microformatting, rDFA, etc. *do not* impact the document outline.


Yes, but using a few of the semantic tags (header, footer and main) together with correct use of headings will provide the correct outline for the vast majority of content - and users can understand it.

Most tools that generate outlines tie outlines to heading levels. The use case for setting the separately is very limited, and out-weighted by the increased scope for error.

The outline does not affect how the content is displayed in browsers, and the information it ads is of limited use to search engines compared to the more specific schema.org markup. Why does the outline matter? Is there confirmation that search engines use it, and that it significantly changes there analysis of a page that uses otherwise clear markup?

I don't find the definition of an aside nearly as confusing as you make it sound when I read the first paragraph that leads into the one you cited:


How often are quotes tangentially related in the way that ads usually are? Does it mean you have to train users to markup quotes as blockquotes or asides depending on how important they are to the content? The average user typing stuff into a CMS finds it hard to understand the difference between an indented para and a blockquote, let alone between blockquote and an aside.

An entire article may be a response to a quote - that makes quotes very semantically different from ads. How is it useful to use the same markup for both?

If I remember right, reducing markup was a stated aim of semantic HTML. sections and different types of asides are going to add markup (unless you want ads and quotes to look the same!).

The problem with being reused independently "in principle" is that it means that the markup does not tell you whether a particular piece of content in an <article> tag is independently reusable. What is the point of that?

JD_Toims

WebmasterWorld Senior Member Top Contributors Of The Month



 
Msg#: 4631473 posted 1:00 pm on Dec 22, 2013 (gmt 0)

...The outline is:

1. Widgets
1.1 Red Widgets
2. Gadgets

but the visual appearance will show headings with the same appearance unless you add CSS to make section h1 different from section section h1

Only if you completely ignore the fact you don't have to use H1 for every section for any reason.

How often are quotes tangentially related in the way that ads usually are?

The preceding question and many of the other "points you've made" [eg the above quote + can't use <aside>, <section>, <article>, because they're too confusing for CMS users, but schema.org OTOH, we can use that -- WTF?!] and questions you've asked indicate you're just arguing and you haven't even really paid attention to what the docs say, so:

Does it mean you have to train users to markup quotes as blockquotes or asides depending on how important they are to the content?

No, just call everything a div and teach your CMS users to use schema.org markup -- Much easier.

graeme_p

WebmasterWorld Senior Member 5+ Year Member



 
Msg#: 4631473 posted 1:32 pm on Dec 22, 2013 (gmt 0)

You are missing my points.

No, I did not say you have to use H1, but that you CAN, making it very easy to make mistakes. More importantly, if you want the outline to match visual appearance you have to be careful to use h1 for the outermost section, h2 to head sections inside that, h3 for the next layer down etc.

Where did I say that CMS users can use schema.org markup? Both types of semantic markup can be used in templates, where schema.org can do more - except for fine tuning of outlines which is of doubtful utility and error prone.

You're right, just call everything a div and teach your CMS users to use schema.org markup -- Much easier.


Again, I did not way that. If you read what I said I say I can see that nav, main, header and footer are useful. What I am not convinced of is that fine tuning of the outline of the main content is useful for the vast majority of sites, because it does not add much.


H1
H2
H2
H2


gives you the same outline as:


<section>
H1
<section>
H2
</section>
<section>
H2
</section>
<section>
H2
</section>
</section>


[developer.mozilla.org ]

So why bother with the latter?

JD_Toims

WebmasterWorld Senior Member Top Contributors Of The Month



 
Msg#: 4631473 posted 1:39 pm on Dec 22, 2013 (gmt 0)

So why bother with the latter?

I answered that 3 posts ago.

Seven or so years ago when I started using those little rel=prev and rel=next links on a paginated directory no one thought they would make a difference either -- I'm sure they just included the different elements that influence a document outline in HTML5 for fun.

JD_Toims

WebmasterWorld Senior Member Top Contributors Of The Month



 
Msg#: 4631473 posted 2:27 pm on Dec 22, 2013 (gmt 0)

Sorry if I sound harsh, but I'm a bit grouchy about arguing whether document structure and the tools [markup] we've been given to use to communicate about it matter or not -- That said, I'll give you the answer to one of your questions to [hopefully] highlight the difference between schema.org and HTML markup and [hopefully] end the discussion of one replacing the other.



First: whether two asides and are tangentially related the same way or not makes no difference at all in the answer to "why" use an aside.



Does it mean you have to train users to markup quotes as blockquotes or asides depending on how important they are to the content?

No, it means you should really read the docs -- They don't say "quote", they say "pull quote". There's a difference.

The average user typing stuff into a CMS finds it hard to understand the difference between an indented para and a blockquote, let alone between blockquote and an aside.

So, you're saying the average user can't "get" if the quote came from another source it's a <blockquote>, but if it's a "pull quote" [quote from within the article] it's an <aside>? I find that very difficult to believe.



[Emphasis Added]
The blockquote element represents content that is quoted from another source, optionally with a citation which must be within a footer or cite element, and optionally with in-line changes such as annotations and abbreviations.

http://www.w3.org/html/wg/drafts/html/master/grouping-content.html#the-blockquote-element

[Emphasis Added]
The [aside] element can be used for typographical effects like pull quotes or sidebars, for advertising, for groups of nav elements, and for other content that is considered separate from the main content of the page.



The following example shows how an aside is used to mark up a pull quote in a longer article.

...

<p>He later joined a large company, continuing on the same work.
<q>I love my job. People ask me what I do for fun when I'm not at
work. But I'm paid to do my hobby, so I never know what to
answer. Some people wonder what they would do if they didn't have to
work... but I know what I would do, because I was unemployed for a
year, and I filled that time doing exactly what I do now.</q></p>

<aside>
<q> People ask me what I do for fun when I'm not at work. But I'm
paid to do my hobby, so I never know what to answer. </q>
</aside>

<p>Of course his work or should that be hobby?
isn't his only passion. He also enjoys other pleasures.</p>

http://www.w3.org/html/wg/drafts/html/master/sections.html#the-aside-element



Why an aside? So a screen reader, bot, etc. doesn't "flow" the quote into the section of content twice [once in the paragraph it's in and once where it's highlighted as a "pull quote"] like it would if it wasn't marked up correctly in the HTML. The structure indicates "move the content to the side" so the section's content reads/flows like it should.

EditorialGuy

WebmasterWorld Senior Member Top Contributors Of The Month



 
Msg#: 4631473 posted 4:27 pm on Dec 22, 2013 (gmt 0)

Why an aside? So a screen reader, bot, etc. doesn't "flow" the quote into the section of content twice [once in the paragraph it's in and once where it's highlighted as a "pull quote"] like it would if it wasn't marked up correctly in the HTML. The structure indicates "move the content to the side" so the section's content reads/flows like it should.


Aha! [Light bulb goes on in brain.] That's the kind of insight that makes Webmaster World worth visiting.

JD_Toims

WebmasterWorld Senior Member Top Contributors Of The Month



 
Msg#: 4631473 posted 2:28 am on Dec 23, 2013 (gmt 0)

That's the kind of insight that makes Webmaster World worth visiting.

Thanks! It's *great* to know someone thinks some of my contributions are on that level.



One of the reasons I keep citing and talking about really reading the docs is there's a bunch of stuff explained in them, but they have to be read thoroughly to "get all the juicy tidbits", and, it has to be understood the examples given often expand on the definitions of use, plus, there are not "hard and fast rules" on some things as highlighted by the example below.



One of the "juicy tidbits" I think many miss, because it's at the very bottom of the page on sectioning is:

[Emphasis Added]
A section forms part of something else. An article is its own thing. But how does one know which is which? Mostly the real answer is "it depends on author intent".



Aside and some other "markup options" are the same way, meaning: There's no "set rule", because there are different ways a document should "flow" depending on what the page is presenting and how the author(s) intend it to be interpreted.

Take, for example, a page about Metal Widgets on a site, assuming there are also Wood Widgets and Plastic Widgets.

<h1>Metal Widgets</h1>
<p>Info about metal widgets</p>
<p>How/Where to Buy Metal Widgets Here</p>

<section>
<h2>Metal Widgets Compared to Wood Widgets</h2>
<p>Info about wood widgets compared to metal widgets</p>
<aside><p>How/Where to Buy Wood Widgets Here</p></aside>
</section>

<section>
<h2>Metal Widgets Compared to Plastic Widgets</h2>
<p>Info about plastic widgets compared to metal widgets</p>
<aside><p>How/Where to Buy Plastic Widgets Here</p></aside>
</section>



Why would I markup the How/Where to Buy <p>'s as an aside in the second two sections, but not under the H1?

People are viewing a page about Metal Widgets, not Wood Widgets or Plastic Widgets. To provide "encompassing" information about Metal Widgets, How/Where to Buy [advertisement] should be included as part of the "content flow" or "main topic" relating to Metal Widgets.

IOW: How/Where to Buy Metal Widgets is information directly relating to Metal Widgets, so it's "part of the content flow" wrt Metal Widgets, meaning it's *not* an aside.

The page is *not* directly about Wood or Plastic Widgets, so while the comparison of Wood/Plastic Widgets to Metal Widgets is directly related to the topic of the page [Metal Widgets], the How/Where to buy Wood/Plastic Widgets info is only indirectly [tangentially] related to Metal Widgets, because the How/Where to buy Wood/Plastic Widgets [advertisement] is about "different Widgets", not "information directly about" Metal Widgets.

The preceding means for the example [above -- not necessarily in all cases] Metal Widgets page: the "buying info" [advertisement] for Metal Widgets is part of the "main content", but the "buying info" [advertisement] for Wood/Plastic Widgets is an <aside> to the "main topic" or "content flow".



Should an Ad go in an aside?
The right answer is: It depends.

graeme_p

WebmasterWorld Senior Member 5+ Year Member



 
Msg#: 4631473 posted 5:32 am on Dec 23, 2013 (gmt 0)

OK, I see that aside is useful for a pull quote. My mistake there. Yes, I agree about prev/next as well.

My problem is mainly with <section> and <article> requiring you to be careful to avoid creating an inconsistency between visual appearance and outline, and increasing the amount of mark-up required (see my example above). Even in your example above the <aside> makes sense, but the <section> tags make no difference to the outline.

"It depends on author intent" seems difficult to implement to me. For example, should WW posts be inside <section> or <article> tags?

There is also a lot of duplication. I noticed you posted on the thread about overlaps between semantic HTML5 and schema.org. I just posted an example there of what you can end up with if you use schema.org, semantic HTML5 and ARIA (which is incorporated into HTML5):

<nav itemscope itemtype="http://schema.org/SiteNavigationElement" role="navigation">

That does not seem right - but if we do not do that, which do we use?

Zivush



 
Msg#: 4631473 posted 5:36 am on Dec 23, 2013 (gmt 0)

@ JD_Toims/graeme_p
Thanks for your inputs. I am in the learning stage.
Two questions -
1. Are you styling your HTML5 elements or you just add HTML5 tags to the page while styling with divs?
I am asking because if you style HTML5 and an old browser (such as IE7, IE8 and even IE9] ignores an element it might probably drop its styling altogether.

2. From your description, I get that an ad can be part, or completely outside, of the entire page's HTML5 elements based on its relevancy. Am I correct?
Is it OK to make something like this:
<article>
.
.
</article>
advertisement
<article>
.
.
</article>
The ad breaks the content flow..

graeme_p

WebmasterWorld Senior Member 5+ Year Member



 
Msg#: 4631473 posted 6:20 am on Dec 23, 2013 (gmt 0)

There are scripts that add semantic HTML5 (NOT full HTML5, just makes a few elements show) support to older versions of IE. That is probably the best solution for now.

An ad should be an <aside>. The full works (with schema.org and ARIA) will be:

<aside role="complementary" itemscope itemtype="http://schema.org/WPAdBlock">

Assuming you need to use all three, which I am far from clear about. For SEO you probably want schema.org (which the search engines invented), for accessibility you want ARIA, semantic HTML5 should cover both so you probably do not need all three.

What I am confused about is who supports what at the moment. Google uses schema.org information (and other search engines probably do). I think most screen readers use ARIA. I have no idea how well supported it is, but given the momentum behind it, anyone not supporting it probably soon will be.

Zivush



 
Msg#: 4631473 posted 7:00 am on Dec 23, 2013 (gmt 0)

OK, I got you @graeme_p

What about related posts and comments? Is this the correct structure? ->
<main>
<header>
<nav role="navigation">
</nav>
</header>
<article>
<header>
<h1>...</h1>
</header>
.
.
<aside>
Related Post
</aside>
<section role="complimentary">
comments go here
</section>
</article>
</main>
OR
<main>
<header>
<nav role="navigation">
</nav>
</header>
<article>
<header>
<h1>...</h1>
</header>
.
.
<aside>
Related Post
</aside>
</article>
<section role="complimentary">
comments go here
</section>
</main>

JD_Toims

WebmasterWorld Senior Member Top Contributors Of The Month



 
Msg#: 4631473 posted 12:33 pm on Dec 23, 2013 (gmt 0)

Even in your example above the <aside> makes sense, but the <section> tags make no difference to the outline.

From the page cited previously:

[Emphasis Added]
Sections may contain headings of any rank, and authors are strongly encouraged to use headings of the appropriate rank for the section's nesting level.

Authors are also encouraged to explicitly wrap sections in elements of sectioning content, instead of relying on the implicit sections generated by having multiple headings in one element of sectioning content.



1. Are you styling your HTML5 elements or you just add HTML5 tags to the page while styling with divs?

It depends on the situation -- When I "build from scratch" I almost always "turn default styling off" with something like:

body,section,article,aside,header,footer,form,img,div,p,ul,ol,li,dl,dd,dt {margin:0;padding:0;border:0;outline:0;font-style:normal;}

Then set the styles as needed for presentation.

-- By "ignore" I meant there's no "default style/presentation" applied by browsers: EG If the <b> in the text of a page was ignored the text would *not* appear bold, unless othewise styled as bold.

A simple example is:

<p>This is an example of <widget>browsers</widget> ignoring markup they don't understand.</p>

-- Copy and paste the preceding to a page and see if you can tell I marked up the word browser as a widget in the HTML.



"It depends on author intent" seems difficult to implement to me.

It's subjective, and no one said "it's simple to implement" afaik, but neither are ARIA or schema.org or microformats or...

If you're looking for "the easy days of old" where throwing some text on a page, stuffing the keyword meta tag, then getting a bulk of links with what you wanted to rank for as the text, is the answer, then you're looking in the wrong place -- Things are difficult right now and the difficulty level is only going to continue to increase moving forward, imo.



For example, should WW posts be inside <section> or <article> tags?

From the same page of the docs I've cited previously:

A comment on an article is not part of the article on which it is commenting, therefore it is its own article.

We're commenting/replying to a post, which is a "stand-alone" and could be redistributed on a number of forums or sites, in principle, so the initial post is an article, and the replies are "individual articles".

I think you're thinking "article" as in "newspaper or reference" rather than "article" as in "individual object", "article of clothing", "item: an object or item, especially one that is part of a group [bing: define article]."



<nav itemscope itemtype="http://schema.org/SiteNavigationElement" role="navigation">

That does not seem right - but if we do not do that, which do we use?

<nav> -- Schema.org and ARIA are to "further define", "redefine", "add granularity to" elements as "other than" or "more than" their default HTML meaning.

For example: an ARIA role of "search" on a form "further defines" what the form is, the same way microdata of <itemscope itemtype="http://schema.org/SiteNavigationElement"> on a <ul> would "further define" the purpose of the list.



Is this the correct structure?

No, read the bottom of the sectioning page of the docs I cited previously. Your question is answered directly there.

graeme_p

WebmasterWorld Senior Member 5+ Year Member



 
Msg#: 4631473 posted 7:39 am on Dec 24, 2013 (gmt 0)

Authors are also encouraged to explicitly wrap sections in elements of sectioning content, instead of relying on the implicit sections generated by having multiple headings in one element of sectioning content.


Why? Does it change how search engines or user agents treat it?

If you're looking for "the easy days of old" where throwing some text on a page, stuffing the keyword meta tag, then getting a bulk of links with what you wanted to rank for as the text, is the answer, then you're looking in the wrong place


No. I explicitly said I see the point of semantic tags that add information - but added complexity should serve a useful purpose. Adding <section> tags that do not change the outline at all just increases the risk of author error for no gain.

A comment on an article is not part of the article on which it is commenting, therefore it is its own article


Is quoting a section of the standard draft marked "non-normative".

I understand how they are defining <article>. What I am saying is that (apart from being a terrible choice of word) it does not provide enough information - for example that each post is part of a particular thread, or a reply to another post.

Schema.org and ARIA are to "further define", "redefine", "add granularity to" elements as "other than" or "more than" their default HTML meaning.


You make the three sound as if they are coordinated much better than they are. There is a lot of redundancy, and I cannot what will support each. I cannot find any confirmation that if I just use <nav> search engines will use that (all I have been able to find was a comment from Google what they would start interpreting HTML5 when it was sufficiently widely used) and screen reader support for HTML5 is still pretty patchy.

So I am back with using all three. At that point it does not matter what the tag is because search engines will know its a navigation element from the schema.org information, and screen readers can use the ARIA markup. In the short term <nav> does not matter.

Of course there is still an argument for using the <nav> to build for the future.

graeme_p

WebmasterWorld Senior Member 5+ Year Member



 
Msg#: 4631473 posted 7:52 am on Dec 24, 2013 (gmt 0)

Also, regarding the relationship between the three types of semantic markup: sematic HTML5 is attempting to replace ARIA and schema.org. Take a look at this by the man who wrote the specification for the HTML6 <main> tag [w3.org ]

A world where ARIA is not necessary and where accessibility developers would be out of a job because the normal markup that everyone writes already creates accessible Web sites/applications would be much preferable over the current world of band-aids.

Therefore, to me, the primary use case for a <main> element is to achieve exactly this better world and not require specialized markup to tell a user (or a tool) where the main content on a page starts


I agree with the aim, but HTML5 is far from granular enough to go very far towards it, and is still not sufficiently widely supported.

JD_Toims

WebmasterWorld Senior Member Top Contributors Of The Month



 
Msg#: 4631473 posted 9:17 am on Dec 24, 2013 (gmt 0)

You make the three sound as if they are coordinated much better than they are...

No, I just have a better grasp of when to use or not use them, which is apparently lost on some I've been [wasting my time] trying to explain to.

Is quoting a section of the standard draft marked "non-normative".

OMG Not That! We should just throw that info out rather than paying any attention to it, right?

So I am back with using all three.

If you really think all 3 are necessary, use all three.

Also, regarding the relationship between the three types of semantic markup: sematic HTML5 is attempting to replace ARIA and schema.org.

It would be nice, but *obviously* we're not there at this point in time.

Angonasec

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 4631473 posted 11:37 am on Dec 24, 2013 (gmt 0)

SKick:
WARNING: I am seeing new Google SERPS layouts that contain NO traditional results at all, they're pushing the envelope even further and now our content IS their results page. The entire page(below the ads) is just content from various sites with a footer credit link containing only your homepage url as anchor text(no link to the page the content was taken from, no title, no words in anchor text).

Don't be in such a hurry to give Google your content, you'll know why when you see one of these new results pages where the "google knowledge" entirely replaces the search results.


Thank you for the timely warning, we are just on the verge of shutting out G. Despite the traffic they bring it's clear where they're heading.

Zivush



 
Msg#: 4631473 posted 7:06 am on Dec 25, 2013 (gmt 0)

@ JD_Toims / graeme_p
I wonder how you treat excerpts (of blog posts) such as in category pages, or short news as seen in front pages of news online magazines?
How do you tag them? Article elements or section elements?

gouri

WebmasterWorld Senior Member 5+ Year Member



 
Msg#: 4631473 posted 11:24 pm on Dec 25, 2013 (gmt 0)

Zivush write:

1. Are you styling your HTML5 elements or you just add HTML5 tags to the page while styling with divs?
I am asking because if you style HTML5 and an old browser (such as IE7, IE8 and even IE9] ignores an element it might probably drop its styling altogether.


graeme_p write:

There are scripts that add semantic HTML5 (NOT full HTML5, just makes a few elements show) support to older versions of IE. That is probably the best solution for now.


My question: If you can't add the scripts, can you style the elements within the HTML5 element in a stylesheet, so if a browser doesn't support an HTML5 element (e.g., <section> element), the content within the <section> element (e.g., a couple of paragraphs, indicated by the use of <p> tags) is styled the way that you want them to be?

gouri

WebmasterWorld Senior Member 5+ Year Member



 
Msg#: 4631473 posted 2:07 am on Dec 26, 2013 (gmt 0)

I think that I should provide an example for what I wrote in the previous post.

<section>
<p>Text here</p>
<p>Text here</p>
</section>

In the above, in case there is a browser that doesn't recognize the <section> tag, and that is what I styled in a CSS stylesheet, the contents in the paragraphs may not look the way that I want them to? So, instead of styling the <section> tag, should I not style the <section> tag in the stylesheet but style the <p> tag. This way, even if a browser doesn't recognize the <section> tag, the paragraph contents will appear the way that I want them to because the browser will recognize the <p> tag.

rish3



 
Msg#: 4631473 posted 4:28 pm on Dec 26, 2013 (gmt 0)

If Google can display a sentence of your content or even a paragraph and it fully satisfies the consumer causing you to go broke, then your business strategy needs rethinking.


If it were only that simple. For example:

- Hotel and Flight comparison sites created net new information that wasn't available to the general public. At the time, Google's response was to buy ITA and push their comparison to the top. If it were happening today, they could just "knowledge graph" it.
- Review sites acquire and actually use products or services, then spend time to test and document features and quality. Big 'G' is then free to take this work and present the most valuable parts so that the visitor need not be bothered with visiting the website that did the work.


The rub isn't that they are scraping raw data. They are watching patterns of visitor traffic, then finding the sites that bothered the put the right kind of data together to make it actionable and valuable. Then, they are scraping that "value add".

Dymero



 
Msg#: 4631473 posted 4:59 pm on Jan 2, 2014 (gmt 0)

I am skeptical about the addition of some of these elements, particularly in their impact on page speed. There has to be some balance of being semantic and remaining speedy.

As a sidenote: I notice that there is some discussion the <main> tag, which isn't an HTML 5 tag, but something proposed for HTML 6.

JD_Toims

WebmasterWorld Senior Member Top Contributors Of The Month



 
Msg#: 4631473 posted 6:13 pm on Jan 2, 2014 (gmt 0)

...the <main> tag, which isn't an HTML 5 tag...

Huh? http://www.w3.org/html/wg/drafts/html/master/grouping-content.html#the-main-element

Dymero



 
Msg#: 4631473 posted 10:47 pm on Jan 2, 2014 (gmt 0)

Oh, well, HTML 5.1. That being said, HTML 5.0 isn't even fully released yet, so it will be some years before 5.1 is a reality.

graeme_p

WebmasterWorld Senior Member 5+ Year Member



 
Msg#: 4631473 posted 7:58 am on Jan 3, 2014 (gmt 0)

Well main is supported by some browsers (Firefox and Chrome) and may be recognised by search engines, so I can see some point to using it now, provided you do not rely on it.

You can either avoid styling it, or use a Javascript to add the tags, and it will not cause problems with older browsers.

graeme_p

WebmasterWorld Senior Member 5+ Year Member



 
Msg#: 4631473 posted 7:28 am on Jan 4, 2014 (gmt 0)

@JD_Toims, going back to using asides for pull quotes, asides are sectioning, so a pull quote in included in, and changes, the outline? Um...

This 59 message thread spans 2 pages: < < 59 ( 1 [2]
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Google / Google SEO News and Discussion
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved