Re: [whatwg] Allow empty string for input type=color

[Shaun Moss]

The way things are done is not always the best way. Most colour pickers 
are used in instances where "not selected" would make no sense.


However, as you're designing a widget for the web that may be used by 
billions of people in any number of unforeseen ways, flexibility is a 
virtue, and the option to clear the field would be an improvement. If 
you don't allow a "not selected" or null option, this would basically 
force all colour widgets to be required fields, which may not be what 
the form designer wants.


To compare, some date pickers do not allow you to clear the field, but 
some do. For the web, it's a useful feature.


Shaun


On 2012-05-03 11:46 PM, Anne van Kesteren wrote:

On Thu, 03 May 2012 02:10:11 -0700, Markus Ernst  wrote:
If I understand the spec correctly, entering no value defaults to 
#00, thus the required attribute does not apply. What are the 
reasons for this? I am sure there were good reasons to specify it 
this way, anyway I don't see them right now. "Not selected" is 
actually very different from "black".


"Not selected" is not something typically supported by native color 
pickers.





--
Shaun Moss
+61 405478912
facebook.com/mossy2100
twitter.com/mossy2100
skype: mossy2100
groups.drupal.org: mossy2100

Re: [whatwg] Double meaning of the element

[Shaun Moss]

Sure, I agree - so, deprecate the , ,  and  tags then.



On 2012-05-02 12:39 PM, Ashley Sheridan wrote:

On Wed, 2012-05-02 at 11:31 +1000, Shaun Moss wrote:

I know it's contentious, but as a teacher it's very simple to teach
students of HTML5 that:
  = underline
  = bold
  = italic
  = strikethrough

Of course, I also teach  and, but the simplest way to teach
  and  is that it's merely an easy way to create bold or italic
text when the meaning of  or  doesn't apply. They represent
a convenience that spares the author the work of using span tags and
creating a CSS class with font-weight or font-style properties.  is
the same, just an easy way to create underlined text. It doesn't really
need semantics piled on top of it - that just makes it harder to teach
and learn. But using Chinese names or misspelled text as /examples/ of
when to use  is another matter.

I grok the desire to have all tags defined semantically, but if the
semantic definitions add unnecessary complexity, then it just seems like
a kludge. Anyone can understand  = bold.

Shaun



On 2012-04-30 3:46 PM, Andrés Sanhueza wrote:
>  The   element was made conforming due to widespread usage and for
>  some cases were other elements weren't suitable. However, I feel that
>  the current definition is not very clear, as it gives two somewhat
>  unrelated used for it: misspelled text and proper names on Chinese. I
>  believe that is fine if is one or the other, but by the current
>  definition seems that the purpose of retaining the element is merely
>  were to underline needs to be used to represent something regardless
>  what it is, which seems inconsistent with other similar tags that are
>  better defined to have more finite purposes that aren't based on the
>  fallback presentational look, even if relevant at the time of defining
>  those. By the definitions seems that proper names and book names are
>  suitable to be indicated by   and   respectively; or some new
>  element altogether. I'm aware that the fallback look is an issue, yet
>  I believe it should be resolved in a more consistent way.



I still seems more important to ask why something should be bold or 
italic. Surely getting students into the mindset of describing their 
data is more beneficial?

--
Thanks,
Ash
http://www.ashleysheridan.co.uk




--
Shaun Moss
+61 405478912
facebook.com/mossy2100
twitter.com/mossy2100
skype: mossy2100
groups.drupal.org: mossy2100

Re: [whatwg] Double meaning of the element

[Shaun Moss]

I know it's contentious, but as a teacher it's very simple to teach 
students of HTML5 that:

 = underline
 = bold
 = italic
 = strikethrough

Of course, I also teach  and , but the simplest way to teach 
 and  is that it's merely an easy way to create bold or italic 
text when the meaning of  or  doesn't apply. They represent 
a convenience that spares the author the work of using span tags and 
creating a CSS class with font-weight or font-style properties.  is 
the same, just an easy way to create underlined text. It doesn't really 
need semantics piled on top of it - that just makes it harder to teach 
and learn. But using Chinese names or misspelled text as /examples/ of 
when to use  is another matter.


I grok the desire to have all tags defined semantically, but if the 
semantic definitions add unnecessary complexity, then it just seems like 
a kludge. Anyone can understand  = bold.


Shaun



On 2012-04-30 3:46 PM, Andrés Sanhueza wrote:

