Previous Entry Share Next Entry
Stylish Wikitext
jducoeur wrote in querki_project
[Warning: while this post isn't too deeply technical, it *does* assume that you know HTML, and have some idea what CSS is.]

As previously mentioned, for the time being Querki isn't letting in any HTML, so I'm taking the initial Markdown syntax and adding enough bits and pieces to do what we need. But that's not just a question of functionality -- we also want to let folks make Spaces that *look* good.

For this, I'm taking advantage of the fact that (a) CSS has grown up to the point where it is not only an option for most styling but actually the best practice in most cases, and (b) CSS doesn't have *nearly* as many Javascript risks as HTML does. So while Querki doesn't allow any HTML for now, it allows nearly all of CSS.

The ability to define stylesheets has been in since the first prototype -- I needed it for the wedding's Save the Date page -- but being able to define the CSS is only half the battle. Just as important is being able to tell the browser when to *use* that CSS. It isn't enough to be able to say "every paragraph should be blue": you need to be able to say, "this is an emphasized bit", and have *that* be what turns blue.

So we're going to follow what seems to be common practice these days, and focus on divs and spans -- if you can declare divs and spans, and say what classes to give them, you can do about 90% of common styling. Once again, we'll enhance the syntax with a new construction, which looks like this:
{{ myClassName : ... some assorted markup ... }}
That is, everything inside of the double-curly-braces (following Querki's usual double-sigil style) has the class "myClassName" attached to it, so any linked CSS for .myClassName will take effect.

The trick here, of course, is that sometimes you just want to do this inline (the span tag), and sometimes you want to do it for blocks (the div tag). I spent a while thinking about that, and decided that the most intuitive approach is to decide based on whether the class declaration is on a line by itself or not, but otherwise leave it identical. That is, this:
blah blah {{ myEm : emphasized }} blah blah
will become a span:
blah blah <span class="myEm">emphasized</span> blah blah
But this:
First paragraph
{{ indentedPara:
Here's some text to indent
Continuing on
will become:
<p>First paragraph</p>
<div class="indentedPara">
<p>Here's some text to indent</p>
<p>Continuing on</p>
That way, you don't even really have to know anything about divs and spans -- the rule is simply that you either put the declaration and the close on lines by themselves, or they have to be contained inside a single paragraph. Other than that, you don't really have to think about it much. (I suspect we can and will write some introductory CSS docs for use in Querki that won't even mention "span" or "div".)

Opinions? Does that seem reasonable? While I can't say that it's perfectly intuitive, it does seem to be easy to remember and use, and decently unobtrusive. It provides a quick and easy way to add a little or a lot of styling to your pages, and while I'm not certain that it's good enough to do absolutely *anything*, it does seem to suffice for all the thought experiments I've come up with so far...

  • 1
Looks reasonable.

If Querki is going to provide a built-in table syntax (like FosWiki does, using | to delimit columns) it would also be good to permit specification of classes for cells (and ideally, rows / columns / tables) - there are things you simply can't do with styling control over the contents of each cell; you need to be able to apply CSS to the table pieces. (And CSS is the nominally best way to do that, though last I checked there were still - and will probably always be - annoying edge cases with certain browsers.)

Hmm -- interesting point. We'll need to discuss this one further, since I don't feel like I understand the problems well enough. I haven't yet come across a wiki table syntax I really *like*, so the question is going to be what sucks least while giving enough power. Going to be very much looking for opinions there...

Simple example: create a table where each cell has 3px padding on left and right, but 0px on top and bottom; where alternating rows have a light gray background (zebra-striping), and where the width of each column is explicitly specified as a % of total table width.

  • 1

Log in

No account? Create an account