Re: Additions to Approved HTML

Code

Anonymous has already told a bit about the state of code tags. While it would be nice to permit code snippets that can have characters that aren't in cp1252, it's not so easy.

The main problem is that the content of all nodes is submitted and stored cp1252-encoded, so you cannot represent characters literally in the perlmonks-HTML source code of a node unless they have an encoding in cp1252. If perlmonks wanted to allow that the raw text of some nodes is encoded as utf-8, we'd have to change a lot of code, and this is not a priority. (Note that perlmonks nodes were officially encoded as iso-8859-1 until 2008-31, but as cp1252 since that. This caused few user-visible changes, except in the XML tickers. See Tidings.)

In theory, we could add a tag that lets you put code snippets into a node that can contain any character, but then you couldn't just represent all those characters literally in the perlmonks-HTML source of your node, but would have to somehow encode them on your side. This is already partly possible if you don't insist on actually using specific code tags, but just write ordinary text (or monospaced text) and ampersand-encode some characters. In fact, some browsers already encode characters that aren't in cp1252 that way, because they can't encode those characters to cp1252 but the submission form on the website asks them to. You then have to manually encode the punctuation characters ><&[] and whitespace as well. The drawback is that in this case people can't use the "download code" option to download just the code part of your node.

The other alternative for a poster is to link to an off-site web resource. None of these is perfect, but there's certainly no easy solution.

WBR

For information about the WBR element, please see http://www.w3.org/html/wg/drafts/html/master/semantics.html#the-wbr-element and https://developer.mozilla.org/en-US/docs/Web/HTML/Element/wbr. I don't see the need to forbid it once we've already allowed, but then I also didn't see why we had to forbid Q tags.

Spoiler

If you want to allow a title attribute for spoilers, please tell us precisely how its value would be used in the formatted spoiler, in all combinations of the five possible values of the "Render <spoiler> as" setting of Display Settings, and whether the spoiler is expanded or not, and then convince us why that change would be worth over the current state of not being able to specify a title. I'm not saying I'm completely against this, because spoiler tags on some web forums do have a title that's useful, but if you want a change, please give precise proposlas or we won't change anything.

Other attributes

I have no big problem with permitting the class, title, dir, lang attributes in posts for any element, given that we already permit these in some elements. The only problem these could cause IMO is that an unclosed tag with a dir or lang element could mess up the formatting of the rest of the page. (Unclosed tags can get into the formatted output with some display settings that some old users may still have.) However, unclosed tags can cause problems in lots of other ways, and you could already add these tags to a blockquote tag, so the situation wouldn't be any worse. For this reason, however, I would recommend that dir and lang attributes are not added to the PerlMonks Approved Chatter HTML Tags unless there is a compelling use case for them.

Comment on Re: Additions to Approved HTML Download Code

Replies are listed 'Best First'.

Re^2: Additions to Approved HTML
by kcott (Archbishop) on Jun 29, 2015 at 19:03 UTC

OK, thanks. Here's where I see the proposal to be (in terms of what can be done now and what will receive approval from one of the gods):

Code: No action: Remove from proposal.
WBR: Action point: A small documentation change to Perl Monks Approved HTML tags. [See below.]
Spoiler: No action: This never was part of the proposal ("I'm not suggesting any changes to the remaining non-standard elements: <spoiler> and <readmore>.").
Other attributes: Action point: Add the attributes class, dir, lang and title to the elements as described in the table in my OP.

For the wbr documentation change, this might save yourself (or someone else in pmdev) a bit of work.

In the table, change

wbr
[download]

wbr<sup>5</sup>
[download]

Add to the end of the existing notes:

<p>
<sup>5</sup>The <c>wbr</c> element provides a <em>suggested</em> 
wrapping point for long strings that contain no whitespace. See 
[http://www.w3.org/html/wg/drafts/html/master/semantics.html#the-wbr-e
+lement|W3C: The <c>wbr</c> element] 
for more information.
</p>
[download]

Obviously, I don't have access to the code for adding attributes to the existing elements; however, if that turns out to be a lot of work (due to the large number of element/attribute combinations), and you'd like an extra pair of hands, just let me know.

-- Ken

[reply]
[d/l]
[select]


go ahead... be a heretic
	PerlMonks