<s> vs <del> in HTML - html

So I'm writing a list of todos in HTML. Some of these todos are, well, done.
<h1>TODO</h1>
<ul>
<li>I'm still to be done</li>
<li>I'm done</li>
</ul>
Now I'm wondering what the best way to mark up and style these items. When it's done, I could mark up each item with <s>, which seems much more acceptable these days, as it's 'no longer relevant':
<li><s>I'm done</s></li>
I could go for <del> as, in some sense, the user has edited the list and set this item for removal (kinda):
<li><del>I'm done</del></li>
I could add a class to say what this item means:
<li class="todo done">I'm done</li>
Or some combination of the three. Or something else entirely.
My concerns are accessibility and semantics - I want the markup to convey the meaning of a 'done' item.
What's the best way of doing this?

Both answers are great. s and del are indeed semantic tags so it's good for accessibility. Unfortunately, no browsers surface those tags in the accessibility tree so screen readers cannot convey any information regarding the tags. But you can work around it with CSS. There's a simple blog that talks about the <mark> element, which is also semantic but does not convey info to screen readers but the blog gives a workaround. You can do something similar with s or del. That is, use either s or del but also use CSS to augment the tag for screen reader users.

A class has no semantic meaning, so if accessibility and semantic are important for you, then you have to use del or s.
If you should use s or del is not easy to say. For s the specs have this example:
<p>Buy our Iced Tea and Lemonade!</p>
<p><s>Recommended retail price: $3.99 per bottle</s></p>
<p><strong>Now selling for just $2.99 a bottle!</strong></p>
So you want to show the reader the old information, but also tell the the information is not relevant anymore.
Your TODO example is covered in the specs in the del section 4.6.2 The del element
<h1>To Do</h1>
<ul>
<li>Empty the dishwasher</li>
<li><del datetime="2009-10-11T01:25-07:00">Watch Walter Lewin's lectures</del></li>
<li><del datetime="2009-10-10T23:38-07:00">Download more tracks</del></li>
<li>Buy a printer</li>
</ul>
I think the main difference is that you have more possibilities to add semantic information to del then to s. So del is more about if the information that something was deleted is really important, e.g. the tracking of changes (diff tool), a TODO list, that a part od a specification was removed, ... . And s is some kind of informally additional information.

In plain HTML, class values don’t convey any meaning. You can make use of classes in addition to making use of semantic elements (classes can be useful for CSS, JavaScript, documentation purposes etc.), but you should not use classes instead of semantic elements.
With del and s, you found the two relevant elements that can make sense in this context. Which one to use? It, most likely, doesn’t make a practical difference.
The semantic differences are subtle:
With del, you convey that the content was removed from the document (semantically, it doesn’t matter if the content is still visible or if you visually hide it with CSS). It represents the actual edit to the document.
With s, you convey that the content is no longer relevant.
I guess the purpose why you show the done items can help in making the choice which element to use:
If the todo list could work as well without showing the done items (so showing them has the purpose of tracking changes, or detecting errors), go for del. In theory, a user agent could offer viewing the list at a specific point in time (making use of the datetime attribute), and a default view could only show the actual current content (i.e., without any content in del).
If it’s relevant for the meaning of the todo list to show what has already been done, go for s.
If there is a relevant difference in your case between removing an item (e.g., because it was added by accident, or didn’t make sense etc.) and marking an item as done, then you might want to use del for the former and s for the latter. You can ignore this if there is no relevant difference (e.g., if you would not keep showing items from the former case anyway).
(Side note: If using del, it would make sense to also use ins for adding new todo items.)

Related

Which HTML5 tag to use for emphasizing and discussing a word?

