Suggesting a <content> tag

[Donar]

Good morning, community

As I am new to these forums, I am uncertain if this is the right place to bring forward my suggestion. Feel free to move the thread if it's inappropriate here.

I feel, that today a page's semantical content still is not separated well enough from the elements serving more administrative purposes. Granted, tags like <menu> etc. can be of considerable value, but due to web designers' creativity it is not too likely, that all semantical components will be distinguishable by machines anytime soon.

This is especially a concern for UAs which attempt to separate "real content" from "overhead" (sidebars, navigation menus, site statistics, copyright notices, validation labels - just to mention a few). Such UAs include search engines of any kind, but are not restricted to those.

Now, aforementioned overhead may and can be found spread overall a particular page, basically restricted only by the web designer's imagination, more often than not interwoven with the page's "real content". Furthermore, such overhead increasingly is generated dynamical, giving a visiting UA the impression that the content changed when it in fact did not.

I feel, that "real content" should be stated. To distinguish real content from overhead, I therefore propose a block tag <content>, to be placed around the true semantical content of a page.

A page containing such tags shall be analyzed accordingly by UAs interested in it, i.e., everything outside the tag pair shall be disregarded. If no such tags are present, or if the UA is not interested in the semantical part, the UA simply shall behave as usual.

A more detailed outline of the proposal can be found on http://herbert.gandraxa.com/herbert/hct.asp.

Well, that's it for now. I am interested in your opinions and look forward to your comments.

Regards,
//Herbert

[zcorpan]

Very good proposal, although I think the use-case is already catered for with the article element (which essentially is the "content" element, if I understand your proposal correctly), and e.g. the nav, aside and footer elements can mark up things that SEs potentially could consider less relevant parts of the page. If those elements don't cover your use-case, then could you please elaborate what the use-case is more specifically?

Cheers,

[Cerbera]

I don't think using comments is a good short-term workaround:

Code: Select all

      <!-- content -->
         A part dealing with the page's topic
      <!-- /content -->

Authors already tend to identify the "real content" of their page via the use of class names, presumably like this:

Code: Select all

      <div class="content">
         A part dealing with the page's topic
      </div>

I often see this:

Code: Select all

      <div id="content">
         A part dealing with the page's topic
      </div>

So I think identifying multiple blocks with class="content" or just a single block with id="content" puts you more in line with the web as it currently stands.

[bfrohs]

I believe this would solve a lot of problems, mainly with mobile devices and search engines. Mobile devices (cell phones, PDAs, etc) would then be able to separate the menu, body, and footer into different areas. I believe this was the intention of W3C when they proposed the <nl>. Also, search engines would greatly benefit from this. For example, search engines gather a list of words from your site. If you have Google Sitemaps, you can check out the list of keywords they have for your site. I looked at my list and every single one of my navigation links (home, portfolio, about me, etc) is shown as a keyword for the simple fact that they are present on every page. With the addition of <menu> (or <nl>), <content>, <footer>, search engines would be able to distinguish between the content of the page and header/footer, ergo improving search capabilities. This could be easily be abused though, but no worse than is currently done by website owners.

[Cerbera]

As zcorpan mentioned, the HTML5 article element generally does what a <content> element would.

The HTML5 <nav> element is generally what the XHTML2 <nl> element is for but without the inconvenient requirement for a <label>.

[mskinner]

I always assumed that <article/> was best suited for things like blog/forum posts or articles on a news web site.

Otherwise, I would probably use the <section/> element (instead of the suggested <content/> element):
http://www.whatwg.org/specs/web-apps/current-work/#the-section
which is "a generic document or application section. A section, in this context, is a thematic grouping of content, typically with a header, possibly with a footer."

[cabbageking]

There is some very useful recent research on web patterns that might give ideas for common elements that web designers/developers are including in the .pdf of the powerpoint presentation given at this year's IA summit:

http://www.iasummit.org/proceedings/200 ... atterns_in

While listing common id & class values (see below), John Allsopp urges us to look to the larger patterns (role & type). For instance role = navigation, container, visual identity/branding, user interaction. And the navigation role might be played by multiple types: topnav, leftnav, globalnav, etc.

I'm not sure exactly how this could be implemented in HTML5, but am sure more brilliant minds than mine can figure it out.

Common id values were:
‣ footer
‣ header
‣ content
‣ logo
‣ search
‣ main
‣ banner
‣ container
‣ Top
‣ sidebar
‣ nav
‣ left
‣ right
‣ menu
‣ Copyright
‣ page
‣ topmenu
‣ toptabs
‣ links
‣ breadcrumbs
‣ title
‣ navigation

Common class values were:
‣ navigation
‣ title
‣ help
‣ footer
‣ content
‣ section
‣ menu
‣ text
‣ nav
‣ main
‣ header
‣ copyright
‣ hdr
‣ headline
‣ search
‣ links
‣ topmenu
‣ left
‣ right
‣ center
‣ logo
‣ bodytext
‣ leftnav
‣ topnav

[Pacoup]

This is the most brilliant idea I have heard of.
Here is how I interpret it:
- The content element has the purpose of defining the content of the page. It does not seperate different content as does section and article. Instead, it encloses whatever is considered as content for UAs to read. <content> could thus be used to identify content that is not linear in a page, in example, intertwiced with design elements of the site. The <content> tag as I understand it could be used multiple times in a page.

Why the section element is not adequate
Section defines a section. Let's take a non linear design for this approach, in which a single article's text may be scaterred in between design elements.

Because the design elements are not content, they must not be put in the section element. This situation would thus require multiple section elements for the same article, which would result in a wrong semantical representation of the text.

The section element is thus inadequate for this purpose.

Why the article element is not adequate
Again, article elements define seperate sections, or articles, not a whole.

The article element is inadequate for this purpose.

However
Search engines can already scan <p> tags and other content-level tags to distinguish content from design. The content tag is not useful at this point and article, with section, header, footer, etc., serves all the purpose needed to seperate different parts of content on the page.

Proposal
In which case non linear text may be present, neither section or article can do anything to help it. If it doesn't already exist, I propose an attribute that defines which article ID an article element may belong too.

Example:

Code: Select all

<article content="1">The first part of the article</article>
<!-- some design elements -->
<article content="1">The continuation of the article 1</article>
<article content="second">The second article</article>
<!-- note that the content attribute can contain anything, as long as both linked articles have a matching content attribute. -->