The  element was made conforming due to widespread usage and for
some cases were other elements weren't suitable. However, I feel that
the current definition is not very clear, as it gives two somewhat
unrelated used for it: misspelled text and proper names on Chinese. I
believe that is fine if is one or the other, but by the current
definition seems that the purpose of retaining the element is merely
were to underline needs to be used to represent something regardless
what it is, which seems inconsistent with other similar tags that are
better defined to have more finite purposes that aren't based on the
fallback presentational look, even if relevant at the time of defining
those. By the definitions seems that proper names and book names are
suitable to be indicated by  and  respectively; or some new
element altogether. I'm aware that the fallback look is an issue, yet
I believe it should be resolved in a more consistent way.


--
Shaun Moss
+61 405478912
facebook.com/mossy2100
twitter.com/mossy2100
skype: mossy2100
groups.drupal.org: mossy2100

Re: [whatwg] [html5] r6088 - [e] (0) clarification Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=12165

[Shaun Moss]

On the contrary, I've often seen  used with  to mark up 
pre-formatted code. If you leave out the  tag then you've removed 
the semantics of the content, plus some source-code highlighting 
libraries look specifically for  tags. If the  tag is left 
out and CSS is used to style code elements as pre-formatted, without CSS 
classes this interferes with marking up code inline.


However, (perhaps tangential to the topic) as far as I know there are no 
rules to say whether the  tags should wrap the  tags or 
vice-versa.


Shaun



On 2011-09-09 8:09 AM, Ian Hickson wrote:

On Fri, 6 May 2011, Simon Pieters wrote:

Modified: source
===
--- source  2011-05-05 22:03:52 UTC (rev 6087)
+++ source  2011-05-05 22:45:13 UTC (rev 6088)
@@ -105238,7 +105238,6 @@
Use an explicitform  andtext field  combination instead.
   listing
-xmp
Usepre  andcode  instead.
   nextid
@@ -105256,6 +105255,9 @@
strike
Usedel  instead if the element is marking an edit,
otherwise uses  instead.
+xmp
+Usecode  instead, and escape "<" and"&" characters as"<" and"&"
respectively.

For xmp it should say "Use pre and code ..." since just code is not a drop-in
replacement for xmp.

Good point.

I went with "pre or code". I don't think you'd use both, typically, right?

Re: [whatwg] element

[Shaun Moss]

On 2011-09-07 5:17 AM, Benjamin Hawkes-Lewis wrote:

2011/9/6 Kornel Lesiński:

Browsing the web with user-submitted comments hidden sounds like a good use
case. There are extensions that do that in various browsers:

https://addons.mozilla.org/en-US/firefox/addon/commentblocker/
https://chrome.google.com/webstore/detail/ckdphbkdjpkpjabcnfogjmlddegeoenc
http://userscripts.org/scripts/show/74340

@class="comment" seems to solve this problem fairly well.


Of course! So does class="article", class="header", class="footer", etc. 
However, in my understanding the purpose of the new semantic elements in 
HTML5 is to provide a consistent mechanism for distinguishing different 
types of content in a web page, instead of everyone just using their own 
class names and ids. This empowers user agents to do things with the 
different types of content, such as skip navigation, transpose articles 
to different sites, or generate meaningful document outlines. Of course 
we can all just keep using class="comment", but then browsers can't do 
anything with comments, since HTML authors will not be consistent with 
class names and ids.


As it stands, there's no practical way for a user agent to distinguish 
between articles and comments. Even if they use the unappealing rule of 
"comments are articles within articles", this is hardly an elegant 
solution since user-submitted comments are often:

(a) not connected with articles, e.g. facebook status updates; or
(b) are not marked up inside the same region as the article or whatever 
is being commented on, e.g. youtube.


Why would we want to distinguish between articles and comments? Because 
they are different. Yes, it's possible for users to submit articles, but 
this doesn't make them comments!


- Articles are generally the main feature of a web page and the most 
important and valuable content on the page. It's true that 
user-submitted comments are occasionally valuable, but they're typically 
trivial (facebook and youtube again as examples)
- An article can stand alone, without comments, even if those comments 
add content (e.g. PHP documentation). A comment, however, needs context, 
hence the addition of the 'for' attribute. You would not be able to take 
a comment such as "Yeah, I love that video!", post it on a page by 
itself, and have it make sense. This is what I understand "stand-alone" 
to mean.
- It's unlikely that a user would want to hide an article, but it's 
quite possible that they might want to hide comments.


