Contents
Borders on tables
Current proposal: Tables whose rows end in another {|
|} character (which would normally simply be ignored) will have a border, those created in {|
|- |blah |bleh |} style without a trailing {|
|} won't. The first line is authoritative.
Tables with corders currently produce just a grey background. Tarquin is working on the CSS...
The CSS classes are now:
- "paratable" no border
- "paratable-border"
Mychaeel: I actually think that most tables don't need any borders at all and actually look better without (like the one on Font Colors, for instance).
Tarquin: Maybe we can do something discreet, like pale grey borders, or white borders & pale grey background. Just something to help the eye follow the lines of the table.
Mychaeel: See 116120.
Forum links
Mychaeel: Provide forum links for every page (to a pre-filled "New Thread" window or an existing thread). See 116130.
See Wiki Development
Header numbering
Would it be difficult to implement heading numering thus:
=== # header ===
Mychaeel: Not at all (since headers only take inline markup anyway). That's actually a nifty idea. Create a numbering along the lines of 1, 1.1, 1.2, 1.2.1 starting at header level 2?
Tarquin: I hadn't thought of multi-level, but yes, that could be useful. Just for the headers that request it with the #. Alternatively, the nesting could left to the user with #, ##, ### etc.
WheatPuppet: Okay, I'm seeing 1.1, 1.2, 1.3, how do you get a 2.1 or a 2.5.1?
Mychaeel: By adding the corresponding numbered headings... like in a word processor. See the Sandbox.
Tarquin says
Tarquin: Oops! Just saw in UnrealEd Viewport that there's a patch I applied to UMW I forgot to mention for Wookee support: arbitrary counters – see http://www.usemod.com/cgi-bin/wiki.pl?WikiPatches/SeparateCounters
Mychaeel replies
Mychaeel: Interesting and very easy to implement in Wookee, but – what for, exactly? (I'm just curious.)
Tarquin concedes
Tarquin: Erm, for being lazy when numbering headers... hm. I see your point.
Mychaeel announces
Mychaeel: Heading numbering works now. Automatically generated table of contents is just a step away (see the Wookee Playground).
Tarquin jubilantly says
wahey!!!
Table of contents
Mychaeel: I've had the idea of automatically generating a table of contents for each page according to the headers found there, linked to the corresponding parts of the page. That table of contents could either be displayed in a floating block in the page's upper-right corner, or be displayed in a drop-down box, or (with the help of some DHTML) pop up menu-like. What do you think?
Mychaeel: See 116360.
Mychaeel: They're in and up and working – even on all browsers I'm aware of (and despite the fact that one thing I'm relying on isn't part of any standard [yet] – offsetParent, offsetLeft and related attributes are supported by Mozilla, Internet Explorer and Opera though). Select the Chilled Blue style to see the Quick Navigation menu, and check the forum thread for information how to enable the other skins as well.
Tarquin: this is a minor point which I don't expect there is a fix for, nor should we bother trying to find one: they don't work on MacIE or OmniWeb, but Mac Mozilla is fine :) (but Mac Mozilla fails on other stuff, like wheel mice, and command-key shortcuts... sigh)
Arrows for properties
Latest consensus on Guidelines On Technical Names was to use "Advanced -> bStatic" for prop names. Mychaeel suggested that the arrow pair could be parsed into an image. The following HTML entity could also be an option, thus:
- Advanced → bStatic
Mychaeel: Very nice! I'm going to implement that (maybe for ⇒ (⇒ =>) and ⇔ (⇔ <=>) and all the other nice arrows from Wiki Markup as well...).
Mychaeel: Any idea for replacing >> (for class paths)?
Wormbo: Ah be careful with the =>= arrows. I get little squares instead of them. (IE and Opera)
Tarquin: On my Win98, → works in all 3 browsers. On my Win98, ⇒ and ⇔ produce "?" in Mo, and boxes in IE and Opera
Mychaeel: What a pity... guess it'll just be ->- then. :-/ (All three arrows work fine on Windows 2000 here, by the way.) No thoughts on >>?
Mychaeel: Done. ->- yields a nice -> now.
Wormbo: You could replace >> with » (»), but it doesn't look that good.
Whitespace paragraphs
Tarquin: This isn't a bug, so much as user sloppiness that Wookee could turn a blind eye to. A single stray space character on a line creates a whitespace paragraph. It might be an idea to only create on if there are characters following the initial whitespace.
Signing & Thread mode
Tarquin: I'll take another look at the hack I impleneted which transformed three "~" characters into a user name. At the moment it just adds the user name, with a dash before it if used at the end of a line.
A possible extension would be if used at the start of a paragraph, it could create a header rule, the user name in bold, and a ":". This would greatly simplify thread mode.
Mychaeel: That's not Wookee-related. That has to be done statically, before the page is saved. – If you include the colon, please make it part of the boldfaced text. It looks so ugly otherwise...
Tarquin: Indeed. But from the POV of the user it's part of markup. Colon in boldface: will do.
Mychaeel: Alright. :) I just wondered why you put this item in Wookee/Suggestions, but I think there's indeed currently no other place that's better suited for stuff like that. – Whether the
is really necessary I don't know. I actually like the more compact way we're discussing in here better.
Tarquin: Done. I thought the same thing about the headers, so they're not included. If a writer has no username, they are parsed as "Guest".
Mychaeel: Let's see. – Not bad. Whether it be a ---- (without a trailing space, my personal favorite) or a ---- (your choice) is a matter of personal preference, I suppose, and I can live with that. What about linking non-Guest usernames though instead of putting them in italics? Mychaeel
Tarquin: without the trailing space the ---- won't be parsed into – . End of line signoff is done. – Tarquin
Mychaeel: Believe me, it will. I coded it, I ought to know. :) →yadda→ –yoo– – Mychaeel
Tarquin: OK, in that case I'll change it so there's no space between the – and the name. Egad, you've found a way to escape it!!! I was trying to code a way to use a backslash in front, which worked, but then of course the marrkup parser needs to be told to ignore the backslash if it finds it.... Space removed –Tarquin
Mychaeel: An m-dash instead of the n-dash would be nifty. :-) – About escaping: Don't you think it'd be sufficient to substitute ~~~ solely at paragraph starts and ends? That'd make escaping unnecessary in most cases and keep the feature anyway.
Tarquin: both changes made. ~~~ now unparsed. →Tarquin
Run-in headers
Tarquin: This is a formatting style demonstrated here that I've seen people use. It's possible to create this with CSS with display:run-in. I haven't tested all browsers, but if it works, we could provide it as a formatting option. Then again, it might be featuritis. Something like one of:
==: heading == == heading ==:
Mychaeel: I don't understand. How's that supposed to look?
Tarquin: Like the example that you changed.... ;) Like the "A few tips:" bit on UT Troubleshooting FAQ. I'm not sure it's useful, it just occured to me when I saw that page, as I've been reading up on the CSS display property lately.
Mychaeel: Hmm... well, if it can be done in CSS, why not. Since the trailing ---- is optional anyway for headings in Wookee, I think ==heading : == would do better for the syntax though...
Tarquin: OK. I'll make some test styles.
Mychaeel: Thinking of it, ===heading=== (without the trailing ----) might even be better...
Tarquin: display:run-in only works with Opera. Sigh.
Boldface Markup
Mychaeel: Currently only ... produces boldface text. How about introducing *...* as an alternative? (Perhaps requiring a match on /\*\S/ for the start tag and /\S\*/ for the end tag?)
Tarquin: wouldn't that create problems with bullet lines? I'm not sure we need a shorthand for bold, but how about _bold_ ?
Mychaeel: Paragraph markup has precedence over character markup, so the only thing you wouldn't be able to do is starting a paragraph with *boldfaced* text. Having this markup for *boldfaced* text means typing four characters less than boldfaced text...
Wormbo: That looks more like _underlined_. Introducing *bold* would also allow to format text as *bold and italic*. (or *italic and bold* – whatever you like better :D)
Mychaeel: Introducing _underlined_ wouldn't be a technical problem either (I'd rather not do it though – underlined text on a web page is confusing if it's not a link), but seeing constructions like *bold and italic* I'm not so sure about the whole approach at all anymore... Wiki markup should be logical, not physical, I believe.
Floating Images
Mychaeel: Please see 118820 for a suggestion about how to handle floating images (@left@imageid and @right@imageid) and a request for comments.
Mychaeel: Floating images are now (much more neatly) implemented by means of HTML tables. Internet Explorer's speshul notion of CSS gave me some trouble, but I was able to devise a workaround that is, at least, still okay with CSS-compliant browsers.
InterWiki
Tarquin: just realised: I can't install InterWiki, because links are now handled by Wookee... I'm not sure if there is an established format for this on wikis that use Freelinks... I guess [[Wikipedia:some page]]<nowiki> would be logical. BTW, does Wookee support CamelCase links? Not that I'm thinking we should use them. :) '''Mychaeel:''' I ignored CamelCase links when I implemented the link formatter. Wouldn't be hard to refit though. – Page links are only partly handled by Wookee; it still calls <code>UseModWiki::FreeToNormal</code> to convert them to actual HTML links. '''Tarquin:''' Interwiki now installed. I'll refactor this section to some other page to explain how to use it. ==ColSpan == Just an idea for rowspan markup: | cell one |_ spans two rows | cell 3 | row 2 cell one | <- should there be a second "|" to indicate the spanned cell? HTML syntax would say no, so this is row 2 cell 3