- From: Ian Hickson <ian@hixie.ch>
- Date: Sun, 17 Feb 2008 23:08:09 +0000 (UTC)
The <m> element received a _lot_ of feedback; indeed as I write this the
subject line with the third most unanswered e-mails in my issues list is
simply "The m element".
Executive Summary: Despite a lot of feedback suggesting dropping the
entire element, I considered the number of use cases for the element, and
the number of high-profile sites working around the lack of such an
element, to be enough reason to keep the element for now. However, I did
act on the feedback suggesting that the element be renamed; the element is
now called <mark>. I also significantly updated the description of the
element and added a number of examples. I hope these changes clarify how
one uses the element.
FEEDBACK CONCERNING THE EXISTENCE OF THE ELEMENT IN GENERAL
On Thu, 8 Feb 2007, Anne van Kesteren wrote:
>
> I think I agree that <m> should be dropped. I believe such an element
> has never been requested before on www-html or equivalent fora.
On Sat, 10 Feb 2007, Lachlan Hunt wrote:
>
> No, the use cases for <m> are clear, and it is different from both <em>
> and <strong>. I think it should be kept as-is, though its definition in
> the spec clearly needs to be improved.
On Fri, 9 Feb 2007, Anne van Kesteren wrote:
>
> I'm not arguing against this. (Heck, I provided the idea for the second
> example.) I'm just saying it hasn't really been requested before and
> that I'm wondering whether it's common enough to warrant a new element.
While it is true that few people have explicitly requested this element,
the same could be said for almost all the other new elements in HTML5. For
new elements we have to consider what people are doing, as well as what
they are asking for.
On Thu, 8 Feb 2007, Rimantas Liubertas wrote, in response to Anne's first
comment above:
>
> +1.
Mere agreement isn't a strong argument. :-)
On Fri, 9 Feb 2007, Anne van Kesteren wrote:
>
> perhaps we shouldn't really specify this as an element yet and let the
> microformat community look into it more closely first.
On Sat, 10 Feb 2007, Jorgen Horstink wrote:
>
> I'm an advocate of Anne's suggestion to let the microformat community
> look into it more closely first.
The semantic in question isn't the kind of thing I would imagine would fit
the microformat ethos.
On Sat, 10 Feb 2007, Charles McCathieNevile wrote:
>
> As far as I understand it, it means something very like emphasis.
> Expecting people to read the spec for things that have a clear and
> distinct meaning hasn't worked before, so why would we expect it to work
> now in the case of a fine semantic distinction?
>
> I think there are lots of ways of splitting the hairs that define the
> difference, but I don't see that the element is worth adding. And I am a
> native english speaker trying to understand the differences. I can only
> guess at what those people I work with who speak dreadful english are
> going to make of it. I guess it could become the google element (if that
> is the example), or just an optional variant of em (in the same way that
> strong is often used now).
I think the semantic in question is distinct enough from the existing
elements that it isn't just splitting hairs. Historically the
specifications have been very vague on how these elements are used, but
with HTML5 we can define these strictly enough that it should be possible
for people to pick up the right use. (I disagree that the status quo of
confused authors is inevitable, given that the specs they would have been
referring to are at least as confused themselves.)
USING THE <B> ELEMENT INSTEAD
On Sat, 23 Jul 2005, Simon Pieters wrote:
>
> I think <m> should be replaced by <b> because <b> already works as a
> marker or a highlighter, even without CSS, and <m> is impossible to
> style in IE6 without hacks.
>
> I couldn't find any suitable synonyms to "marked" or "highlighted" that
> starts with "b", but I don't think that should be reason enough to drop
> the element type. Given that <kbd> represents "user input (typically
> keyboard input)", <b> could represent "marked or highlighted (typically
> bold)", IMHO.
>
> "The b element represents a run of text marked or highlighted (typically
> highlighted as bold in visual user agents, although it may be
> highlighted in any way suitable for the UA)."
On Mon, 16 Jan 2006, Simon Pieters wrote:
>
> I think that we should use <b> instead of <m>. It will stand for marked
> or highlighted. The reason for this is backwards compability. I think
> it's ok, given that we have <dl> to stand for "unordered association
> list", while we havn't given it the name <ual> (or simular).
>
> If we use <b>, Google is already (partially) compliant. ;-)
The difference between the semantic of <b> and the semantic we are
discussing here is that while <b> indicates key words in the text,
independent of the reader, the element we are discussing here is
highlighting key words theoretically relevant for the user.
On Mon, 7 Nov 2005, ROBO Design wrote:
> >
> > Should we just repurpose u or b for this semantic instead? What would
> > they stand for?
>
> Not really. I didn't really "enjoy" the repurposing of <small>, even if
> it's well done. The humble existence of <small> will make "developers"
> use the element for presentational purposes.
>
> I suggest dumping <u>, <b> and <i> forever, with no regrets.
<u> is currently gone due to lack of use cases, but <b> and <i> are
defined and cover use cases that aren't covered by any other elements at
the moment, so I don't think we should drop them.
USING THE <U> ELEMENT INSTEAD
On Fri, 9 Feb 2007, Anne van Kesteren wrote:
>
> Perhaps <u> can be "reused" for this as Henri suggested
On Sat, 10 Feb 2007, Alexey Feldgendler wrote:
>
> I don't like the idea of reusing an existing presentational element such
> as <u>. Otherwise we'd immediately have the web full of incorrect uses
> of the element.
On Sat, 10 Feb 2007, Jorgen Horstink wrote:
>
> I absolutely second that. Just because of backwards compatibility we
> should not reuse the element.
On Sat, 10 Feb 2007, Keryx Web wrote:
>
> I agree strongly.
>
> Rule number one: Do not confuse users. Therefore it is bad usability to
> underline anything that is not a link.
>
> Rule number two: Do not confuse developers. If developer A starts
> building an app using <u> to mean anything else but "underlined text",
> then developer B comes along, sees all existing markup - gets confused -
> and it will take quite a while for her/him to get up to speed.
On Tue, 6 Feb 2007, Elliotte Harold wrote:
>
> A possibility:
>
> i --> em
> b --> strong
> u --> m
> s --> ????
On Tue, 6 Feb 2007, Henri Sivonen wrote:
>
> FWIW, I've already suggested dropping m and repurposing u for the use
> case.
I think the arguments put forth above against reusing <u> are pretty
convincing.
USING THE <EM> ELEMENT INSTEAD
On Tue, 6 Feb 2007, Charles McCathieNevile wrote:
>
> I fail to see how this is different from an em element... (very loose
> and abused semantics, but I dont see how adding a new element to mess up
> is helpful)
On Wed, 7 Feb 2007, Lachlan Hunt wrote:
>
> <em> is for emphasis, <m> is not. They have very different meanings.
>
> [<mark> doesn't change the meaning of the text], whereas <em> does
> change the meaning of the text.
[I haven't quoted the subthread where this was further explained.]
On Thu, 8 Feb 2007, Charles McCathieNevile wrote:
> > >
> > > Strong provides a strong emphasis, no?
> >
> > Strong denotes importance (see the spec). This is a change from HTML4,
> > but HTML4 didn't really define the difference between emphasis and
> > strong emphasis anyway.
>
> One is stronger than the other. Given that HTML5 allows nesting of
> emphasis, there is not much point in having the strong element as well,
> is there? If em refers to the importance of some text in the context of
> the internal semantics of the text (where m refers to its importance in
> a context not generally derived from its internal semantics), then
> doesn't nesting it convey weighted importance?
>
> It seems to me we could do away with both m and strong here and not lose
> anything (except that strong appears occasionally in the wild).
On Thu, 8 Feb 2007, David Latapie wrote:
>
> I too can't see the point in this <m> element. Semantic highlighting
> already exists (<em> and <strong>, although I personally would prefer
> <em value="+1">, so that we could get <em value="-1"> too and so I
> would not need to use <small> anymore).
On Thu, 8 Feb 2007, David Latapie wrote:
>
> And still don't see any difference with <em> or <strong>. How would you
> pronounce an important word? How would you pronounce a highlighted word?
> Even on the semantic level I can't see the point.
On Fri, 9 Feb 2007, Charles McCathieNevile wrote:
> >
> > The *meaning* is that the content is highlighted.
>
> Or, as the first few definitions I looked at all said, "emphasised".
On Tue, 6 Feb 2007, Mikko Rantalainen wrote:
>
> Perhaps <m> should be considered as a special case of <em>. I would have
> to agree that semantic value of <m> over <em> is next to meaningless. I
> think that one usable definition between <m> and <em> would be that <m>
> is meant for highlighting content for a single user and <em> is meant
> for emphasizing stuff in general. That would limit usage of <m> to
> dynamically generated content only, though, and reserving such a short
> tag for that purpose only doesn't seem reasonable.
>
> I'd rather suggest <em class="mark">, <em class="highlight"> or <em
> role="marker">.
>
> What's the deal with <em>, <strong> and <m> anyway? Why not just define
> that one should use nested <em>s for all the emphasis needed? What
> semantical value have <strong> or <m> to offer over nested <em>s? I hope
> that the answer is not "bolding" and "yellow background".
On Tue, 6 Feb 2007, Alexey Feldgendler wrote:
>
> IMO, the key difference between <m> and <em> is that <m> is intended to
> be placed by somebody or something other than the author of the original
> text. Highlighting search hits is one of the examples (the hits are
> marked by the search engine, not by the author of the text). Another
> example can be quoting someone and using <m> to mark the words of
> particular importance -- not in the cited author's opinion, but rather
> in the context where the quote appears.
>
> Example:
>
> <p>Another example is this sentence: <q>Hard <m>labour</m> has turned
> monkeys into human beings.</q> Note the use of British spelling.</p>
>
> Using <em> in this example wouldn't be appropriate because it would
> imply that "labour" is the most important word in the sentence.
On Wed, 7 Feb 2007, Charles McCathieNevile wrote:
>
> No, it just implies that in the context of this page as delivered, the
> word is emphasised for some reason (which you have to guess from context
> unless you are going with RDFa or some microformat or something).
On Tue, 6 Feb 2007, Leons Petrazickis wrote:
> >
> > IMO, the key difference between <m> and <em> is that <m> is intended
> > to be placed by somebody or something other than the author of the
> > original text.
>
> This distinction may be too fine for people to follow. It's reminiscent
> of the rev VS rel distinction, which few people grasped.
I think the arguments here arguing that there are clear differences
between <em> and <mark> are convincing, enough to at least continue with
the two semantics separate for now.
I've included an example of how <mark> and <em> differ, and others based
on the suggestions quoted above.
USING THE <STRONG> ELEMENT INSTEAD
On Wed, 7 Feb 2007, Jonathan Worent wrote:
>
> Isn't this what <strong> is for? I.E. signifying the contained text is
> somehow more important than the surrounding text but not changing the
> meaning.
>
> | 3.12.5 paragraph 3: "Changing the importance of a
> | piece of text with the strong element does not change
> | the meaning of the sentence."
On Sat, 10 Feb 2007, Jorgen Horstink wrote:
>
> I've been reading the entire discussion now, and I am still not
> completely convinced of the need for the <m> element. In sum the element
> <m> is now explained as highlighting (or marking, I don't care about
> naming) for reference purposes.
>
> Lachlan Hunt explained that 'future reference' can be within weeks (when
> you have to learn an exam for example), days, minutes or immediately
> (google cache). My main concern is; what are we referencing? To my mind
> it is important content. When we highlight articles, we only highlight
> the important pieces of content which are useful to us to generate a
> mental model of the material. When we highlight search keywords, we only
> highlight the important words within the context of the query.
>
> Concluding: to my mind a reference marker implies importance; we only
> highlight what is important for some use by some user. So, to blow the
> flame a little more, why not using a strong element with className
> 'highlight'?
>
> <strong class="highlight">
On Thu, 8 Feb 2007, David Latapie wrote:
>
> What Google is doing is almost good (almost, because <strong> would be
> better here). The highlighted words are the important ones. Highlighting
> could be some kind of <emph value="+3">. Still, we are in the importance
> mindset. And students highlighting whole paragraphs are doing just that.
> Denoting importance.
On Thu, 8 Feb 2007, Jonathan Worent wrote:
>
> No the *meaning" is that the content is important. [...]
>
> By drawing attention to something you indicating that it is important.
On Thu, 8 Feb 2007, David Latapie wrote:
>
> How does it differ from "important"?
I've included an example showing the distinction between importance
(<strong>) and marking for relevance or critique (<mark>).
USING A PREDEFINED CLASS INSTEAD
On Sun, 4 Feb 2007, Sarven Capadisli quoted [heavily edited and reordered]:
>
> <csarven> in that sense, why not `span` with a class?
>
> <zcorpan> span with a class is longer to type :)
>
> <csarven> the 'text' though has no extra meaning. `m` seems to handle a
> presentational issue. like i was wondering, why not `span` with a class
> which can cover numerous cases similar to highlighting
>
> <csarven> as opposed to a predefined class name 'marked' that does just
> [whatever <mark> would do]?
>
> <zcorpan> i don't think <m> is any better than <span class=marked>
> except that the former is shorter
>
> <csarven> but thats introducing a new element for a very narrow usage
> especially where it has no extra meaning. given the idea that the
> reading of the marked text is no different then any other text on the
> page, i fail to see why a new element is necessary where `span` with a
> class can handle this scenario. i also can't come to terms with a new
> element being introduced because `span` with a class is too long in
> comparison to `m`. :)
On Sat, 10 Feb 2007, Keryx Web wrote:
>
> The only current element that can be used instead of <m> is <span>, like
> in <span class="highlight">, <span class="ambigous"> or <span
> class="searchresult">
>
> I think that is good enough. We do not need need the <m> element.
On Sat, 10 Feb 2007, Michel Fortin replied to Jorgen's feedback above:
>
> That's not a bad idea, especially since the biggest use-case for <m>
> seems to be for programatically-inserted highlighting of search terms,
> something that involves absolutely no manual typing and gets little
> benefit from a short element name.
>
> <strong class="highlight">Big brother</strong> is watching.
> or
> <strong class="search-result">Big brother</strong> is watching.
>
> And since the current specification has predefined class names, it could
> simply be added as one.
Since we've removed the predefined class names after receiving
overwhelming feedback against them, I'd rather not go this route.
FEEDBACK IN FAVOUR OF THE ELEMENT OR GIVING USE CASES
On Mon, 7 Nov 2005, ROBO Design wrote:
>
> The <m> element is a really good idea. Up until now developers used
> <span>, <strong>, <b>, <u> or <i> to mark/highlight a part of the text
> in the page.
On Sun, 4 Feb 2007, Sarven Capadisli quoted [edited and reordered]:
>
> <csarven> to me it seems to be more of a presentational issue then
> having a semantic meaning behind it
>
> <zcorpan> there may be different reasons behind why you want to mark or
> highlight a piece of text
>
> <zcorpan> one reason might be to highlight search terms, another may be
> to mark errors in the document, or things you should remember
> specifically
>
> <mpt> Like on those pissantly annoying "Welcome Google user! You
> searched for xyz" pages, where xyz is highlighted
>
> <csarven> in those cases the marked text has no extra meaning other then
> how it would be viewed or interpreted. "highlighting does not change the
> reading of the text when you're reading straight through, it just helps
> you find the bits you should pay attention to." -
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2005-May/003946.html
>
> <zcorpan> i don't think highlighting is presentational
>
> <csarven> how should `m` be treated under Lynx?
>
> <zcorpan> it could have a different text color and you could have a
> shortcut key to jump to the next <m> element
On Wed, 7 Feb 2007, Lachlan Hunt wrote:
>
> <m> is for highlighting text that is of some interest to the reader, but
> it does not alter the meaning of the text itself.
On Thu, 8 Feb 2007, Lachlan Hunt wrote:
>
> Leons Petrazickis wrote:
> >
> > Would you say that <em> is semantic and <m> is presentational, with
> > the difference from <span> is in default formatting? Or is "meaning"
> > not quite the right word - is <m> like a highlighter in revision
> > change tracking, meant to be seen and then discarded?
>
> No, <m> does have semantics. It marks a specific point of interest, as
> you might do with a highlighter, it just doesn't alter the meaning of
> the text itself.
>
> <m> isn't really needed for revision tracking, we have <ins> and <del>
> for that. Though, another use case is that it could be used to mark a
> section that needs to be reviewed and/or edited later. That could be
> particularly useful collaborative editing, like in a wiki. That's often
> what I use the highlighter tool for in MS Word.
On Sat, 10 Feb 2007, Lachlan Hunt wrote:
>
> <m> marks a point of interest for future reference, it does not denote
> importance. Everyone seems to be focussing on the definition of
> highlight meaning emphasis as their argument that it is the same as <em>
> and/or <strong>. However, it's the definition of mark, in particular
> "to identify an item for future reference", that is most relevant, and
> neither <em> nor <strong> fulfil that purpose.
>
> Highlighting, emphasising, underlining, or whatever, is simply the
> mechanism used to identify the item, not the semantic purpose of the
> element itself.
On Sat, 10 Feb 2007, David Latapie wrote:
>
> Of Google cache highlighting has anything to do with future reference?
> Or is the Google cache highlighting example a wrong one?
On Sat, 10 Feb 2007, Lachlan Hunt wrote:
>
> What? I'm not sure I understand, but I think your putting too much
> emphasis on the word "future". The google cache highlights the word as
> a reference for the user, which is exactly what this element is for.
> It doesn't matter whether the user looks at it immediately, in 5
> minutes, tomorrow, or in the distant future; it's there for when the
> user needs it.
On Sat, 10 Feb 2007, Jorgen Horstink wrote:
>
> My problem is; strong and em do draw attention as well don't they? I mean
> normally they do by some sort of mechanism (visual or aural).
On Sat, 10 Feb 2007, Jens Brueckmann wrote:
>
> Sure they do, as do headings, and images.
>
> But the purpose is different. Whereas headings, objects, emphasis etc.
> are usually an integral and static part of a document, the
> M/MARK/HI/FLAG/ATTN elements may change.
On Sat, 10 Feb 2007, Jens Brueckmann replied:
>
> Somehow these points of interest surely have to be presented, but they
> are more than merely presentational.
On Thu, 8 Feb 2007, James Graham wrote:
>
> A marker element certianly has a few use cases: marking syntax
> highlighting e.g. <m class="keyword">def</m> <m
> class="functionName>foo</m>; marking search terms identified on a page,
> marking parts of a document with an external annotation attached (though
> arguably this requires more sophisticated machinary). I believe (though
> many including, I suspect, Hixie, would disagree) the real question is
> whether using <m> rather than span for these use cases enables useful
> features in general purpose UAs (e.g. a common aural styling, a way of
> presenting the information in aggregate form, etc.). I'm strugging to
> see that it does.
On Thu, 8 Feb 2007, David Latapie wrote:
>
> Personally, I use <ins>/<del> a lot on my blog, to show updates. I don't
> know if it supposed to be used that way, but this is an example of use
> outside of traditional, "diff-like" text editing.
>
> You may have a point here. So we would have two dimensions (don't pay
> attention to the words):
> - structure/intrinsic
> - post-authorship/manipulation (like searching)
On Thu, 8 Feb 2007, Martin Atkins wrote:
>
> When I'm giving a speech, I can "highlight" a certain fact that my
> listeners might not have been aware of. (e.g. by saying "Allow me to
> highlight the fact that...")
>
> "highlight" just means "draw attention to", which is exactly what
> Google's cache highlighting is trying to do, and what a student
> highlighting passages in a book is trying to do. The highlighting has no
> effect on the content, it's just a navigation aid.
>
> While the presentation in graphical browsers would likely resemble that
> of paper -- that is, a yellow background -- an aural browser wouldn't
> draw attention to the mark as it is being read. It would hopefully
> instead allow a user to quickly skip between passages containing
> highlighted text much as sighted people do with their eyes as they scan
> over a page with highlighted text.
On Fri, 9 Feb 2007, Lachlan Hunt wrote:
>
> Highlighting with a yellow highlighter, underlinging, circling or
> drawing arrow are all different forms of marking, and could all be
> marked up using the <m> element. It is not restricted to just
> highlighting, though it may be the default presentation.
I've tried to convey the above use cases and examples in the spec.
On Tue, 20 Feb 2007, Gervase Markham wrote:
>
> Where in that data is the basis for this "hi" or "m" element which has
> caused so much discussion recently?
>
> As I skim the flood of mail on that subject, I must confess that it
> seems that, while prospective use cases can be constructed, and fine
> semantic details can be carefully defined, I don't see the web today
> crying out for this element, or having to work around its lack.
>
> The current spec is pretty massive, and contains a lot of good stuff. As
> the above URL shows, we've covered all the major bases. At this stage,
> should we be erring on the side of not increasing the size without an
> excellent, real-world reason?
On Tue, 20 Feb 2007, James Graham wrote:
>
> Since it is designed as an annotation to a page rather than a part of
> the markup, I don't think that it would show up in such a study.
>
> I believe the element was introduced on the basis that there are lots of
> pages that perform some kind of highlighting, especially of others'
> content e.g. Google [1] and Yahoo[2] both use this on their cache pages,
> cam.ac.uk use it on their search pages [3] (as I suspect do any other
> ultraseek based searches) and popular browser addons seem to offer this
> functionality e.g. [4]. I certainly agree that there are sufficient real
> world examples of the proposed semantics to make this element worth
> consideration. Presumably the benefits of a specific element would
> include a better accessibility story and CSS-based customisation of the
> highlighting style.
>
> [1] http://216.239.59.104/search?q=cache:rL_bO-_wkrIJ:www.surtell.com/projects_code_google_highlighting.asp+google+highlighting&hl=en&ct=clnk&cd=3
> [2] http://216.109.125.130/search/cache?p=highlighting&fr=yfp-t-501&toggle=1&ei=UTF-8&vc=&fp_ip=UK&u=en.wikipedia.org/wiki/Syntax_highlighting&w=highlighting&d=RO_V2-xsOTfc&icp=1&.intl=us
> [3] http://web-search.cam.ac.uk/query.html?qt=xray
> [4] http://help.msn.com/resources/targeted/en-US/msnsearchtoolbar_v1/content/SEARCHTBAR_PROC_UseHLV.htm
As James says, there are a number of uses of this element. I think most
uses of them seem to use the "style" attribute directly, which wouldn't
show up, and which, ironically, means it would be even better to provide
an alternative element with specialised UI (if they use it).
On Fri, 9 Feb 2007, Michel Fortin wrote:
>
> Suggestion of an improvement to the spec:
>
> "The m element represents a run of text marked or highlighted for
> reference purposes."
>
> I think adding "for reference purposes" to the current definition helps
> distinguish it from importance (given by <strong>) or stress emphasis
> (given by <em>).
>
> <em> : stress emphasis (changes the meaning)
> <strong> : importance (no change in meaning)
> <m> : reference marker (no change in meaning or importance)
I've added the "for reference purposes" bit to the definition.
On Thu, 8 Feb 2007, Charles McCathieNevile wrote:
>
> If I want to note a word in something someone else said ('"does emphasis
> *change* the meaning", emphasis mine' is what you find in current usage)
> which tag do I use?
On Thu, 8 Feb 2007, Alexey Feldgendler wrote:
>
> IMO this is exactly the use case for <m>.
I've added an example with this.
On Sat, 10 Feb 2007, Jorgen Horstink continued:
>
> Secondly, attention which is caused by a visual, aural or shortcut clue
> sounds like presentational markup to me.
Something is presentational or media-specific if it has only one
presentation -- if it has so many different options, it's not
presentational, almost by definition. :-)
On Thu, 8 Feb 2007, Leons Petrazickis wrote:
>
> One example would be the highlighting of terms in Google Cache:
> <http://209.85.165.104/
> search?q=cache:q_G8YP3E4WwJ:www.worldprimatesafaris.com/+primate+england+madagascar&hl=en&ct=clnk&cd=2&client=opera>
>
> This is Google's current syntax: <b
> style="color:black;background-color:#ffff66">Primate</b>
>
> They are marking the search terms with a highlighter. In an aural
> browser, would these terms be read differently? Perhaps. Does this
> transfer to mobile browsers? Very definitely.
>
> In the Western world, the standard for highlighting is a neon yellow
> background. I submit that a much better name for <m> is <hi> (<hilite>,
> <highlite>, <highlight>). People don't necessarily mark text much -- if
> anything, "mark" implies underlining, circling, and drawing arrows --
> but they do highlight. In university, I often saw students perched with
> their notes and a highlighter, marking important sections. The semantic
> meaning is to draw attention for later review.
>
> The default styling of <hi> would be a neon yellow background. Google's
> choice of #ffff66 could well be suitable.
I've added an issue marker saying the rendering section should say this.
On Thu, 8 Feb 2007, Martin Atkins wrote:
>
> The first thing I tend to do when I load up a Google Cache result is do
> an inline find for one of my search keywords or manually scan the page
> for the yellow text. Some keyboard shortcuts or on-screen buttons for
> skipping back and forth between highlights would be nice.
>
> I can't think of any use-cases for highlighting where this navigation
> aid *wouldn't* be useful. After all, the purpose of highlighting is to
> help your eyes locate important information more quickly; when you
> express it with markup, it can help your browser to help your eyes
> locate important information more quickly in a document that doesn't all
> fit on-screen at once.
>
> As for aural browsers, they too can implement the above navigation aid,
> but allow the user to have the surrounding context read as well so that
> it actually makes some sense, thus avoiding reading the entire document
> just to locate the highlighted text.
On Thu, 8 Feb 2007, David Latapie wrote:
>
> Now this is something I didn't think about when saying "this is just
> like <em>/<strong>". Worth considering.
On Thu, 8 Feb 2007, Alexey Feldgendler wrote:
>
> 1. Offer navigation (next/previous) amonng highlighted regions in the
> document. (Probably only amongh <hi> sharing the same class.)
>
> 2. Turn highligting on/off. Google currently implements it thorough page
> reload (serves a version without highligting), but this could be done
> client-side.
I've added an issue marker suggesting this UI be added to the rendering
secton suggestions.
On Thu, 8 Feb 2007, Nicholas Shanks wrote:
>
> I don't think it would be confusing *provided* it was listed next to
> <ins> and <del> on all those "Learn HTML5 in 24 Hours"
> sites/books/specifications that people will actually learn about it
> from. Doing this would allow 99% of such people to ignore it like they
> currently ignore <ins> and <del>, and therefore won't confuse anyone.
I'm not sure it really belongs in the "Edits" section. There are more use
cases to this element than edits.
ON THE ELEMENT'S NAME
On Wed, 7 Feb 2007, Nicholas Shanks wrote:
>
> On concern that we would be 'wasting' such a short element name for such
> an esoteric usage, why not call it <mark> instead?
On Wed, 7 Feb 2007, Maciej Stachowiak wrote:
>
> I agree, I think the spec should be hesitant to introduce additional
> single-letter element names.
On Sat, 10 Feb 2007, Jens Brueckmann wrote:
>
> It comes to my mind that an appropriate name for this element woud be
> "flag". Putting a flag somewhere in a document does not emphasise but
> draws attention to this part (as in Google or when manually highlighting
> some passages or words in document).
>
> This name best describes its usage and avoids confusion with EM and
> STRONG.
On Sat, 10 Feb 2007, Jorgen Horstink wrote:
>
> To my mind a flag denotes a single point somewhere in the document and
> does not denote a range. So I associate it with the real-world analogy
> of a flag placed somewhere in the document. So I am not an advocate of
> <flag>
On Sat, 10 Feb 2007, Jens Brueckmann wrote:
>
> I am in the process of trying to grasp what highlighting acually is. For
> me it is something different from plain emphasis, although it does sort
> of emphasise a passage of text. So what do you think about something
> along the line of ATTN, meaning "attention"?
On Sat, 10 Feb 2007, David Latapie wrote:
>
> So does a mark in my mind (that may be me). Not that I have any other
> proposal.
On Thu, 8 Feb 2007, David Latapie wrote:
>
> I also agree with Nicholas Shank that single-letter element shall be
> avoided. We have only 26 possibilities, no more. We'd better be very
> careful on this. Even <a> is of doubtful use if we use the XHTML2 idea
> of anchoring anything.
On Thu, 8 Feb 2007, Henri Sivonen wrote:
>
> None of those 26 possibilities are doing anyone any good if we never
> dare to use them.
On Thu, 8 Feb 2007, David H?s?ther wrote:
>
> Agreed. However, I think single-letter names should be used only for
> common element types. "P" is a good example IMO, "M" probably less so.
On Thu, 8 Feb 2007, David Walbert wrote:
>
> I would be less concerned that it's a single letter than that "m" and
> "em" are pronounced identically (in English, and in the other European
> languages I can think of offhand) -- which would be confusing if one
> were trying to explain them aloud, especially given how close they are
> semantically.
On Thu, 8 Feb 2007, David Walbert wrote:
>
> Fine -- you have me here on details -- but they are still similar in the
> languages you noted; they are only one letter apart; and given that the
> tag "em" is short for the English word "emphasis" (and despite any
> phonetic wrangling you might provide is pronounced just like the letter
> m by every English speaker with whom I work) I still say this is a
> problem. Elements so similar in meaning should have unmistakably
> different tags to avoid confusion. Confusion on <em> is bad enough
> already.
On Thu, 8 Feb 2007, David Latapie wrote:
>
> == <hi> is better than <m> ==
> - is m/hi for highlighting? Or for marking future reference? Work notes
> (that I presently format with <tt>) and search highlight (? la Google)
> seem to be grouped together, whereas they are much different.
>
> I much prefer <hi> than <m>, because the former is closer to the use.
> Mark may be understood as *id* (for anchors), as *comments*, or *work
> notes*. For instance:
>
> "HTML was released in 1992 <m>check about the 1989 allegation</m>"
>
> No such misunderstanding with <hi>
On Thu, 8 Feb 2007, Nicholas Shanks wrote:
>
> [...]
>
> [<hi>] seems to impart too much of a visual origin too. Like <b> and <i>
> did. I still think <mark> would be better. It's short enough not to be
> annoying, and long enough to be self explanatory.
On Thu, 8 Feb 2007, David Latapie wrote:
>
> Problem with <mark>/<m> is that its meaning is confusing.
On Sat, 17 Feb 2007, Matthew Raymond wrote:
>
> I've been pondering a use for the <m> element, and I agree that the
> highlighting sematics make the name "hi" a better choice. Also, I think
> it would be most useful in this context:
>
> | <blockquote>
> | XForms is a W3C recommendation.
> | <hi by="Matthew Raymond" title="This comment has no logical basis.">
> | XForms Tiny is does not conflict with XForms, but WF2 does.</hi>
> | </blockquote>
On Sun, 18 Feb 2007, Anne van Kesteren wrote:
>
> FWIW, I think <hi> is a very confusing name. I keep thinking of some
> header until I read it's supposed to replace the <m> element. If this
> element is needed <m> is definitely a better name.
On Sun, 18 Feb 2007, Elliotte Harold wrote:
>
> One objection seems to be to the single character name. Maybe ma or mark
> instead of hi?
On Sun, 18 Feb 2007, David H??s??ther wrote:
>
> The problem I have with both mark and hi(light) as names is that they
> both are verbs in this context. It sounds more like a command to the
> browser: "mark this", "hilight that", instead of being descriptive.
On Mon, 19 Feb 2007, Lachlan Hunt wrote:
>
> I strongly disagree. I think it should remain as <m> or, if people
> really object to using a single letter name (though I don't understand
> why), then <mark> (or similar) would be acceptable.
I've renamed the element <mark>, based on the above feedback.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 17 February 2008 15:08:09 UTC