I could have used some of these semantic HTML elements in some comments in the forum and I think they could be useful to others:

  • ins (inserted text, companion of "del" which is currently allowed)
  • abbr (an abbreviation, full text in the title attribute)
  • acronym (an acronym, full text in the title attribute)
  • kbd (indicating typed in text)

Full reference at: http://www.w3.org/TR/html4/struct/text.html

This may need some tweaking of CSS for presentation though...

Regards,

Christian Larsen

Comments

drumm’s picture

+1 for abbr and acronym. I'd use those. The others are useful, but I'm not going to say I'll use them much.

webchick’s picture

I'd like to see <strike> too, personally.

webchick’s picture

Aw, <strike> is deprecated :(

Tiburón’s picture

@webchick: strike got deprecated in favor of the ins/del pair and the use of CSS (where ins/del semantics does not apply). Basically just use del where you would want strike to signify (deleted) striked out content :-).

I would expect to see the same happen to b and i overtime as they are presentational elements with no semantic meaning.

Ok, the part about no semantic meaning is arguable but screen readers ignore b and i and modulate the voice of the speech engine when hitting strong and em (as well as with other semantic elements like headings).

sepeck’s picture

do we have styling in the css to account for these ads?

Tiburón’s picture

StatusFileSize
new1.8 KB

The browsers have standard rendering for these HTML elements though they varies a little from browser to browser:

Test of ins, del, kbd, abbr, acronym.

What is rendered:

  • ins get underline (the same undeline as a elements)
  • del get line-through
  • kbd get monospace font like courier (think pre, code, ... but inline rather than block)
  • abbr get a dotted bottom border (though Safari render this as normal text)
  • acronym get dotted bottom border (though Safari render this as normal text, while Opera troughs small-caps into the mix)

Basically there is no pressing need to modify CSS at*.d.o since there generally are some support for these HTML elements in browsers in regards of visual rendering.

But for consistency between browsers a little hacking should be done.

The following code restates some default rendering for consistency across browsers as well as adding a little color to the mix. The use of color should in this case not be an accessibility issue since other visual cues are available (text-decoration, font-family, border-bottom).

  <style type="text/css" media="screen">
    ins {
        background-color: #EFE; /* a slightly green background */
        text-decoration: underline;
      }
    del {
        background-color: #FEE; /* a slightly red background */
        text-decoration: line-through;
      }
    kbd {
        background-color: #EEE; /* a slightly grey background */
        font-family: monospace;
      } 
    abbr {
        font-variant: normal;
        border-bottom: 1px dotted #999;
        cursor: help; /* change cursor to signal that help/info is available */
      }
    acronym {
        font-variant: small-caps;
        border-bottom: 1px dotted #999;
        cursor: help; /* change cursor to signal that help/info is available */
      }
  </style>

See attached sample HTML file for the above CSS in action.

Tiburón’s picture

Status: Active » Needs work

@sepeck: Sorry. I forgot to answer your Q in my previous post so here goes:

I do not see any styling for these HTML elements in the stylesheet currently supplied by d.o (I did a quick search with FireBug). I have not investigated the rest of *.d.o.

As I state above there are default styling in place at the browser level though not a consistent rendering across browsers thus the code snippet in my previous post...

I change the status from "Active" to "patch (code needs work)" since there is code ready but it is neither reviewed or in patch form at this time.

Also, maybe this should be added to core? If there are interest I will open a similar feature request for core...

silverwing’s picture

Webmaster Issue Queue Cleanup - 2.5 year old issue (!)

So is abbr, ins and kbd something that should be added to the filter? Acronym is available for Documentation (and I'll assume Full HTML).

Tiburón’s picture

I still think that the listed HTML elements should be added to the filter as allowed. They can be quite handy when illustrating changes to code and text snippets.

Also the CSS in #6 should likewise be considered added to the current *.d.o theme and for the d.o redesign.

Incidental the sample file attached to #6 is no longer accessible. Maybe a lingering problem after the upgrade to D6 on d.o?

Regards

Christian Larsen

silverwing’s picture

tvn’s picture

Status: Needs work » Closed (won't fix)

Closing old issues. Please re-open if necessary.