CommYou 0.1.7 released

[jducoeur]

Instead of posting the detailed release notes here, just the high concepts:

This was the "textual self-expression" release. Up until now, CommYou was cutting all HTML off at the knees, for safety reasons. Now, it's whitelisting a lot of the basic HTML tags. It's not *quite* up to LJ's level yet, mostly in that it only allows very simple forms of those tags, but it's probably enough for 99% of actual use. So things will stop being quite so plain-looking.

Also: it now includes a simple wikitext engine. There are a bunch of very common idioms that I've always wished were a little easier to simply type, being a text-focused kind of guy. So a lot of the common things like bold, strikethrough, quoting, links and lists now have reasonably intuitive wikitext versions. (For example, doing *this* would render "this" as bold: this.)

Eventually I'll probably implement a WYSIWYG editor, for those who prefer that. But this release should help a lot...

Comments

[metahacker.livejournal.com]

But what if I *want* _this_?

It's funny...my eyes read *this* easier than this -- bold weighting just isn't markéd enough, and I have years of training in flat text...

[jducoeur]

My initial reaction was to mention that there is already a story (not yet implemented, but in the plans) to turn off the post-processing at the request of the creator.

But it occurs to me that that's not quite what you're asking for -- you really want a *read*-time control. I think that's also possible, but a bit further down the story list: that's probably best handled by the user-managed CSS filter that's in the plans. In theory, that could be used to change the way things like bold render, to be text-based instead of font-based. (In practice, it's an interesting issue that I've never seen come up -- I'll need to see if it's actually entirely possible.)

I'll have to think about this one -- it's an interesting viewpoint. It's analogous to enough other potential stories that it ought to be possible eventually...

[metahacker.livejournal.com]

Actually I was just thinking about turning it off for authoring, a la your top story...

...but now you've got me thinking about a custom stylesheet (using element:before and stuff) for viewing *all* web pages. :-P

[jducoeur]

Actually I was just thinking about turning it off for authoring, a la your top story...

Okay, *that* is on the list, not too far down. (learnedax suggested it as part of the original wikitext discussion.)

I'm still chewing on the best way to handle the display aspect. It would actually be relatively easy to just show the "raw" input -- I'm going to need to start saving that soon anyway, in order to support editing -- but there are security problems with that, so it couldn't be done naively. And you do need *some* post-processing -- at the least, the newline-to-br transform is essential if things are going to be readable.

It's actually a pretty interesting problem, on reflection. The wikitext, like the HTML result, is essentially a markup language, and both are ways of indicating intent. In principle, the best way to deal with this is the CSS route: we boil the text into the most common format (HTML), and then use stylesheets to express it. In practice, it'll be interesting to see how well that actually works.

One thing I'll need to think about for the medium term: whether to keep translating to simple tags like <b>. It would be more modern Web style to instead translate to custom classes that simply *look* bold through a stylesheet. I was thinking about that anyway, but this strengthens that idea -- if the wikitext translated into custom styles, it would allow you to specify the formatting of the wikitext *separately* from that of the explicit HTML, which might be a win. And now that the wikitext core is written, switching to a style-based approach would be fairly easy. Hmm...