It's not practical to mark up everything that has comments attached to 
it with an  tag. As mentioned, comments can apply to links, 
images, videos, music, status updates - basically any kind of multimedia 
or content. Comments may be like articles in some ways, but they are not 
articles, and they shouldn't be bound only to articles. They should be a 
separate thing that can reference any other element.


Another useful feature of comments would be the ability to extract 
conversations from web pages. One comment could be "for" an article, 
video, link or whatever, but a /reply/ to that comment could be "for" 
the previous comment. With the current spec, this would require placing 
an article inside an article inside an article, and so on for however 
many replies there are (consider our current email thread, for 
instance). This is not beautiful or practical, in my opinion! It would 
make nested tables look elegant. But if conversations can be extracted 
from a web page, they can be archived, searched, syndicated, reorganised 
in different ways (linear vs. threaded views), etc.


As yet another use case, comments are often marked up differently. 
Consider this CSS:


/* this CSS applies to articles as well as comments */
article {
  background-color: white;
  font-size: 1em;
}

/* this CSS is for comments, and overrides the previous definition */
article article {
  background-color: silver;
  font-size: 0.8em;
}

vs. this:

article {
  background-color: white;
  font-size: 1em;
}

cmnt {
  background-color: silver;
  font-size: 0.8em;
}

Which would you prefer to code?




https://addons.mozilla.org/en-US/firefox/files/browse/130567/file/chrome/content/application.jsm#L28

An official bit of vocabulary might solve it a bit better, but
increase the complexity of the language.

I think that the web can bear the weight of one or two more tags :)



For this use case,  might be better than  so that one
could hide the chrome and widgets and cruft that form part of modern
comment lists.


Actually, we need both. I would suggest  or  for 
consistency.




I *like* the idea of this use case, but almost nobody uses the
CommentBlocker addon (870 users after 3 versions). So this use case
may be too narrow to support introducing core vocabulary.

--
Benjamin Hawkes-Lewis


Have a great day!
Shaun

Re: [whatwg] element

[Shaun Moss]

Sorry I can't address all your points in this reply, as I'm pressed for 
time. But I take your point about /content/ authoring vs. /html/ authoring.


At first I could not find anything refering to the old IE  tag, 
which I suspect was used less than . But then I found this page:

http://msdn.microsoft.com/en-us/library/ms535229(v=VS.85).aspx
So I accept that we shouldn't use  as the tag name.

One reasonable alternative is **, as this is concise, and is an 
established abbreviation for a user-submitted comment.

http://www.internetslang.com/CMNT.asp
http://www.urbandictionary.com/define.php?term=cmnt

Although there is a small risk of confusion with , I doubt this 
will be an issue since  is so rare and obscure.


Back to the main point of marking up comments, I offer youtube as an 
example.

http://www.youtube.com/watch?v=BRG5VNNUq_E

Here we have the item being commented on (the video) in a full-width 
block, with the lower half of the page divided into two sections, 
comments on the left. If user-submitted comments must be  tags 
inside  tags, then virtually the whole page would have to be 
inside an  tag, or, of course, the user-submitted comments are 
marked up as now, using class="comment".


The problem I am trying to solve is a perceived error in the HTML5 spec, 
which specifies that comments should be marked up as articles inside 
articles. I believe this to be an error for several reasons:


1. Articles and comments are different, and should therefore use 
different elements (otherwise the reference to marking up user-submitted 
comments as articles within articles should be removed).
2. Comments are a unique type of content, since they are submitted by 
users, not site developers or content managers.
3. Robots and plugins can extract comments from web pages more easily if 
they have their own element. Comments can then be more easily 
syndicated, displayed, hidden, styled, etc.
4. Comments often apply to things other than articles, such as blog 
posts, forum topics, social network status updates, images, videos, 
links, and other comments, which should not have to be marked up as 
articles just so the comments can be marked up as articles within articles.
5. Comments sometimes appear in a different region of the page than the 
item that they are referencing, hence the markup for comments should not 
have to be contained within the markup of the item.


I'm not trying to be a jerk. Please seriously consider what I am showing 
you. I will happily write a proposal for a  element for the W3C 
and browser vendors, and submit it to you for (haha) comments.


Thanks,
Shaun




On 2011-09-06 10:34 AM, Benjamin Hawkes-Lewis wrote:

On Mon, Sep 5, 2011 at 11:21 PM, Shaun Moss  wrote:

Sorry that it's difficult for you to think of concise names, but I hardly 
think  is ambiguous.

Really? So if in the course of a discussion of something else, I make
a comment about something, could I mark that up with? Or
should comments only be block-level sections relating to an article or
some other bit of content?

In any case, we can't realistically use  thanks to legacy behaviours.


If you really think that 99.9% of HTML is written using WYSIWYG editors then
you are clearly not a web developer.

I am a web developer.

I think it's reasonable to say that 0.01% or less of the _content_ on
the web (as opposed to the _code_) is written by non-developers.

The experience of web developers isn't particularly relevant to
majority authorship.

Mostly non-developers are using WYSIWYG editors (e.g. email clients,
WordPress, Google Sites, etc). Less often, they are using non-HTML
markup-like systems like WikiMedia markup and Textile. Rarely, they
are using extremely simple HTML markup directly (mostly limited by
content filters to  and).


Yes, some is generated using editors,
but a considerable amount is not, especially in the world of PHP, Perl,
Python, Drupal, Joomla, Wordpress, etc., etc. where HTML is often embedded
in templates, which must be hand-coded.

Indeed, but non-developers are mostly not writing templates.


In fact, if your belief is prevalent
within WHATWG, this is a good indication as to why the spec has become more
complex instead of simpler.

The complexity of the spec is one of many reasons why we're not in a
rush to introduce new features that don't solve significant problems.
(I encourage you again to think about what problem you are trying to
solve and what the possible solutions might be.)


Regarding WYSIWYG editors in general, do you really think they generate
perfect markup

No.


and that the developers of these apps and plug-ins are experts in the HTML spec?

I think most developers of WYSIWYG editors have looked at HTML specs.
I'd class very few people as "experts" on the specs.


Every WYSIWYG editor I know of now uses
tags for bold and  tags for italic. This is technically incorrect

Just because people know what a s

Re: [whatwg] element

[Shaun Moss]

On 2011-09-05 11:13 PM, Benjamin Hawkes-Lewis wrote:

On Mon, Sep 5, 2011 at 9:55 AM, Shaun Moss  wrote:

Please explain to me how it makes sense for a comment to stand on its own.

Works just as well as all those blog posts that are just commentary on
something someone else has written. (And which often are syndicated as
comments via pingback.)

In which case they can (and should) be marked up as comments.




To an HTML author, especially a newbie, an article *is* a newspaper article,

and this is entirely distinct from a user-submitted comment related to the
article. Semantics isn't just for robots, it's for humans, too - a fact that
seems to be frequently overlooked.

This seems a rather Anglophone-centric argument. In any case, it turns
out to be very hard to come up with concise names that are
unambiguous. For example,  has often been misunderstand as
intended to wrap a quotation rather than a source or title.


Yes, well, forgive me for seeming anglophone-centric, but the fact 
remains that HTML as well as most other programming languages use 
English words, most of the people who use these languages speak English, 
and presumably they expect something to mean what it says. Otherwise we 
should just name our tags  and . Sorry that it's 
difficult for you to think of concise names, but I hardly think 
 is ambiguous.




That it is hard to name things unambiguously is not necessarily a good
reason to introduce more names.


This may come as a surprise, but 99.9% of HTML authors don't read specs.

When it comes what to what markup blogs and CMSes should churn out to
structure the page, this hardly matters. The 99.9% will be generating
content via WYSIWYG editors, and the results of their labors will be
dumped into the relevant HTML5 structural elements, as generated by
code produced by the much smaller segment of authors with marginally
better spec awareness.


If you really think that 99.9% of HTML is written using WYSIWYG editors 
then you are clearly not a web developer. Yes, some is generated using 
editors, but a considerable amount is not, especially in the world of 
PHP, Perl, Python, Drupal, Joomla, Wordpress, etc., etc. where HTML is 
often embedded in templates, which must be hand-coded. In fact, if your 
belief is prevalent within WHATWG, this is a good indication as to why 
the spec has become more complex instead of simpler.


Regarding WYSIWYG editors in general, do you really think they generate 
perfect markup, and that the developers of these apps and plug-ins are 
experts in the HTML spec? Every WYSIWYG editor I know of now uses 
 tags for bold and  tags for italic. This is technically 
incorrect, but what WYSIWYG is going to have one button for "important 
text" and another for "bold text"? In any case, having used dozens of 
such editors, I can tell you that the HTML generated is frequently wrong 
or broken, and it's frequently necessary to switch to source mode to fix 
it. Plus, how many WYSIWYG editors have buttons for , , 
or even ? If you want to use these elements you have to get your 
hands dirty, even if most of your page structure is generated.


Shaun




--
Benjamin Hawkes-Lewis

Re: [whatwg] element

[Shaun Moss]

The link you've sent contains numerous comments, none of which can stand 
on their own. Also, this example comment is long and well-written, 
deliberately selected from "bestof", to try and make your point. 
However, 90%+ of user-submitted comments are much more trivial. Consider 
most facebook comments.


Comments have two distinct features that distinguish them from articles:
1. They are submitted by users, not content managers.
2. They are in reference to something else on the page, whether it be an 
article, link, forum topic, blog post or another comment.


Shaun




On 2011-09-06 5:17 AM, Tab Atkins Jr. wrote:

On Mon, Sep 5, 2011 at 1:55 AM, Shaun Moss  wrote:

On 2011-09-05 6:36 PM, Odin wrote:

On Sun, Sep 4, 2011 at 10:43 PM, Shaun Moss
  wrote:

Yes, but this is not semantic!!! Comments are not articles. They are
completely different. Comments can appear in reference to things that are
not articles (such as status updates), and therefore would not appear
inside
antag - so how would the browser recognise them as comments?

It is semantic.

Comments *are* in fact articles. You're thinking of it in the wrong
way. Article is not a newspaper article, but something that would make
sense to stand on its own.

Please explain to me how it makes sense for a comment to stand on its own.

For 
example:<http://www.reddit.com/r/AskReddit/comments/cf1n2/holy_fuck_i_just_saw_someone_get_hit_by_a_train/c0s4de4>

(Comment pulled at random from r/bestof.)

A comment is an individual piece of work that may be usefully cited on
its own.  It's related to the parent article (which may be another
comment, or may be the original blogpost), but it can be usefully
viewed by itself and syndicated.

~TJ

Re: [whatwg] element

[Shaun Moss]

On 2011-09-05 6:36 PM, Odin wrote:

On Sun, Sep 4, 2011 at 10:43 PM, Shaun Moss  wrote:

Yes, but this is not semantic!!! Comments are not articles. They are
completely different. Comments can appear in reference to things that are
not articles (such as status updates), and therefore would not appear inside
an  tag - so how would the browser recognise them as comments?

It is semantic.

Comments *are* in fact articles. You're thinking of it in the wrong
way. Article is not a newspaper article, but something that would make
sense to stand on its own.


Please explain to me how it makes sense for a comment to stand on its own.

To an HTML author, especially a newbie, an article *is* a newspaper 
article, and this is entirely distinct from a user-submitted comment 
related to the article. Semantics isn't just for robots, it's for 
humans, too - a fact that seems to be frequently overlooked. Giving 
elements obscure, unobvious meanings in the spec is a kludge, plain and 
simple. For example, to the WHATWG and W3C the  tag now basically 
means "different but not important". The ,  and  tags have 
similarly gained bizarre new definitions. To everyone else on the 
planet, however,  means bold,  means italic,  means underline 
and  means strikethrough. This may come as a surprise, but 99.9% of 
HTML authors don't read specs. They look at a tag, and think, now what 
would I use that for? "Ok, so the  tag is for tables, right? I 
guess  is for articles, then. Oh, it's for user-submitted 
comments, too? wtf?"




So, a *nested* article is defined to be dependent on the outer
article, but still it is it's own content and can be syndicated as a
individual content piece that's related to the parent article.

It makes perfect sense and is quite beautiful and doesn't require a
whole slew of tags. It's very nicely done.


We don't need a whole slew of new tags. We need *one*: , and 
/maybe/ one more: , to wrap them.
I'm not sure of the reluctance to introduce new tags that are useful and 
have a clear purpose. There are 10 tags just to describe tables. I'm not 
saying we should do that. I'm saying: here is a very obvious use case 
for an element that (imho) is not being met by the current spec.




And comments /are/ syndicated. Just look at WordPress. When I read
blogs in Liferea, I get the blog posts, as well as each individual
comment loaded from the syndicated comment-stream from that particular
blog post.



   HTML5 is great
   Yup. It is.
   By Me

   
 You're so correct!
 By Ben
   

   
 Better than butter, I say
 By Adam
   





