17

Stack Exchange supports a restricted subset of HTML. In some ways, this is good; but in others, it's a little too restrictive. It would be nice to have the following:

Elements

Attributes

If you want something that's not on this list, please post an answer, then edit the question. (Please remove that last sentence if this question is marked .)

15
  • <small> could be achieved by using either the <sub> or <sup> tags. Not exactly the same, but it "works".
    – Lino
    Commented Sep 4 at 16:54
  • 5
    @Lino It's also wrong, posing an accessibility issue in multiple ways. See discussion on Allow the <small> tag (2010). (Can someone else write the <small> answer, please? I'm a bit tired.)
    – wizzwizz4
    Commented Sep 4 at 16:59
  • 3
    I think there's a lot of potential value-add for new tags which provide useful functionality, but I think it's also worth keeping in mind that, without equivalent Markdown syntax, I'd wager that they will languish as mostly unused. I don't see any issues with relatively niche features existing only via HTML (like <kbd> and <del> are today), and I realize the line dividing the categories is fuzzy, but for anything to be used consistently by non-power users, it really needs to be Markdown-available, I think. I don't think this should block a new tag, but something to keep in mind probably.
    – zcoop98
    Commented Sep 4 at 17:08
  • 1
    @zcoop98 That's a very good point. Could you chuck that in the "Accessibility considerations" CW answer please, probably above "Further reading"? (Not sure what the heading should be.)
    – wizzwizz4
    Commented Sep 4 at 17:15
  • 1
    Just throwing it out there: in the past two years, my colleagues and I set up a documentation system for the software product we develop, implement and support, solely based on Markdown - no HTML, we have some colleagues who are not that technical. If we need something fancy like a diagram, we include it as an image, and Markdown supports that. I seriously think that every Q&A on the network would be able to manage without HTML, just using Markdown and site-specific formatting. (Even though I do occasionally use HTML tags myself.)
    – Glorfindel Mod
    Commented Sep 4 at 19:25
  • 3
    The main disadvantage of allowing more HTML tags: more room for confusion for editors who don't know about them. I've been a full stack developer (or at least aspiring to be so) for 25 years and have never known <details> or <summary>. Mixing Markdown and HTML can easily lead to content not being rendered as expected (i.e. with raw tags being displayed).
    – Glorfindel Mod
    Commented Sep 4 at 19:34
  • 4
    @Glorfindel That says more about the (atrocious) state of educational materials than about their usefulness. (Jon Skeet thinks it's useful, so that's end-of-story as far as I'm concerned. :-P) You know Stack Snippets, right? Those should be implemented with <details> / <summary> and an <iframe>. I've lost count of the number of web frameworks that implement their own custom version of <details> / <summary> (and even those that roll their own using web features that came out after <details> / <summary>). Editor confusion is a valid point, though.
    – wizzwizz4
    Commented Sep 4 at 19:39
  • My final words (for now): every language feature(-request) starts at -100 points. The mixture of Markdown and HTML that's SE currently uses definitely counts as a language.
    – Glorfindel Mod
    Commented Sep 4 at 19:39
  • I know about Stack Snippets but have used them myself only occasionally. Looks like inclusion of them could generate the appropriate HTML tags in the rendering of the post. We don't want to make users responsible for that themselves.
    – Glorfindel Mod
    Commented Sep 4 at 19:42
  • PPS: how many of those fancy HTML options does Wikipedia support? Next thing you know, users expect to be able to specify color ... ah, the horror ...
    – Glorfindel Mod
    Commented Sep 4 at 19:45
  • @Glorfindel Wikipedia? Most of them, actually. Regarding colour: many of the use-cases in those answers are provided, with fewer accessibility issues / crimes against taste, by semantic HTML elements. And, anecdote: while writing this answer, I tried to include the Orca output by abusing a Stack Snippet. (I would've gotten away with it too, if it weren't for that meddling character limit.)
    – wizzwizz4
    Commented Sep 4 at 21:15
  • 1
    Isn't this a duplicate that has been posted before several times?
    – bad_coder
    Commented Sep 5 at 14:00
  • 1
    The counter side to this is - we are essentially using commonmark with minimal additions rather than a broad subset of additions. We also use two different dialects of markdown on comments and chat. Commented Sep 5 at 15:04
  • 1
    @JourneymanGeek We're actually using a restricted subset of CommonMark in post bodies (with some small extensions like >! and the site-specific stuff). Most of these elements we're asking for are in the CommonMark spec. (So's <script>, which we definitely don't want.)
    – wizzwizz4
    Commented Sep 5 at 15:08

6 Answers 6

16

<details> / <summary>

These elements have many, many uses. See Please add the ability to fold blocks of code in questions and answers (2009).

It would be helpful if <details> supported the open attribute. Ideally boolean-style (<details open>), not XHTML-style (<details open="open">), but I'll take what we can get.

I see no need for the name attribute. Since names are global per-page, and (unlike MathJax) there's no easy way to localise them, that would be a whole other feature request.

7
  • 1
    Please mark your answers here as CW. Commented Sep 4 at 17:00
  • 3
    @ShadowWizard I'm using the first person, and not asking for collaboration on the answers. Per The Future of Community Wiki, I don't think CW is appropriate here. (The question should ideally be Community Wiki, but that has side effects which aren't appropriate, due to the original (now deprecated) conception of CW.)
    – wizzwizz4
    Commented Sep 4 at 17:06
  • 4
    One of the potential uses of details and summary is a replacement for the current spoiler implementation, which is inaccessible to keyboard-only users.
    – Tsundoku
    Commented Sep 5 at 1:55
  • 1
    I mean because it's a poll, where you post all answers. I don't feel comfortable to vote in such a case (either up or down) plus it can trigger serial voting scripts. (Which I want to believe won't run for votes on CW) Commented Sep 5 at 11:59
  • @ShadowWizard That's a good point. At least two sets of upvotes have been discarded by the serial voting script. I'll investigate.
    – wizzwizz4
    Commented Sep 5 at 15:01
  • @ShadowWizard There's a workaround for that. I don't know whether the vote reversal script applies to CW answers: you can get badges from them, so I assume it still does.
    – wizzwizz4
    Commented Sep 5 at 16:37
  • 1
    Another potential use of <details> is to cite and collapse a long text from external link which might get expired or modified in the future.
    – VainMan
    Commented Sep 26 at 0:08
8

Accessibility considerations

Ease for Non-Power Users

Adding new tags may be a great benefit to exprienced users in the know, but for them to be broadly useful, they must also be surfaced in a way that's accessible and easy to use for people unwilling to dig deeply into FAQs and wikis. Otherwise, they'll languish as mostly untouched, regardless of how beneficial they may be.

This might be mitigated by adding new functionality to the editor, or by supporting some level of equivalent Markdown syntax, but wide adoption highly depends on easy, intuitive usage of the new features by the average user.

This shouldn't necessarily stand in the way of adding such new tags, but it should be kept in mind that devoting hours to supporting them probably depends on broad utility.

Further reading

2
  • 2
    Something pretty big that's missing here is if the suggested tags here are accessible to the people writing posts, not just the readers. How do you expect the average person to use these suggested tags? (Will you put them in the formatting toolbar?) How will they know how/when to properly use them? Given that we even had to write a guide for markdown, the markdown experience here already is already pretty inaccessible for writers.
    – Laurel
    Commented Sep 4 at 17:46
  • @Laurel perhaps a larger overhaul of the editor (and onboarding to it) is needed. But I suppose that would be a separate feature-request.
    – A-Tech
    Commented Sep 5 at 10:26
3

<mark>

Sometimes, you're quoting something, and you need to emphasise a particular part of it. On Stack Exchange, <strong> is often used for this purpose.

The quick brown fox jumped over the lazy dog.

(emphasis mine)

However, there's a dedicated HTML element for this! From the WHATWG spec:

The mark element represents a run of text in one document marked or highlighted for reference purposes, due to its relevance in another context. When used in a quotation or other block of text referred to from the prose, it indicates a highlight that was not originally present but which has been added to bring the reader's attention to a part of the text that might not have been considered important by the original author when the block was originally written, but which is now under previously unexpected scrutiny. When used in the main prose of a document, it indicates a part of the document that has been highlighted due to its likely relevance to the user's current activity.

(emphasis mine)

As per MDN docs:

Don't confuse <mark> with the <strong> element; <mark> is used to denote content which has a degree of relevance, while <strong> indicates spans of text of importance.

3

<figure> and <figcaption>

Whenever one inserts a block quote into a post, an awkward matter arises: where to put the attribution? It’s not part of the quote, so it can’t be inside the quote markup. But it should also be distinguished from text surrounding the quote: just dumping the attribution line like any other paragraph looks just as awkward.

Correct functioning of security mechanisms depend critically on the evil bit being set properly. If faulty components do not set the evil bit to 1 when appropriate, firewalls will not be able to do their jobs properly. Similarly, if the bit is set to 1 when it shouldn't be, a denial of service condition may occur.

— RFC 3514 “The Security Flag in the IPv4 Header”, §7 “Security considerations”

As we can see, the author of the RFC clearly understands the importance of setting the “evil bit” properly.

One runs into a similar issue when embedding multiple text files in the post and giving names to each of them.

Having the <figure> and <figcaption> elements available will allow attributions and other captions to be appropriately styled, and put those problems to rest.

Previously requested:

2

lang / <span>

The lang attribute makes the screen reader pronounce stuff right, and compensates for Han unification.

In some cases, we can put lang on an <i> tag, but this is not always correct. Adding <span> would make lang a lot more useful.

1

<ins>

We have <del>. Its counterpart, <ins>, has been maliciously excluded unfairly overlooked. See <del> without <ins>? (2010).

<ins> will probably be abused as underline formatting, but this is relatively minor compared to the terrible things people are already doing for want of semantic HTML elements.

1
  • 3
    It might be additionally styled to tint background green (and <del> might tint it red for symmetry, distinguishing it from <s>) Commented Sep 4 at 19:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .