[whatwg] Add 'type' attribute to <mark>

[Eduard Pascual]

First of all, I'd like to avoid any missunderstandings: I have nothing
against the <mark> element itself; although I'm afraid my previous
e-mails may lead to think otherwise. It could be a really good
addition to HTML but, IMHO, it isn't yet, and I'm trying to show why I
think so.

On Sat, Nov 1, 2008 at 2:57 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Sat, 1 Nov 2008, Eduard Pascual wrote:
>> [...]
>> What's the difference then between <mark> and <span> then? I mean, does
>> the <mark> element provide anything that <span> with an appropriate
>> class wouldn't?
>
> A default style when there's no CSS support, support in accessibility
> tools, the ability for search engines to understand what's going on,
> easier round-tripping between editors, simpler rules in CSS and other
> selector-like environments, etc. The usual benefits of semantics.

Let's take that point by point:

-> A default style when there's no CSS support: that's entirely
presentational; and although I may accept it as a side-bonus, I don't
feel presentational arguments are a good base for including/excluding
a new element.

-> Support in accessibility tools: that's plain daydreaming: what kind
of support can an AT provide without any hint on whether the <mark>'ed
text is a search term, or the line of a code snippet that caused a
crash, or the total price of the orders in a shopping cart, or
whatever other usage authors may come up with?

-> The ability for search engines to understand what's going on??
Comming from someone else, I'd think they are simply wrong, but
comming from Ian I really hope you were joking: besides a SE would be
as clueless on that aspect as an AT; this would extremelly easily
abused by "black hat" SEO, to the point of making the element
completely meaningless for SEs: just a "mark { display: none; }" rule
and a site becomes able to freely spam "highlighted" keywords across
the entire page. And, although many SEs are capable of checking CSS
sheets, it's almost trivial to achieve the same from JavaScript, and
even to obfuscate the script if any SE managed to figure the trick
out.

-> Simpler rules in CSS and other selector-like environments: I simply
can't believe that this came from an editor of the CSS3 Selectors
module. How much simples is "mark" than ".match", ".crash_line",
".total", and so on? The only difference is a single dot; plus the
fact that classes give much more flexibility that directly styling (or
selecting on any other similar environment) could ever allow. And
finally, it's worth to mention that, as soon as a page needs to use
<mark> for two or more different purposes, there is no other way to
differentiate them in selectors than classes (and no way at all for
ATs or SEs to differentiate then, BTW).

-> The usual benefits of semantics. Honestly, that's a really good
purpose; it's only that it's not achieved. If you look again at the
counter-arguments above, you should be able to notice that they are
nothing else than the usual drawbacks of lack of semantics. Because,
simply put, the semantics defined for <mark> are so vague that, in
practical terms, they are the same as no semantics at all. Pentasis's
initial proposal would be a simple and efficient solution to this
issue: with some sort of type/role/whatever attribute (based on a
well-defined list of allowable values), an AT could tell the user why
some text is marked, a SE could figure out what's really going on, and
a designer could rely on that attribute upon selection instead of
defining classes with an entirely presentational purpose.

Well, that's my opinion, just wanted to share it.