When I want to emphasize or discuss a word that is related to computer code inside a block of normal text, I use the <code> tag. For example:
If you set the variable foo to the value 'bar', then something will happen. If you set foo to any other value, then nothing that's any good will happen.
What is the best semantic HTML5 tag to use to emphasize or discuss a word that is not related to computer code? The way I am thinking of this, it would be (or could be) styled like <code> but not monospace. For example:
The word math is a shortened version of the word mathematics, which has its root in some ancient language that I am not going to research right now.
If you're looking for the tag indicates that its content is being referenced / used as an object for discussion
you can use <dfn> tag. According to MDN:
The HTML Definition element (<dfn>) is used to indicate the term being defined within the context of a definition phrase or sentence.
I just found the updated meaning of the <i> tag for HTML5. From MDN:
The HTML <i> element represents a range of text that is set off from the normal text for some reason. Some examples include technical terms, foreign language phrases, or fictional character thoughts. It is typically displayed in italic type:
Musa is one of two or three genera in the family Musaceae; it includes bananas and plantains.
It is a good idea to use the class attribute to identify why the element is being used, so that if the presentation needs to change at a later date, it can be done selectively with style sheets.
So, this is what I am going to do for this case... <i class="example"> or similar.

What is the purpose of the blockquote attribute ''cite'' in html?

I cannot comprehend this.
Using <cite> text </cite> separately like this just makes the text appear a little bite italic, but i cannot understand the purpose of cite being used as an attribute in blockquote.
For example:
<blockquote cite="http://www.example.com">
For 50 years, WWF has been protecting the future of nature.
</blockquote>
Now, where does this url link appear? Everywhere i look it just says "it's for reference", but reference where?
The link is not showing on the output unless I use href and <p> to make it appear.
So what exactly does this attribute cite does in this case? Where does this url appear?
As per https://www.w3.org/TR/2011/WD-html5-20110525/text-level-semantics.html#attr-q-cite
Content inside a q element must be quoted from another source, whose address, if it has one, may be cited in the cite attribute. The source may be fictional, as when quoting characters in a novel or screenplay.
If the cite attribute is present, it must be a valid URL potentially surrounded by spaces. To obtain the corresponding citation link, the value of the attribute must be resolved relative to the element. User agents should allow users to follow such citation links.
<p>
... or better said by Frank,
<q cite="https://www.goodreads.com/author/show/22302.Frank_Zappa">
So many books, so little time.
</q>
</p>
Since it's not a link (not something a human can follow) it's clearly for SEO purpose, but mostly for indexing. So if you take a quotation from another resource, like another websites page, a cite attribute pointing to the site you've taken that quote from - helps search engines index such resources relations.

are leading and trailing whitespaces ignored in html?

html4 says this:
In order to avoid problems with SGML line break rules and inconsistencies among extant implementations, authors should not rely on user agents to render white space immediately after a start tag or immediately before an end tag. Thus, authors, and in particular authoring tools, should write:
<P>We offer free <A>technical support</A> for subscribers.</P>
and not:
<P>We offer free<A> technical support </A>for subscribers.</P>
and this:
SGML (see [ISO8879], section 7.6.1) specifies that a line break immediately following a start tag must be ignored, as must a line break immediately before an end tag. This applies to all HTML elements without exception.
The following two HTML examples must be rendered identically:
<P>Thomas is watching TV.</P>
<P>
Thomas is watching TV.
</P>
So must the following two examples:
<A>My favorite Website</A>
<A>
My favorite Website
</A>
So, one shouldn't rely on them being ignored or not. What about html5?
UPD Or let us put it this way: can I treat them as being ignored or sometimes they matter (manifest themselves in one way or another)? In which ways, if any?
UPD Um, should I have said I had refactoring in mind...? I'm trying to make templates a little more readable, that's what made me think about it.
Spaces are definitely not ignored in inline tags (i.e. <a>, <span>, <strong>, ...), for instance in this example,
<p>We offer free <a>technical support</a> for subscribers.</p>
<p>We offer free<a> technical support </a>for subscribers.</p>
if you set the CSS to something like this
a { text-decoration: underline; }
you can definitely see the difference.
Sometimes line breaks can produce weird results in inline tags, for example if you write the code like this,
<p>We offer free <a>
technical
support
</a> for subscribers.</p>
it seems to ignore the first line break, but not the last.
Here's a fiddle for both examples: http://jsfiddle.net/Niffler/fnnanru2/
Within block tags (i.e. <p>, <h1>, <div>, ...) spaces as well as line breaks at the beginning or end of the tags should always be ignored (i.e. <p>test</p> should look the same as <p> test </p>).
And as another user wrote in a comment, a line break will generally render the same as a space.
Also, multiple spaces or line breaks or combinations thereof generally get summarized to one space.
SHOULD spaces be ignored by browsers, and ARE spaces ignored by browsers are two totally different questions.
You should not put spaces after the opening tag, even though it (sometimes) works. Because of the documentation on this, the browsers could change to obey that rule without notice.
They shouldn't be rendered the same way, but currently most browsers render
<P>We offer free<a> technical support </a>for subscribers.</P> and
<P>We offer free <a>technical support</a> for subscribers.</P>
the same.
Remember: all of this could change without notice, so I would definitely follow the documentation's rules.