Perfect is the enemy of good. Cue in xhtml2. :-)


This is a false analogy. HTML5 is better than XHTML2, because it reduces 
errors and is more in line with browser behaviour. If XHTML2 was perfect 
it wouldn't have been canned. I'm not talking about anything like that. 
I'm proposing a new tag to represent an extremely common feature of 
millions of websites.


Shaun

Re: [whatwg] and elements

[Shaun Moss]

On 2011-09-05 7:56 AM, Shaun Moss wrote:
I like your thinking about the possibility of a comment being about 
another web page, or about an item on that web page. It could have 3 
basic forms:


 to refer to an item on the same page, e.g. an 
article or blog post.

 to refer to another web page.
 to refer to an item (article or similar) on 
another web page.


Actually, now that I think about it, these forms don't really work. For 
starters, there should not be a '#' preceding the id of the related 
item, for consistency with the "for" attribute as used elsewhere (e.g. 
).


More importantly, there is probably no need for the value of the "for" 
attribute to be a URL. In any situation where a comment is about another 
web page, a link will be present on the page that the  can 
reference. So the form in this case would be:


http://example.com";>Example website

This website has a lot of great resources and ideas.


Hence the only valid usage for the "for" attribute would be as with 
, i.e. for="id".


Cheers,
Shaun

Re: [whatwg] and elements

[Shaun Moss]

Thanks, Jukka :)

I like your thinking about the possibility of a comment being about 
another web page, or about an item on that web page. It could have 3 
basic forms:


 to refer to an item on the same page, e.g. an 
article or blog post.

 to refer to another web page.
 to refer to an item (article or similar) on 
another web page.



With regard to the use of  for comments, the spec for article 
doesn't fit user-submitted comments:


"The|article 
|elementrepresents 
a 
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."


User-submitted comments are not independently distributable or reusable, 
e.g. in syndication. Neither, for that matter, are forum posts, 
generally speaking, although the initial post may be equivalent to an 
article. Forum posts would be better marked up with , since 
they're user-contributed content.


"When|article 
|elements 
are nested, the inner|article 
|elements 
represent articles that are in principle related to the contents of the 
outer article. For instance, a blog entry on a site that accepts 
user-submitted comments could represent the comments as|article 
|elements 
nested within the|article 
|element 
for the blog entry."


This is a kludge because comments could be related to things other than 
articles, and hence not appear nested in an  tag. Also, more 
importantly: user-submitted comments aren't articles!


"Author information associated with an|article 
|element 
(q.v. the|address 
|element) 
does not apply to nested|article 
|elements."


Fair enough, but note that comments often contain author information, 
i.e. the person who submitted the comment and when. Hence, if we insist 
on using the semantically incongruous tag  for author 
information, it should also be permissible inside  elements.


Have a great day!
Shaun







On 2011-09-05 6:45 AM, Jukka K. Korpela wrote:

4.9.2011 23:27, Odin wrote:


We already have a comment tag. It's listed in the article-element
section of the spec. Article within article is suggested to be a
comment:


Suggested, not defined.


When article elements are nested, the inner article elements represent
articles that are in principle related to the contents of the outer 
article.


That's the definition of the meaning of nesting article elements: "in 
principle related to".



For instance, a blog entry on a site that accepts user-submitted
comments could represent the comments as article elements nested
within the article element for the blog entry.


That's an example. "Could represent".

If we assume that authors use elements as per the spec as currently 
worded, you _cannot_ decide that an article inside an article is a 
comment. Just as it might be. It could be anything "in principle 
related to" the contents of the outer article.


Besides, while many principal entries in a blog are relatively 
self-contained and might be suitable for syndication, I don't think 
most blog _comments_ share that property. A comment is _typically_ 
strongly dependent on the context and seldom suitable for syndication. 
So making authors and systems use  for blog comments would be 
bad for the very idea of .


If we think that comments need markup of their own, then I guess 
 would be OK, on the grounds already presented, and the 
natural way to create useful semantic associations would be to allow 
(and recommend)  elements to have an attribute, say for=..., 
that refers (by id) to the element that it comments on - maybe with 
the added semantics that if the referred element is a link (), 
then the comment is about the linked resource, not the link as such.


This would make it possible to marku up some content as a comment to 
some _external_ document too, such as a different page in the same 
system, in a discussion forum view where each entry is displayed as a 
separate HTML document, just linked to others in the thread.

