Re: suggestion for tag set <sarcasm> </sarcasm> pair

2014-11-04 1:52, Steve Faulkner wrote:
> sure, what you get with a custom element, is that the semantics are 
> added for you.

What “semantics” is added for me by whom/what? All I can see in your 
example is just a way to style an element. What “semantics” beyond that 
do you mean? You could also add some functionality to it, e.g. so that 
clicking on the element causes a maniac laughter. But nobody else is 
going to add such “semantics” for you. If you mean that the made-up tag 
name “sarcasm” is semantic, or carries a meaning, how would that differ 
from the use of <span class=sarcasm>?

> Besides <sarcasm> is an exercise in suggesting we don't need a native 
> element for everything and if one really wants an element , then it 
> can be done using newer features of the open web platform, if one so 
> desires.

Two questions:

1) Why would you want to use an element of your own when you can achieve 
the same reliably, in all browsers, without any new features, by using a 
class element on a suitable general-purpose element like <span> or 
<div>? (It can make the code shorter and superficially more readable, 
but is there anything else?)

2) Assuming that you really, really want an element, what is the benefit 
of using new features, defined in drafts and with experimental 
implementations, as opposite to just using <sarcasm> and styling it? It 
works in all browsers except some old versions of IE, where the new 
features surely won’t work and where the simple 
document.createElement('sarcasm') trick will fix the issue when 
scripting is not disabled.

I gather that you have some wider perspectives and scenarios where the 
new extension mechanisms might be useful. But it looks confusing when 
suggested, in a simple case like this, as a solution to something that 
has a much simpler solution that works here and now.

The only real problem with just using custom tags is that some future 
browsers may, as their own extensions or as an implementation of some 
new specification or draft, recognize such a tag with some real meaning 
– with some definition assigned to it, possibly (or probably) with some 
default styling, perhaps some default functionality, maybe some impact 
on search engines, and with some fixed content model and allowed 
contexts. This would cause unpredictable consequences to any document 
that uses it as a custom tag.

This problem could be addressed by defining a mechanism that declares an 
element as a custom element, effectively so that it will be treated as 
/HTMLUnknownElement even if the element has a definition in some 
specification or draft. Since we probably don’t want to add general 
declarative mechanisms to HTML, at this point, this might need to be a 
somewhat ugly convention, e.g. so that the attribute @custom in the 
first of the element would do this. So <sarcasm custom>...</sarcasm> 
would protect against any unexpected handling of the element in future 
browsers. To avoid unnecessary implementation burden, the attribute 
could be treated as invalid for any element defined in HTML (as 
currently specified in the W3C Recommendation).

More complicated extension mechanisms may well provide much wider 
possibilities, but this one would seem to meet the needs of most authors 
who wish to use tags of their own.
/

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

Received on Tuesday, 4 November 2014 07:07:50 UTC