[html5] <article> for ecommerce product?
Richard Summers
Richard.Summers at bbc.co.uk
Thu Jul 21 02:47:41 PDT 2011
Hi Yukka,
I agree with your assertion that the nesting of <article> tags does not feel
like the best way to deal with user-submitted content (comments in response
to an article).
I feel that a <response>, or <comment> element would provide valuable
distinction between the original article, and the user-submitted responses.
At the BBC, we do not currently display user-submitted comments to News
article's as nested elements of the main Article container, they appear
further down the page structure. I understand this goes against the
principal of semantic nesting, but it isn't so different from un-nested form
<label> and <input> elements. Perhaps an <article name="article_name"> and
<response to="article_name"> relationship could be considered?
In the context of a syndication harvester, we would want to make a solid
distinction between the reporter/journalist created Article, and the
public/user created Comments - as there may be legal issue's around
syndication of public/user created Comments.
Rich
--
Rich Summers
Senior Client Side Developer
Social Publishing Platform
BC4 D6
Future Media & Technology
BBC Broadcast Centre
201 Wood Lane
London W12 7TP
On 20/07/2011 17:49, "Jukka K. Korpela" <jukka.k.korpela at kolumbus.fi> wrote:
> 20.07.2011 15:01, Dominic Morgan wrote:
>
>> This is where I start to have issues with the spec. Are the contents of
>> an <article> tag supposed to make sense out of context or not?
>
> The contents of <article> element is supposed to make sense out of
> context, and this is an essential part of the meaning. At least this my
> understanding of the prose. The <article> element is effectively
> <syndicatable>, but that's too long a word. I guess.
>
>> To me a
>> "user-submitted comment" is not a "self-contained composition".
>
> It usually isn't. This is where things get too wild, perhaps. A blog
> post (by a blogger) is expected to be self-contained, syndicatable. But
> comments might me just "Me too!" or "You got it wrong in paragraph two,
> because...", which surely aren't standalone.
>
> I think <article> elements should be nested only in rare cases, where
> the inner elements are self-contained too. Sometimes a blog comment is
> syndicatable, perhaps more valuable than the original post. But blindly
> marking up all comments as <article>, as the current version suggests
> more or less, goes far too far.
>
>> Outside
>> the context of the original post it often makes little or no sense at
>> all. The clarification about nesting goes some way to addressing this
>> but not far.
>
> Now that you say it, it looks rather evident. The question remains which
> markup should be used for blog comments. By answer is to use <div> at
> present. It is better to be semantically empty than semantically all
> wrong. What would happen if a syndication harvester got zillions of
> "article elements" containing just "Me too!"?
>
> Alternatively, the spec could say that an article element inside an
> article element is not necessarily (or usually, to be honest)
> self-contained and syndicatable. The question then arises: What _is_ it?
>
>> I suspect that
>> the reason blog and news posts are used as examples is that they fit
>> more intuitively with the name of the tag rather than that the scope of
>> the element is limited to them.
>
> Quite possible; a blog post is an "easy" case, too. But examples should
> really help to understand the meaning better, not state the obvious. A
> difficult task indeed; it is more difficult to present good examples (or
> to set a good example) than to present good theories (or rules).
http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
More information about the Help
mailing list