Re: [whatwg] and elements

[Shaun Moss]

On 2011-09-05 6:27 AM, Odin wrote:

On Sun, Sep 4, 2011 at 8:14 AM, Shaun Moss  wrote:

I've joined this list to put forward the argument that there should be
elements for  and  included in the HTML5 spec.

We already have a comment tag. It's listed in the article-element
section of the spec. Article within article is suggested to be a
comment:

http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-article-element


Yes, but this is not semantic!!! Comments are not articles. They are 
completely different. Comments can appear in reference to things that 
are not articles (such as status updates), and therefore would not 
appear inside an  tag - so how would the browser recognise them 
as comments?







When article elements are nested, the inner article elements represent
articles that are in principle related to the contents of the outer article.
For instance, a blog entry on a site that accepts user-submitted
comments could represent the comments as article elements nested
within the article element for the blog entry.


  is no good idea exactly how Rand McRanderson explained it. You
can read it on the wiki as well:
http://wiki.whatwg.org/wiki/Rationale#Failed_proposals

Re: [whatwg] and elements

[Shaun Moss]

Hi Jukka

That's an interesting thought about the  element, and making it 
simple to turn them off using CSS. This would indeed dissuade authors 
from using it. I'm not sure of the best solution, since  still 
seems like a kludge, but it may have to do in this case because of the 
nature of ads.


Regarding comments...

A suggested semantic meaning for : /The content of this element 
has been contributed by a website user in reference to an article, 
discussion topic, status update, image, video, or some other item of 
content./


The idea of a "for" attribute for the comment tag is a great one! Yes, 
absolutely perfect. But it would be less useful to use the tag 
. Everyone knows what  means, it's an extremely 
frequent semantic meme across the web (see previous post), and I already 
have students already complaining that tag names are getting too long.


Re your comment: "I don't think commonness is sufficient for introducing 
a markup element", didn't the algorithm used to discover the new HTML5 
tags scan billions of web pages and look for common and recurring class 
names and ids? Surely commonness is the primary metric by which new tags 
have been determined? Your example with  is not a particularly 
accurate analogy - I can't imagine there are too many web pages out 
there with  everywhere, necessitating a tag.


Similarly "since any new element would have the problem that some 
relevant browsers do not even let you style an element unknown to them - 
for example, if you wish to style , you need to teach it to IE 
with a little JavaScript. It's simpler and safer to keep using class=article> for some years, no matter what people might write in the 
specs." By this reasoning we shouldn't introduce *any* new tags!! You 
might like this: http://code.google.com/p/html5shim/


Thanks!
Shaun



On 2011-09-05 4:23 AM, Jukka K. Korpela wrote:

4.9.2011 9:14, Shaun Moss wrote:


I've joined this list to put forward the argument that there should be
elements for  and  included in the HTML5 spec.


IE recognized  and ignored it in display, so it was like a 
comment declaration (). It seems that they dropped support 
at some stage (perhaps in IE 7). So maybe the old effect and usage 
would not disturb much, if you wanted to define a completely different 
semantic meaning for it. I guess what you mean is semantics like 'the 
content of this element is a commentary' (perhaps with a for=... 
attribute to indicate what it is a comment on?). But if introduced, 
I'd still call it .



These are both extremely common features of many web pages;


I have no strong feelings about this, but I don't think commonness is 
sufficient for introducing a markup element. For example, almost all 
HTML documents contain verbs, and yet nobody has proposed a  
element. Just ease of writing isn't really a good motive, especially 
since any new element would have the problem that some relevant 
browsers do not even let you style an element unknown to them - for 
example, if you wish to style , you need to teach it to IE 
with a little JavaScript. It's simpler and safer to keep using class=article> for some years, no matter what people might write in 
the specs.


There's a real argument in favor of : it lets robots detect 
pieces that might be eligible for syndication. What would  be 
useful for?


For , there's the obvious potential usage of setting

ad { display: none !important }

in a user style sheet. I don't think this possibility would make  
popular among authors.

Re: [whatwg] and elements

[Shaun Moss]

Hi John! (Or Rand.)

I hadn't heard of the  tag from IE before, and I've been 
authoring HTML since 1995. So I don't think it would be confusing, 
certainly not more so than any of the new definitions for , , or 
any of the other repurposed tags. As you say, it would allow robots to 
distinguish s from the s that they relate to; and it 
would be easier to style them.


 elements could be used to refer to any comment added to a blog 
