Sforzando: Did LJ just strip out custom styling in comments?

[silveradept]

Leave it to the RP communities to notice, because they're usually the people who stretch the platform as far as it will go to achieve the desired ends, but a little while ago, someone noticed that their comments weren't showing inline style any more. For most standard commentaries, that's not a total loss, as we tend to be agnostic about most aspects of our text, but if one were, say,

• trying to represent more than one person in a comment,


• were the kind of journal where there were multiple possible aspects talking in the same comment,


• were representing inner thoughts and outer speech,


• or were otherwise trying to make something of literary quality or that required customized sizes and fonts to get the point across,

then not being able to style the comment pretty well blows up your ability to do so. Workarounds can be made, sure, but they're usually fairly clunky. (Not to mention that everyone's imagination of flowing handwriting or a musical tone of voice is different.)

A comment thread in the news post is active, asking about this development, as is a Support request. There's a probability that someone was poking around in the code and this is an unanticipated consequence of it, and they'll track down the bug and squish it. It could be that they want to move their pages up to a more strict standard and removing inline style is part of that move.

It would be worthwhile to ask if, in the case of customized styles available for paid accounts, whether the stylesheet that users can access for a journal extends into any comments they will receive on that post, making it possible, although tedious, to replicate style-in-comments using custom tags and/or class containers that would have to be distributed to participants.

It might also be worthwhile to test out in Dreamwidth to see if they have retained those elements in comments, to see if their customized stylesheets will allow for the tedious replication, and to ask whether they have any intent to remove such options from comments any time in the future.

No need for panic or anger yet, as there's no indications as of this posting that this is a deliberate move on anyone's part or a hostile one. And it might inspire me to go poking around and see just what kind of customization is truly possible - Tabula Rasa, if it is exactly so, might end up become a style of choice for those people who need to have style control over all their elements and comments.

Comments

[hybridelephant.myopenid.com]

i haven't noticed styling on comments for a while, but i let my paid account expire a couple years ago, and i think that may have been part of it.

[krinndnz.livejournal.com]

I still really want to be able to say "never ever show me other people's styles unless I opt in" - some people use bloody unreadable journal styles. >.

[silveradept]

I think what you're supposed to be thankful for is the style=light option that you can append on manually if you must to such things. Or the style=mine option if your style is correct and non-eye-searing. Shouldn't have been too hard, though, for them to implement something into your session that overrides anyone else's style and imposes either the light style or your style.

[rimspace.livejournal.com]

My guess is that this is an overenthusiastic security fix. What most people don't know is that the style="" attribute on html entities can be abused to insert dynamic content - essentially, you can craft a style that invokes javascript functions, or worse. This makes style="" a little considered, but surprisingly flexible, pathway for cross-site scripting attacks and other exploits. It's an utterly braindead 'feature', and no sane web dev I know can present a remotely sensible justification for its existence, but it is there, and it causes all sorts of headaches for people who allow user-entered html.

It's possible to strip it while still allowing normal stylesheet content, but doing it can be tricky. I'm suspecting they just decided "none of it" rather than "how the hell to we write something to correctly validate this shit?". It might also be somehow tied to the farcebook integration trainwreck...

'course, I could be wrong about the motivation, and it's just some muppet who broke the code...

[silveradept]

Always possible. I had wondered whether there were security risks involved with that kind of code, and that someone would be able to do bad stuff with it. Is there any sort of sane way of offering an alternative that would allow the styling that wouldn't also allow for the vulnerabilities?

[rimspace.livejournal.com]

The same degree of control that using style="" provides? Not really.

Basically, the problem is this:

• inline style allows the user to include any CSS property they want, giving them essentially complete control over the styled content. This includes fairly innocuous things like font size, style, colour and so on, right through to positioning on the page. It also permits the use of cross-site content loading, and the horrible dynamic CSS system, which is where the big security issue lies.


• Cleaning up the contents of the style="" attribute is possible, and indeed doable (I've had to do it), but highly non-trivial. There are currently over 100 standard CSS properties, and Azathoth only knows how many non-standard ones. Even assuming you only permit standard CSS1 or 2 properties, you need to check that the values in the style are valid and correct - it's a lot of work.


• Offering a different mechanism, say letting users use some kind of a [style ...]content[/style] tag, runs into the problem that you either highly constrain the supported properties (which involves checking and validation), or you end up in the same boat - so alternatives don't really buy you anything, if you're letting the user specify properties by hand: you may as well just validate the standard style="" in that case.


• Offering a set of tags akin to BBcode works, and there are well-established mechanisms to process such tags, but as you probably know the range of features offered by BBcode is drastically less than style="".

So, they either need to do proper, thorough checks on the style, replace it with a far more constrained system, or just drop it entirely.

But then, thinking about this more, and the fact that they've also killed <font> and chums, I'm wondering if this isn't more towards the farcebook integration end of the possibilities than the security end - the security problem is not easy, but it's recognised and there are methods to address it, so it's either laziness, muppetry, or something to do with the new connectors I'd guess...

[silveradept]

I suppose it's a good thing that you're following the logic train that I had, just with actual evidence to back it up. I'm guessing that the cross-site posting tools probably wouldn't want rogue tags or styles, just so they don't have to deal with them at all in parsing for the other sites?

[foxfirefey]

LiveJournal has had, for a very long time, user content filters to prevent JS in CSS and other exploits. I hope they haven't discovered a new one, but it's definitely been pretty fire tested for years. I'm not positive, but I wouldn't be surprised if it's more about CSS exploits that somehow break pages than a really serious exploit.