in reply to Re^2: Approved PM markup: div but not span?
in thread Approved PM markup: div but not span?

The lack of a style attribute was also my first thought; however, on reflection, it's really a lack of a style element that's the (bigger) problem.

To elaborate on that, I have a script which generates HTML containing syntax-highlighted code, that looks something like this: 

<pre class="syntax-highlight">
    ...
    <span class="variable">x</span> <span class="operator">=</span> <s
+pan class="string">...
    ...
</pre>

[download]

While I wouldn't want to change, for example, every <span class="string"> instance to, say, <span style="color: #00ff00; background-color: #000000">; I might like to add one simple block like: 

<style>
...
pre.syntax-highlight > span.string {
    color:            #00ff00;
    background-color: #000000;
}
...
</style>

[download]

However, beyond that, which really just shifts the focus of where style is missing from, I do agree with you. id is not an allowed attribute for any allowed element; the lang and dir attributes are only allowed with the blockquote element; and so on.

There may be reasons why things are this way. Perhaps someone from pmdev could provide some feedback.

-- Ken

Replies are listed 'Best First'.
Re^4: Approved PM markup: div but not span?
by ambrus (Abbot) on Jun 28, 2015 at 21:43 UTC

    Very well, since you ask me explicitly. The following is my belief, and need not reflect the gods' official standing.

    The way some attributes are allowed on some elements but not all is inconsistent, yes, but I also didn't find it too important. You may try to petition us with a complete proposal of what attributes to enable in what elements, and then maybe I'll write a patch and maybe some god will apply it. (Update: nuh-uh, sorry, I won't write that patch, for the technical reason (if you're not a pmdev then you might not understand this) that it would have to be a patch to a setting, and I hate setting patches, because the gods keep applying other patches before them, and the perlmonks interface makes it practically impossible to diff and merge setting sanely.)

    But the style attribute, that's disabled deliberately, and we'll never enable it, ever. Don't dream of it. Allowing arbitrary CSS styles on your elements lets a post attempt to take over infrastructure parts of the perlmonks page, such as covering the nodelets or vote buttons by fake elements. The results of a post that tries that could be anything from mischieveous and disrupting to downright evil and destructive. This can even get more powerful in the future as more and more things become possible with CSS in browsers every year. The only way we could support custom styling is if we explicitly filtered custom styles in posts, but I don't think we want to implement that.

    Update: as for syntax highlighting, (a) I would not like to see people control that in their posts, because I personally don't like syntax highlighting and I think it's the viewers that should decide whether they want syntax highlighting, not the poster, so unless you're doing this on your homenode or scratchpad, please just don't do it, and (b) if you want to highlight stuff, you can already do that with classes for which the viewer enables rules in their personal CSS, and (c) if you really want to force highlighted text on the reader to make a point, use the color attribute of the font tag.

[reply]

      Your points about CSS are all valid - no problem.

      I've added a post requesting discussion of allowed HTML: Additions to Approved HTML. What I've posted constitutes what I would have proposed; however, as stated in that post, I think concensus across the Monastery is important. I'll await feedback and then modify as appropriate to form a proposal that most agree on (or can, at least, live with).

      As far as syntax-highlighting is concerned, I was really only providing an example contrasting the style element with the style attribute. The example could just as easily have focussed on some other aspect of styling. The script I mentioned doesn't operate on Perl, it's just written in Perl; if interested, see Syntax-highlight Non-Perl Code for HTML. Given your points about CSS, this is now entirely moot (at least with respect to PerlMonks markup).

      -- Ken

[reply]
[d/l]
[select]

      (c) if you really want to force highlighted text on the reader to make a point, use the color attribute of the font tag.

      But be aware that it might match the background color of users theme ... so at that point why even bother:
      Q: The parts I need help with are highlighted in green
      B: I use the green theme, all the text is already green, who which parts do you need help with?

[reply]

        Yes. And our rules allow you to force even background color on the viewer. Which they can then try to override with CSS or other client-side stuff.

        All that fancy markup is probably useful only

        • on homenodes,
        • in old posts from before spoiler tags that used background color and font color to hide spoilers,
        • and in a few posts of eyepopslikeamosquito (but don't even think of copying him).
        We want to keep supporting some of those uses unless it causes too much problems. If someone wants to make their posts unreadable, there'll always be ways for that, and I don't think there's much point trying to fix that by banning particular attributes unless a particular sort of abuse gets too common.
[reply]
Re^4: Approved PM markup: div but not span?
by Anonymous Monk on Jun 28, 2015 at 21:47 UTC

    If id were allowed, that would allow id collisions, ... could be used for attribution confusion, navigation hazards and other tricky annoyances

    <a name=""> can be used for anchors instead of id

    regarding "style", if it is allowed, it would have to be validated, for things like urls() for XSS attacks, and for overwriting content by id ...

    There are font tags but without a background Hard-coded colors breaking custom CSS settings.

[reply]

      Thanks for your input and, as a general response to your post, please see Additions to Approved HTML.

      I was aware that ids needed to be unique but thought that these would be resolved by Node IDs (assuming authors used unique IDs in their individual nodes); however, upon further consideration, that's probably little more than wishful thinking.

      ambrus (in Re^4: Approved PM markup?) points out issues with using CSS in posts: I've dropped the suggestion of using either the style element or style attributes.

      -- Ken

[reply]
[d/l]
[select]
      If id were allowed, that would allow id collisions, ... could be used for attribution confusion, navigation hazards and other tricky annoyances

      Really? I mean, really, really!?

      I know that lore has it that duplicate ids in html is verboten -- although HTML5 relaxed the specification to:

      The value must be unique amongst all the IDs in the element's home subtree and must contain at least one character

      with duplicates in a given subtree being ignored. -- but is the possibility of duplication -- accidental or deliberate -- so heinous that we must prevent it at all costs?

      Isn't the worst that could happen is that the duplicates might both get styled the same way?

      I could (vaguely) understand the restriction if this place was a JQuery-driven game-show site, like so many are these days; but as-is, and seems likely as-always-will-be, isn't the banning of ids just another piece of over-zealous control-freakery?

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
      I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!
[reply]
        What are you hoping to achieve with an ID?
[reply]

In Section Perl Monks Discussion