Handling view output [#865470]

Both an “article” and a “section” element will create a new sub-outline in an HTML5 document. One of the key differences between a ‘section’ and an ‘article’ is that a ‘section’ is generally used to group related content together, while an ‘article’ element wraps around a piece of content that “makes sense on it’s own” – Like a news article.
It may be a good idea to differentiate wrappers when using either the’ field’ or ‘node’ style in a ‘view’. Generally, a list of ‘nodes’ would benefit more from a bunch of ‘article’ elements being wrapped around a ‘section’ element. Where in the instance of a ‘field’ view it can be hard to determine the utility of the view. Sometimes they act like menus, lists or even slide shows in some cases.

Comments

Comment #1

patmacs CreditAttribution: patmacs commented 26 July 2010 at 21:38

Sorry. Typo. *A list of 'nodes' would benefit more from a bunch of 'article' elements sitting INSIDE a 'section' element.

Comment #2

jensimmons CreditAttribution: jensimmons commented 28 July 2010 at 00:43

Comment #3

masagin CreditAttribution: masagin commented 3 August 2010 at 18:22

+1 for ARTICLEs in node listings

Comment #4

migueltrindade CreditAttribution: migueltrindade commented 3 August 2010 at 20:49

+1 for articles

Comment #5

jensimmons CreditAttribution: jensimmons commented 3 August 2010 at 21:55

Are we suggesting this?

View — section • View row — article • View row — article • View row — article • View row — article

I also think that's best.

Mostly, people will need to mark up their particular usecase using Semantic Views. We cannot pick one default to have it work for all cases. We can't. What we can do is pick one default that will be pretty good, the most common one, and provide tools / encourage best practices for people to use to markup their content for their usecase.

How are we proposing to do this? With a view tpl? Is that the best way to go? We want to override the default Views tpls.... but also, more importantly, we want to provide Semantic Views on Steroids or something so people can do what they need to. We don't want to override the output of that.

Comment #6

mason@thecodingdesigner.com CreditAttribution: mason@thecodingdesigner.com commented 3 August 2010 at 21:51

I agree with this.

I think the implementation should be a default views template, plus whatever we can do for semantic views. I think we should be able to add a template to add the SECTION tag for sem views, but the ARTICLE tag will be entered in the sem views UI.

Comment #7

jensimmons CreditAttribution: jensimmons commented 3 August 2010 at 21:54

Plus remember we get HTML Tools :D so anything we want functionality-wise on the module level, let's scheme it up and post it to the HTML Tools issue queue.

Comment #8

Jacine

she/her

New York

CreditAttribution: Jacine commented 3 August 2010 at 22:05

Speaking of HTML Tools... With all this talk about not knowing what the content will be, my first thought is that I will be using Skinr to help with that. The template file functionality is IMO the perfect answer to this problem.

The HTML tools module could provide theme functions/tpls for what the output, and Skinr could be used to apply the settings. For example, the default theme implementation might be ARTICLE, but then the HTML tools could provide theme hooks/tpls and skin definition for the other tags and the use/admin can just pick what they want.

The template functionality needs work in Skinr, and this is a perfect excuse to get on that! I don't think any of this work would be wasted either, because it could all be posed for inclusion in Drupal 8...

Comment #9

jensimmons CreditAttribution: jensimmons commented 4 August 2010 at 01:40

Yes, yes. Skinr is a great place to put stuff not-in-the-theme tpl or css, not-in-the-module....

I like Skinr, and think we should support it. Use it to give people tools to apply HTML5 markup as they like.

I'm apt, however, to say we don't want to *require* skinr. We want this to be a flexible base theme for all kinds of professional projects.... even ones that aren't using Skinr.

Comment #10

ericduran CreditAttribution: ericduran commented 4 August 2010 at 04:12

I like the skinr Idea. We could possibly branch of another html5_tool module in there for skinr support to provide the hoook, tpls, and skins. That way the skinr stuff is there if someone wants it but is not is there not using it. I think skinr is a reasonable excuse to add another module to the html5_tools set.