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 <comment> tag, which I suspect was used less than <blink>. 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 <comment> as the tag name.

One reasonable alternative is *<cmnt>*, 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 <comment>, I doubt this will be an issue since <comment> 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 <article> tags inside <article> tags, then virtually the whole page would have to be inside an <article> 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 <cmnt> 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<sh...@astromultimedia.com>  wrote:
Sorry that it's difficult for you to think of concise names, but I hardly 
think<comment>  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<comment>? 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<comment>  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<b>  and<i>).

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<strong>
tags for bold and<em>  tags for italic. This is technically incorrect
Just because people know what a spec says does not mean the software
they produce will follow it.

how many
WYSIWYG editors have buttons for<address>,<cite>, or even<dl>? If you
want to use these elements you have to get your hands dirty, even if most of
your page structure is generated.
Indeed. Naturally, these elements don't occur in content authored by
most people.

--
Benjamin Hawkes-Lewis

Reply via email to