Tracking changes is a quintessential copyediting feature for comparing versions of content. While we’re used to tracking changes in a word processing document, we actually have HTML elements capable of that. There are a lot of elements that we can use for this process. The main ones we’ll look at are
,
and
. But, as we’ll see, pairing them with other elements — including
,
and custom markup — we can get the same sort of visual tracking changes features as something like Word, Google Docs, or even WordPress.
Different apps have different ways of tracking changes.
Let’s start with the
element.
The
designates text that should be or has been inserted. The verb tense gets a little wonky here because while the
tag is suggesting an edit, it has to have, by virtue of being in the
tag, already been inserted. It’s sorta like saying, “Hey, insert this things that’s technically already there.”
CodePen Embed Fallback
Notice how the browser underlines the inserted text for us. It’s nice to have that sort of visual indication, even if it could be mistaken as an underline using the
element, a link, or the CSS text-decoration
property.
Let’s pair the insertion with the
element, which suggests text that should be or has been deleted.
CodePen Embed Fallback
The browser styles
like a strikethrough (
) element, but they mean different things.
is for content that should be removed/edited out (like that creepy seeming section above) while
is for content that’s no longer true or inaccurate (like the letter writer’s belief that that section would be endearing).
OK, great, so we have these semantic HTML elements and they produce some light visual indicators for content that is either inserted or deleted. But there’s something you might not know about these elements: they accept a cite
attribute that can be used to annotate the change.
cite
takes a properly formatted URL that provides points somewhere to find the reasons why the change was made. That somewhere could even be an anchor on the existing page.
CodePen Embed Fallback
That’s cool, but one issue is that the citation URL isn’t actually visible or clickable. We could use some CSS magic to display it. But even then, it still won’t take you to the citation when clicked… nor can it be copied.
CodePen Embed Fallback
That said, it does make semantically clear what’s part of the edit and what is not. If we wrap
and
in a link (or even the other way around) it still is not clear whether the link is supposed to be part of the edited content or not.
But! There’s a second attribute that
and
both share: datetime
. And this is how we can indicate when an edit was made. Again, this is not immediately available to a user, but it keeps semantically clear what is part of the edit and what isn’t.
CodePen Embed Fallback
HTML’s datetime
format, as a machine readable date and time, requires precision and can thus be a bit, well, cranky, But it’s general tenants aren’t too hard. It’s worth noting though that, while datetime
is used on other elements, such as
, formatting the value in a way that doesn’t include at least a specific day, month, and year on
and
would be problematic, obscuring the date and time of an edit rather than provide clarity.
We can make things clearer with a little more CSS magic. For example, we can reveal the datetime
value on hover:
CodePen Embed Fallback
Checkboxes work too:
CodePen Embed Fallback
But good editing is far more than simply adding and deleting content. It’s asking questions and figuring out what the heck the author intended. (For me personally, it’s also about saving me from embarrassing spellling and grammar mistooks).
So, meet the
element.
points out text of special interest to the reader. It usually renders as a yellow background behind the content.
CodePen Embed Fallback
If you’re the editor and want to write a note to the writer (let’s name that person Stanley Meagher) with suggestions to make Stanly’s letter more awesome (or less creepy, at the very least) and that note is large enough to warrant flow content (i.e. block level elements), then the note can be an
element.
<aside class="note">Mr. Meagher, I highly recommend you remove this list of preferred cheeses and replace it with things you love about the woman you are writing to. While I'm sure there are many people for whom your list would be interesting if not welcome, that list rarely includes a romantic interest in the midst of your profession of love. Though, honestly, if she is as perfect for you as you believe, it may be the exact thing you need to test that theory.</aside>
But often you’ll want to do something inline in order to point something out or make a comment about sentence structure or word choice. Unfortunately there’s no baked in way to do that in HTML, but with a little ingenuity and some CSS you can add a note.
<span class="note">Cheesecake isn't really a "cheese"</span>
The
element — long an anathema to web developers for fear of confusion with a link — does actually have a use (I know, I was surprised too). It can be used to point out a misspelling (apparently squiggly and red underlines aren’t a standard browser rendering feature). It should still not be used anywhere it might be confused with an actual link and, when used, it definitely should use a color that distinguishes it from links. Red color may be appropriate to indicate an error.
<p>Please, <u>Lura</u> tell me your answer. Will you wear my mathlete letter jacket?</p>
As we’ve seen throughout this article, the browser’s default styles for the elements we’ve covered so far are certainly helpful but can also be confusing since they are barely distinguishable from other types of content. If a user does not know that the document is showing edits, then the styling may be misconstrued or misunderstood by the user. I’d therefore suggest some additional or alternate styles to help make it clear what’s going on.
ins {
padding: 0 0.125em;
text-decoration: none;
background-color: lightgreen
}
del {
padding: 0 0.125em;
text-decoration: none;
background-color: pink;
}
mark {
padding: 0 0.125em;
}
.note {
padding: 0 0.125em;
background-color: lightblue;
}
aside.note {
padding: 0.5em 1em;
}
u {
text-decoration: none;
border-bottom: 3px red dashed;
}
CodePen Embed Fallback
I ask myself the same question every time I learn something new in HTML: How can I needlessly animate this?
It would be great if we could fade up the changes so that when you clicked a checkbox the edits would fade in as well.
CodePen Embed Fallback
The notes and text in
tags can’t be faded in with CSS the same way that background colors and paddings can. Also, display: none results in no fading at all. Everything pops back in place, including the backgrounds. But using a combining the CSS visibility
property with a set height
and width
value of 0 allows the backgrounds to smoothly fade in.
And there you have it: specifications and a few strategies for keeping track of edits on the web (plus an excellent example of how not to write a love letter (or, perhaps, how to write one so perfect that responding positively to it is a sign you’re soulmates).
The post Copyediting with Semantic HTML appeared first on CSS-Tricks .
You can support CSS-Tricks by being an MVP Supporter .