[Bug 6774] <mark> element: restrict insertion by other servers

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6774





--- Comment #3 from Nick Levinson <Nick_Levinson@yahoo.com>  2009-04-24 08:10:06 ---
Crackers often don't care about permission, but major-brand browser makers do.
They'll need to offer HTML5 compliance for their business not to suffer, and
that will legally be defined as general compliance with the W3C standard.
Warranties, at least in the U.S., that apply to buying a computer or a lot of
them include approximate compliance with the standards when the browser
manufacturers offer HTML ability. Standards thus matter in law. If the standard
grants permission, the major manufacturers can exploit it and may profit from
it (the objection is not to profit per se but profit is a motivator likely to
increase the volume of <mark> tagging). Crackers do plenty without permission,
but what major-brand suppliers could also do with permission via their
widely-distributed products would add massive quantities of exploitation.

Present practices in scripting are often not violations at all. Neither are the
other tags that you mentioned.

The proposed standards for the <mark> element and for the <b>, <span>, and
other similar elements differ in one critical aspect. None of the latter
elements would depend on a user's current activity. Only the mark element would
depend on that knowledge.

>From the draft standards: "The span element doesn't mean anything on its own,
but can be useful when used together with other attributes, e.g. class, lang,
or dir." W3C Working Draft 23 April 2009, Section 4.6.18. "The b element
represents a span of text to be stylistically offset from the normal prose
without conveying any extra importance, such as key words in a document
abstract, product names in a review, or other spans of text whose typical
typographic presentation is boldened." Id., sec. 4.6.20. "The i element
represents a span of text in an alternate voice or mood, or otherwise offset
from the normal prose, such as a taxonomic designation, a technical term, an
idiomatic phrase from another language, a thought, a ship name, or some other
prose whose typical typographic presentation is italicized." Id., sec. 4.6.19.
"The strong element represents strong importance for its contents." Id., sec.
4.6.5. "The em element represents stress emphasis of its contents." Id., sec.
4.6.4.

By contrast: "When used in the main prose of a document, it ["[t]he mark
element"] indicates a part of the document that has been highlighted due to its
likely relevance to the user's current activity." Id., sec. 4.6.7.

That requires knowing "the user's current activity."

Knowing could be by the method the article you referenced described, namely, if
the user arrives at a page via a search engine the HTTP referer could be used
in generating a page with any HTML content desired. That method is safe
because, in order to apply it, the website owner's permission is needed in
order to modify or generate a page according to the referer. No objection here.

Scripts in general cannot be on a page unless the website owner approves. As a
website owner I don't object to scripts being in the standards. Some scripts
are useful. If I don't want one, I don't put any on a page. And, so far, I
don't, because I want my content to be as useful to people who turn their
browsers off against all scripts. The same need for a site owner's permission
is true of PHP and Perl. I'm planning to add Perl for a security purpose.
Neither of those languages is being added without my consent.

But <mark> wouldn't limit how "the user's current activity" is to be known. It
could be with permission, but it could be without permission. Nowadays, that's
considered insecurity. Under HTML5, the definition of the mark element would
give permission to know, and permission to apply the knowledge. The permission
would not be because the mark element has to be present in a page's markup, it
could be absent, but because HTML5 would specify that <mark> is for "the user's
current activity." That purpose, because it is stated in HTML5, would be
permission for adding <mark></mark> to arbitrary locations within a page. The
permission would not be limited to the owner or even the recipient of a page
but would be permission for anyone (and the recipient should not have that
permission unless they are aware that they, the recipient among typical amateur
recipients, is doing it, and is not under the impression that the owner is
doing it). Because it would be permission for anyone, injection of <mark>
markup by arbitrary parties along the route of transmission would be permitted
by HTML5. That would be a breach caused by the standards.

HTML5 should not be consent to inject anything by anyone without the owner's
consent. It is. It should not be.

If the element is taken away, the span element appears quite sufficient for all
purposes that the mark tag would otherwise serve legitimately. The span element
can, for example, have the class attribute. Therefore, the <mark> element
should be removed from HTML5 altogether or it should be redefined to be just a
presentational alternative to <b>, <em>, <strong>, and <i> without knowledge of
a "user's current activity."

If there's still some need for <mark> as presently defined, then the ability to
defeat intermediary interjection is a necessity, and for that the addmark meta
keyword is a solution. Creating addmark as an attribute directly in the mark
element won't suffice while the standard would allow the mark element to be
added by someone else, who presumably would never use addmark, never asking the
site owner for an opinion. But a meta element can serve as a per-page block,
albeit requiring more coding just to opt out from undesired effects.

Right now, getting rid of <mark> completely is the ideal solution. A good
alternative is to redefine it to remove anything like "the user's current
activity" from possible relevance. The only other good alternative is a metatag
with addmark. One of these choices is needed.

Thank you.

-- 
Nick


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 24 April 2009 08:10:15 UTC