HTML5 semantic element for Tip/Warning/Error pullouts?

I am using XML-safe HTML5 and would like to know the semantic way of documenting extra tip/warning/error boxes (like those often found in technical manuals):
<div class="info-tip" role="contentinfo">
<p><strong>Tip:</strong> Holding the control key when doing this will make life easier.</p>
</div>
Except if possible I would like to use a more appropriate element. I am not even sure if contentinfo is an appropriate choice here.
ADDED: I am after a HTML5 alternative of the <note> element in DITA.
A little context: I will be using stylesheets (both XSLT2 and CSS) to re-format the content for a number of outputs.
The semantically closest one seems to be the <details> element - usage

Correct use of the <small> tag, or how to markup "less important" text

Yet another tag that was given new meaning in HTML5, <small> apparently lives on:
http://www.w3.org/TR/html-markup/small.html#small
The small element represents so-called “fine print” or “small print”,
such as legal disclaimers and caveats.
This unofficial reference seems to take it a little further:
http://html5doctor.com/small-hr-element/
<small> is now for side comments, which are the inline equivalent of
<aside> — content which is not the main focus of the page. A common
example is inline legalese, such as a copyright statement in a page
footer, a disclaimer, or licensing information. It can also be used
for attribution.
I have a list of people I want to display, which includes their real name and nickname. The nickname is sort of an "aside", and I want to style it with lighter text:
<li>Laurence Tureaud <small>(Mr.T)</small></li>
I'll need to do something like this for several sections of the site (people, products, locations), so I'm trying to develop a sensible standard. I know I can use <span class="quiet"> or something like that, but I'm trying to avoid arbitrary class names and use the correct HTML element (if there is one).
Is <small> appropriate for this, or is there another element or markup structure that would be appropriate?
The spec you're looking at is old, you should look at the HTML5 spec:
https://html.spec.whatwg.org/multipage/
I suggest <em> here instead of small:
<p>Laurence Tureaud also called <em>Mr. T</em> is famous for his role
in the tv series A-TEAM.</p>
<small> is not used commonly in an article sentence, but like this:
<footer>
<p>
Search articles about Laurence Tureaud,
<small>or try articles about A-TEAM.</small>
</p>
</footer>
<footer>
<p>
Call the Laurence Tureaud's "life trainer chat line" at
555-1122334455 <small>($1.99 for 1 minute)</small>
</p>
</footer>
Article sentence:
<p>
My job is very interesting and I love it: I work in an office
<small>(123 St. Rome, Italy)</small> with a lot of funny guys that share
my exact interests.
</p>
Personally I would think <small> would not be the correct tag for this as it suggests the text will be physically smaller which doesn't seem to be the case with your example. I think using a <span> would be more appropriate or possible the HTML <aside>. http://dev.w3.org/html5//spec-author-view/the-aside-element.html
You should ask yourself how you would prefer the document to be displayed when style sheets are not applied. Select the markup according to this, instead of scholarly or scholastic theories about “semantic markup” (see my pragmatic guide to HTML).
If smaller size is what you want, then use <small> or <font size=2>. The former is more concise and easier to style, and it is more “resistant” (on some browsers, settings that tell the browser to ignore font sizes specified on web pages do not remove the effect of small). So it’s a rather simple choice.
On the other hand, font size variation inside a line of text is typographically questionable. In printed matter, it is much more often accidental, an error, rather than intentional. Putting something in parentheses is normally a sufficient indication of being somehow secondary