Seems you're right. Though without the ability to supply inline styling (or at least an id) it might as well be totally disallowed.

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

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.

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.