From: Tara S. <te...@cl...> - 2001-11-15 11:52:27
|
I can't find my way in the code to do this, but this is how nested lists=20 could be made standards-compliant. First, this is what a nested list should look like (hope you can see the=20 tags): <ul> <li>first</li> <li>second <ul> <li>first nested</li> <li>second nested</li> </ul></li> <li>third</li> <li>last</li> </ul> you can see that the inner <ul> simply needs to be inserted inside an=20 existing (closed) list item. One way to do this would be (it's probably similar to some extent to=20 what is currently being done in 1.3): On meeting the first * (or #), replace it with <ul><li>. Replace the next * by </li>\n</li> (etc) If we get two ** replace by <ul><li> (you can see that it is the same as=20 the first, so no need to treat it differently) So basically, we need two "opening" lines: one of the "first" or "extra" * (if there is one more than the last=20 line, of if this is the first line) one for a "next" ** in a series. The tricky part is the closing. When we go "down" one level, we need to have: </li></ul></li> (closing the nested list-item, closing the nested list,=20 closing the list-item the nested list is in. But if we're going down to level zero, we need: <li></ul> I think there is some sort of counter in the current code that keeps=20 track of which level we are in? There. I'm just posting this thinking to the list in case it can inspire=20 someone. If you see clearer than me into the existing code (which isn't=20 difficult), is there a simple way this could be implemented in it? I'm sure I could hack out a little function or such to do this, but it=20 would probably take me a VERY long time and be VERY ugly ;) waiting for feedback :) Tara --=20 Je r=E9ponds au mieux de mes connaissances Climb to the Stars! - http://climbtothestars.org/ SpiroLattic - http://climbtothestars.org/spiro/ Pompeurs Associ=E9s - http://pompage.net/ |
From: Gary B. <ga...@in...> - 2001-11-15 12:01:49
|
On Thu, 15 Nov 2001, Tara Star wrote: [snip] > I'm sure I could hack out a little function or such to do this, but it > would probably take me a VERY long time and be VERY ugly ;) > > waiting for feedback :) I've come to the conclusion that the fact that wiki marks up line by line means that: - block-level markup is hard to code - the WikiSyntax for block-level markup is contrived and ugly. I'm working on a prototype two-pass markup scheme that will apply block-level markup (h[1-6], p, hr, ul, ol, dl, blockquote, pre and maybe table), leaving lines of text which will have line level markup (i, b, a, etc), It will hopefully eliminate all the problems in MeatBall:SillyTextFormattingRules and, incidentally, produce well-formed XML/XHTML. It will also mean that stuff like ''italics'' will be able to span multiple lines. When I turn it into code it will be a thing of beauty, I promise, but it is all in my head at the moment. I hope to get it done by sometime this weekend and then let you all have a look at it. Till later then, Gary [ ga...@in... ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ] |
From: Tara S. <te...@cl...> - 2001-11-15 12:10:37
|
Gary Benson wrote: > I've come to the conclusion that the fact that wiki marks up line by li= ne > means that: > - block-level markup is hard to code > - the WikiSyntax for block-level markup is contrived and ugly. >=20 > I'm working on a prototype two-pass markup scheme that will apply > block-level markup (h[1-6], p, hr, ul, ol, dl, blockquote, pre and mayb= e > table), leaving lines of text which will have line level markup (i, b, = a, > etc), It will hopefully eliminate all the problems in > MeatBall:SillyTextFormattingRules and, incidentally, produce well-forme= d > XML/XHTML. It will also mean that stuff like ''italics'' will be able t= o > span multiple lines. I assume you're talking about wiki-lines, and not html-<p>-lines! > When I turn it into code it will be a thing of beauty, I promise, but i= t > is all in my head at the moment. I hope to get it done by sometime this > weekend and then let you all have a look at it. Looking forward to that! Tara --=20 Je r=E9ponds au mieux de mes connaissances Climb to the Stars! - http://climbtothestars.org/ SpiroLattic - http://climbtothestars.org/spiro/ Pompeurs Associ=E9s - http://pompage.net/ |
From: Gary B. <ga...@in...> - 2001-11-15 12:36:06
|
On Thu, 15 Nov 2001, Tara Star wrote: > Gary Benson wrote: > > > > I've come to the conclusion that the fact that wiki marks up line by line > > means that: > > - block-level markup is hard to code > > - the WikiSyntax for block-level markup is contrived and ugly. > > > > I'm working on a prototype two-pass markup scheme that will apply > > block-level markup (h[1-6], p, hr, ul, ol, dl, blockquote, pre and maybe > > table), leaving lines of text which will have line level markup (i, b, a, > > etc), It will hopefully eliminate all the problems in > > MeatBall:SillyTextFormattingRules and, incidentally, produce well-formed > > XML/XHTML. It will also mean that stuff like ''italics'' will be able to > > span multiple lines. > > I assume you're talking about wiki-lines, and not html-<p>-lines! For sure. The idea is that if you have something that looks like this: Hello I am a bit of a paragraph * ''hello I am a big rambly list item that splits across some lines'' Hello I am a bit of another paragraph then it will break that into: para: "Hello I am a bit of a paragraph" item: "''hello I am a big rambly list item that splits across some lines'' para: "Hello I am a bit of another paragraph" and then apply line-level markup to each, hence the ''italics'' will cross line boundries automagically. Gary [ ga...@in... ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ] |
From: Jeff D. <da...@da...> - 2001-11-15 15:59:45
|
On Thu, 15 Nov 2001 12:01:30 +0000 (GMT) "Gary Benson" <ga...@in...> wrote: > I've come to the conclusion that the fact that wiki marks up line by line > means that: > - block-level markup is hard to code > - the WikiSyntax for block-level markup is contrived and ugly. > > I'm working on a prototype two-pass markup scheme that will apply > block-level markup (h[1-6], p, hr, ul, ol, dl, blockquote, pre and maybe > table), leaving lines of text which will have line level markup (i, b, a, > etc), It will hopefully eliminate all the problems in > MeatBall:SillyTextFormattingRules and, incidentally, produce well-formed > XML/XHTML. It will also mean that stuff like ''italics'' will be able to > span multiple lines. > > When I turn it into code it will be a thing of beauty, I promise, but it > is all in my head at the moment. I hope to get it done by sometime this > weekend and then let you all have a look at it. Most excellent. As I've been saying, I've been thinking along similar lines for awhile now. One more point to think about: it would be nice to be able to mark spans of (pre-transformed) wiki-text, then have those spans suitably marked up in the post-transformed (X)HTML. A couple uses for this would be: 1. Fancy diff output. Before transforming, the diff engine produces page text which includes all the deleted text (from the previous revision) as well as the current page text. Added and deleted spans of text would be so marked, somehow. Then after transforming the added and deleted spans of text would be marked up as <span>s (or maybe <strike>, <font color="...">). 2. Jump to match. The full text search output now highlights matching words in the page text. It would be nice if when you click on one of those, you're taken to the location of matching text within the target page. I'm envisioning that if one browsed to a URL something like: http://a.b.c/wiki/HomePage?match=Wiki#match3 in the transformed text, all occurences of the word 'Wiki' would be highlighted --- they would also all be marked up as named anchors: the first match named #match1, ... The best implementation of this would be, I think, (though I haven't though about this too hard) to mark the matching words in a separate step before transforming. Again the transform code has to support some means of marking spans of pre-transformed text. A complication to consider is that the pre-marked spans of text may overlap with other markup in the transformed text. (I.e. in the diff case, an added section of text may span several paragraphs.) I think this means the transform code has to be able to split the pre-marked spans into sub-spans, as necessary, to maintain proper nesting of elements in the final XHTML. No, it's not simple. I'll keep thinking about it, too. |
From: Tara S. <te...@cl...> - 2001-11-15 16:17:34
|
Jeff Dairiki wrote: > 1. Fancy diff output. Before transforming, the diff engine > produces page text which includes all the deleted text (from > the previous revision) as well as the current page text. > Added and deleted spans of text would be so marked, somehow. >=20 > Then after transforming the added and deleted spans of text > would be marked up as <span>s (or maybe <strike>, > <font color=3D"...">). no <font>, please! Use <ins> and <del>, and specify visual aspect in=20 css. Please please please! --=20 Je r=E9ponds au mieux de mes connaissances Climb to the Stars! - http://climbtothestars.org/ SpiroLattic - http://climbtothestars.org/spiro/ Pompeurs Associ=E9s - http://pompage.net/ |
From: Jeff D. <da...@da...> - 2001-11-15 17:17:39
|
On Thu, 15 Nov 2001 17:13:41 +0100 "Tara Star" <te...@cl...> wrote: > no <font>, please! Use <ins> and <del>, and specify visual aspect in > css. Please please please! Thanks for the hint. :-) These things would, of course, be "configurable" (even if that means editing the source.) Consider, though, that some of us still need to support older browsers. (AFAIK, Netscape 4.x doesn't support <ins>, <del> at all.) I suppose it would be possible to add an additional output layer (only when needed) which would, e.g., translate <del> to <strike>, etc... (Of course XSLT is the real solution, but we're putting that off for reasons specified elsewhere.) I guess what I'm proposing is that we could write a cheesy/hacky output translator which would allow us to move towards cleaner XHTML output from the main PhpWiki code. When it comes to pass that PHP supports XSLT better, we'd drop the cheesy translator in favor of real XSLT. Just thinking out loud, mostly. It's probably more trouble than it's worth. |
From: Tara S. <te...@cl...> - 2001-11-15 19:51:16
|
Jeff Dairiki wrote: > Just thinking out loud, mostly. It's probably more trouble than > it's worth. what is - producing standards-compliant code, or supporting older=20 (broken!) browsers? ;) T. --=20 Je r=E9ponds au mieux de mes connaissances Climb to the Stars! - http://climbtothestars.org/ SpiroLattic - http://climbtothestars.org/spiro/ Pompeurs Associ=E9s - http://pompage.net/ |
From: Jeff D. <da...@da...> - 2001-11-16 23:08:56
|
On Thu, 15 Nov 2001 12:48:34 +0100 "Tara Star" <te...@cl...> wrote: > I can't find my way in the code to do this, but this is how nested lists > could be made standards-compliant. I think I've now kludged things enough to get this right. (I've just checked my changes into the CVS repository.) |