post, article or discussion forum. You could call it something else, 
like , but this would be more confusing I think, since they're 
called "comments" everywhere on web pages ("Post a comment", "Add a 
comment" "Login or sign up to post comments", facebook "Like - Comment - 
Share", etc., etc.). I use Drupal a lot as well (apparently 2% of the 
world's websites now run on Drupal) and comments are a core feature, as 
they are of any community site.


Shaun



On 2011-09-05 5:41 AM, Rand McRanderson wrote:

I could say from a robots perspective, a comment tag might be useful since 
users sometimes want the option to view comments but not necessarily that as a 
default.

For example many blogs/cmses offer a comment feed, also many news articles will 
have a default of no comments with a trigger to show comments. Also consider 
Discus as a model where comments and content are separated.

But I think from an author's perspective a "comment" tag would be confusing (they might 
think this is a revival of the ie method). The "commentary" tag might work, though it is 
a long tag + I feel like commentary implies something longer and more formal than a comment on the 
web. However, I can't think of any intuitive, more concise tag names.

- John Thomas


- Reply message -
From: whatwg-requ...@lists.whatwg.org
Date: Sun, Sep 4, 2011 3:08 pm
Subject: whatwg Digest, Vol 90, Issue 5
To:

Send whatwg mailing list submissions to
whatwg@lists.whatwg.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org
or, via email, send a message with subject or body 'help' to
whatwg-requ...@lists.whatwg.org

You can reach the person managing the list at
whatwg-ow...@lists.whatwg.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of whatwg digest..."


When replying to digest messages, please please PLEASE update the subject line 
so it isn't the digest subject line.

Today's Topics:

1.  and  elements (Shaun Moss)
2. Re:  and  elements (Jukka K. Korpela)


--

Message: 1
Date: Sun, 04 Sep 2011 16:14:40 +1000
From: Shaun Moss
To: whatwg@lists.whatwg.org
Subject: [whatwg]  and  elements
Message-ID:<4e631750.4030...@astromultimedia.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi all

I've joined this list to put forward the argument that there should be
elements for  and  included in the HTML5 spec.

These are both extremely common features of many web pages; I would say
at least as common as "article". At present there is no obvious semantic
element for comments and ads. To use,  or  is
a kludge at best.

I would love to hear people's thoughts on this idea, as I'm sure it
would have been discussed before. Please also let me know the process
for submitting a formal proposal to the WHATWG or the W3C about this.

I'm the founder and CEO of IWDA (International Web Development Academy),
and currently writing a course in HTML5.

Thanks,
Shaun



--

Message: 2
Date: Sun, 04 Sep 2011 21:23:09 +0300
From: "Jukka K. Korpela"
To: whatwg
Subject: Re: [whatwg]  and  elements
Message-ID:<4e63c20d.6090...@cs.tut.fi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

4.9.2011 9:14, Shaun Moss wrote:


I've joined this list to put forward the argument that there should be
elements for  and  included in the HTML5 spec.

IE recognized  and ignored it in display, so it was like a
comment declaration (). It seems that they dropped support
at some stage (perhaps in IE 7). So maybe the old effect and usage would
not disturb much, if you wanted to define a completely different
semantic meaning for it. I guess what you mean is semantics like 'the
content of this element is a commentary' (perhaps with a for=...
attribute to indicate what it is a comment on?). But if introduced, I'd
still call it.


These are both extremely common features of many web pages;

I have no strong feelings about this, but I don't think commonness is
sufficient for introducing a markup element. For example, almost all
HTML documents contain verbs, and yet nobody has proposed a
element. Just ease of writing isn't really a good motive, especially
since any new element wo

[whatwg] and elements

[Shaun Moss]

Hi all

I've joined this list to put forward the argument that there should be 
elements for  and  included in the HTML5 spec.


These are both extremely common features of many web pages; I would say 
at least as common as "article". At present there is no obvious semantic 
element for comments and ads. To use ,  or  is 
a kludge at best.


I would love to hear people's thoughts on this idea, as I'm sure it 
would have been discussed before. Please also let me know the process 
for submitting a formal proposal to the WHATWG or the W3C about this.


I'm the founder and CEO of IWDA (International Web Development Academy), 
and currently writing a course in HTML5.


Thanks,
Shaun