Tag Info

Give HTML5 some time to mature and gain wide acceptance and you might have some specific guidelines for SEO, but I don't think it will differ much from what's currently considered good practice. Either way, I think it's a little too early.
In general, if it's good for your users, it will be good for SEO. Make your site accessible and usable. Use a good ...

To speculate (because I think that's all you can do on this question without rigorous testing in an essentially uncontrollable environment) I personally doubt that there are yet ANY ranking factors associated with HTML5, for the same reason that Google doesn't assign quality points for valid HTML. There aren't enough sites using these structured elements ...

schema.org: Article, BlogPosting
If something is a schema:BlogPosting, it is an schema:Article, too, isn't it? As schema:BlogPosting is a more specific schema:Article:
More specific types
BlogPosting
NewsArticle
ScholarlyArticle
So you have an schema:Article, and now you may decide if one of these more specific types applies to your ...

The main thing I would keep in mind at the moment is that if your pages rely on meta-tags, you will want to test and monitor their acceptance regularly. For instance, for Google Webmaster Tools, if you want to verify ownership via meta-tag, you will have to place it in a "head" element (there are other ways to verify ownership, so generally that's not a ...

Assuming those search results are available to be crawled by search engines as their support for form submissions is very limited at best, repeating that text isn't going to hurt your SEO efforts at all. Text repeated in that manner is perfectly normal and common. I wouldn't change how you are doing or or worry about this at all.

In SEO perspective wrapping contents with <div> tags is not an issue but large amount unwanted coding will increase the bytes of data which may increase the PageSpeed. Here an extract from this source:
Compacting HTML code, including any inline JavaScript and CSS
contained in it, can save many bytes of data and speed up downloading,
parsing, ...

Yes, markup can be spread all over the page. In fact, you can try it out with Google's own Structured Data Markup Helper, which will allow you to highlight items on a page and see suggested marked-up HTML.

At a microscopic level it might make a difference, but I would spend much more time worrying about things like your information architecture, server performance and the quality and quantity or links to your site.

While your checkbox idea is much more efficient, I think you would have to avoid stating it as a question for it to make sense. For instance:
<label for="the_question">I would answer yes to this long winded question.</label>
<input type="checkbox" name="the_question" id="the_question" value="1">
However, if your designers are dead set on ...

I think you'll find Dive Into HTML5, a book in progress, a great resource. Here's a relevant section on when and how to use new semantic elements. For your example, I think that you may be able to omit the <section> tag.

I can't find any recent numbers on HTML usage, but this site has some figures from 2 years ago.
Here's a small-scale poll of web developers (figures will be skewed since it's from a development site) from 2008 as well.
But it's probably best to just choose your HTML version or doctype by looking at browser support. On new projects, you should just use the ...

Microdata (Note) can only be used on HTML elements as defined by HTML5. According to HTML5 (CR), the svg element is not in the HTML namespace. WHATWG’s HTML spec explicitly mentions that Microdata doesn’t work for svg (quoted on 2014-01-02):
Currently, the itemscope, itemprop, and other microdata attributes are only defined for HTML elements. This means ...

They're using microformats, specifically hCard and hCalendar. Along with RDFa and JSON-LD, this is an alternative to microdata.
See Google's Rich Snippet spec for people here, and here's my public LinkedIn page viewed with Google's structured data testing tool, showing a preview Rich Snippet and the extracted structured data.

Possible answer, I will only select my answer as the correct one if up voted 3 times:
http://w3techs.com/technologies/overview/markup_language/all
Also, found these of interest too:
Javascript Libraries
http://w3techs.com/technologies/overview/javascript_library/all
client-side programming
...

I disagree with both of the approaches.
Mostly, if the "long winded question" really does have two answers then "Yes" and "No" are poor choices to offer. The options should be short phrases that state the decision being made.
An example. Instead of this:
Do you want to book conference accomodation now as a part of your ticket?
( ) Yes
( ) No
do ...

If you don't need sections (have small articles) you can just use a bare <article> entity around your content. And when you don't, the section can wrap sub-titles and paragraphs in those sections.
Check out the html5 section specs.
Example:
<header>
<h1>Blog Posts</h1>
</header>
<article>
<header>
...

I has been a while since I've done this, but I believe that Google Doc's export to HTML works better than MS Word and I believe that Google Docs will read Word docs, so you might be able to load the doc into Google Docs and export it that way.

You can always use another application as an intermediary, like LibreOffice, and use it to save it as an HTML document.
LibreOffice (formerly OpenOffice, which is still available if you prefer it) generates much cleaner code comparatively.

You may wish to consider a code snippet collection sharing service such as Smipple, Code Barrel, or CodePad Projects. They're designed for teams to share code/markup; some (e.g. Code Barrel) allow you to tag snippets, which may help your team organise them by UI element.

I don't think I get what you are trying to do. If you want to reference objects inside a page, you can give each object an ID, and form the links so they will point to the ID you you've tagged.
Template page:
<div id="{{{ID|1}}}">{{{object|2}}}</div>
On relevant pages:
{{obj|cool_table|image}}
...some text...[[#cool_table|in figure 4]] ...

In my view and experience, blog post schema should be used for posts on a blog. It contains all the properties you may require on a blog posts (albeit, so does article schema).
The more a search engine utilises information provided via Schema, the more relevant your content becomes if it can be correctly identified (is marked up). I'd associate Articles ...

Yes to both. Or mostly, depending upon a potential inaccuracy in your question.
Textile is just a simplified markup convention. Browsers won't do anything with it; as far as they're concerned it's just text. You'll need a pre-processor of some sort to generate HTML from it. Some text editors support this directly, there are command-line scripts and ...

<meta http-equiv="content-language" content="ll-cc"> what is this
John Conde is correct that it should be included as part of the tag, but there's also the important consideration of ensuring that it's included as part of the HTTP Headers.
Most Meta elements are redundant replacements or over-rides for information that should be sent as part of the ...

The full answer to the question is answered by the W3C here: http://www.w3.org/International/questions/qa-http-and-lang.en
@John Conde is correct that it should be included as part of the <html> tag, but there's also the important consideration of ensuring that it's included as part of the HTTP Headers.
Most Meta elements are redundant replacements ...

Sadly with anything Google there is nothing that is given in approx. time frames. This is because Google allocates resources to your site based on its authority and how busy their bot is. But in experience structured data normally appears between 1-6 weeks after the first index - it can take a few crawls before Google decides to display it within Google ...

As bybe mentioned, it can take a few weeks before your structured data begins to appear, and there have been some bugs in the reporting system lately.
However, I should mention that if you use Google's Data Highlighter Tool to mark up your page, Google's testing tool will not pick it up. That's because the Highlighter Tool does not actually add HTML markup ...

Another problem with a code-heavy site is it takes the search engine spiders longer to crawl your pages. Even if bloated code does not affect page load time (from the visitor's perspective) the longer crawl time can negatively affect how the search engines rate your site. (It's not a major signal but every little bit helps.)
From SearchEngineGuide.com:
...