tags inside
sections) (see below for details) ** Blank lines are rendered as "", which is rendered strangely by some browsers (Is it valid HTML?). I recommend using a HTML 4.01 doctype, then *never* emitting the end-paragraph () tag. ** most pages seem to have an unmatched closing ''''-tag. * Sometimes, when clicking on the VisualTour ImageMap, it displays raw map programming instead of the WikiPage (10/2001) * When an ISBN link is formed, a space may be generated after the ISBN number, and that space is usually included in the link (10/2001) * The formatter for diff output doesn't appear to be OnceAndOnlyOnce'd with the formatter for normal output. (DanglingLink''''''s show with '?' links normally, but as normal links in the diff.) * When a monospaced ISBN link is formed, ISBN is followed by two spaces instead of one (10/2002) * WikiBackslashBug * Multiple indentation (e.g., for bullet points) is processed as one level of indentation fewer if it immediately follows a monospaced line, and the tag for the monospaced line follows the indented line, causing it to be monospaced as well. (28 Jul 2003, still there 2006/01/18) * There seems to be a bug in the script preparing the new http:RecentChanges. I got the line (literally) Sand Box 37, -37, 1, new 2861, * which seems to contain 2 errors **'new' without a ',' in the middle (this seems to be intended, it occurs always; with 'del' too) and **a trailing ',' at the end * On doing a FullSearch, I got "No pages found out of 588 pages searched." (12/2004) * New pages are no longer automatically annotated as new in the RecentChanges page. (1/2005) * The output from NewRecentChanges sometimes omits updates which have been done. (2/2005) * Google hasn't indexed Wiki since perhaps March 2005! The fault is probably c2's, not Google's. See GoogleHatesWiki. (Bug listed 2005-08-28.) ** Evidence points to the implementation of DelayedIndexing. *** Ward throttled this back in August 2007 and it seems GoogleLovesWiki again! * OhAcuteBug: As of the switch to UtfEight in May 2006, the lowercase letter 'o' with acute accent (� Ó) cannot be represented. * IsbnThirteenBug: Wiki recognises ISBN-10s but not InternationalStandardBookNumber''''s ---- The pages produced by the QuickDiff feature (which rocks!!!) produce tables which are ''exactly'' 600 pixels wide. This is a BadThing as it means you can see less of big changes in wide browsers, and less of changes in small browsers (palm/CE devices). -- BrianEwins The pages produced by the QuickDiff feature (which rocks!!!) underline and turn blue Bumpy''''Case words which should only have a blue question mark following them. I love the feature. Thanks. -- ChrisGarrod ---- If you go to http://c2.com/cgi/wiki it will display the content of FrontPage. All the links work except the referer-based ones: BackLink''''''s, LikePages, VisualTour, etc. My suggestion for fixing this is to issue "301 Moved permanently" for any URL which resolves to Wiki content but !~ m{(www\.)?c2\.com/cgi/wiki\?.}i . The only side-effect I can think of would be to break access for people who are forced to do some strange form of munging to get past a firewall. (Yes I know the (www\.)? is redundant since the pattern isn't left anchored, but it serves to illustrate lack of prejudice against the alternative URL form.) ---- Here are a few problems recently noted with LikePages: 1. The page from which the request was made should not be included in the lists. ** '' Sorry - have to disagree on this one. I like having the "back" feature this implies. I know that any 21st century browser will do it, but it's nice anyway. -- MartySchrader'' 1. Clicking on a link on the LikePages page results in another call to LikePages, which is not what one would expect. ** [WikiSelectBookmarklet is one workaround.] 1. Each link listed by the like function contains a trailing space. ---- http://www.example.com/Note/The/Trailing/Colon: <-- the trailing colon gets slurped into the URL, which is not similar to the existing "ignore trailing punctuation" rule. [This is documented, but inconvenient.] ---- '''Excess Spacing''': ''' in pre-formatted text''' This Wiki produces invalid HTML for some pages. Its handling of pre-formatted text is especially irritating. On page LongFunctionsDiscussion, someone noted "(Note that Mozilla displays too many blank lines in this example.)" and "visual spacing is a key element of this debate". We have some text that's already just the way we want it. The space character at the beginning of each line *should* tell the Wiki parser to leave it alone. In the middle of that text, there is a single blank line. edit mode: //---- Wake Up ---- [blank line here] foo = bar + adsfsdf() Wiki rendered (as of 2004-04-17)//---- Wake Up ---- foo = bar + adsfsdf()* No space: IE/Mac * One blank line: Netscape 4.x, IE/Win * Two blank lines equivalent: MozillaBrowser, SafariBrowser, OperaBrowser Wiki ''should'' render it as
//---- Wake Up ---- [blank line here] foo = bar + adsfsdf()which gives correct results on all browsers. This breaks the rules for HTML (
is illegal inside
..., according to http://validator.w3.org/). -- BruceAdams What's the best way to fix this? -- DavidCary You could either generate
or simply " \n" The same thing happens with the KonquerorBrowser too, so it isn't ''just'' a Mozilla/Netscape problem. In any case, I have a lot of difficulty thinking of any way to interpret the spec that would justify this behaviour. -- GarethMcCaughan ''by "this behavior", do you mean the allegedly invalid HTML that the WikiEngine is producing, or the strange inconsistencies between web browsers?'' I certainly think this is a ''minor'' Wiki bug. But, it ''is'' a bug. http://validator.w3.org/ is very good at telling you if your HTML is valid. By its standards, ordinary Wiki pages have a few problems, all of which, I think, should be fixed. If the code is available, I'd be happy to make the fixes myself. -- BruceAdams I disagree that it is minor. It makes for some ugly-looking and sometimes confusing code samples and AsciiArt. Perhaps "medium" bug? Why do you rank it low? True, its not a show-stopper, but it's either uglied-up or made editing difficult for roughly 50 pages that I've read or participated in. It has a medium-low per-page impact, but it is a '''high-quantity''' bug. And, non-IE browsers are growing more common. I'd like to see the cost/benefit analysis compared to other wiki bugs. I noticed that people are altering their formatting habits apparently to work around this bug, resulting in non-WYSIWYG text in the edit view. FireFox 2 rendering suffers from this also. It seems a re-formatting gnome is going around and "fixing" the spacing in the edit window, which breaks it in Mozilla-based browsers (showing excess space). They are probably using Internet Explorer and not realizing the impact of their spacing "fix". ---- ''' in non-pre-formatted text''' WikiWiki uses for the empty line between paragraphs. In OperaBrowser, this is rendered as a line break, not an empty line. This makes all paragraphs run together. Readability suffers. -- RichardCyganiak ''And there is no real reason. You could putinto the header,
into the footer, andor even
in place of a blank line.'' Recent versions of OperaBrowser (checked with 7.02) render
as an empty line, solving this problem. However, marking up paragraph breaks as is still a bad idea. -- RichardCyganiak [Doing without is a litttle tricky if one wishes to avoid the side-effect of unwanted blank lines.] ''Why can't the WikiEngine simply use? My HTML 4.01 documents never have any
, and they (usually) pass the W3 validator.'' ---- '''things that may look like invalid HTML, but turn out to be perfectly valid''' I've noticed that the source for the "?edit=[WikiName]" page look like this at the end: FrontPage Is there a reason for the trailing "body" and "html" tags to be missing? -- AndrewMartin The HTML pages returned by Wiki are not HTML since they do not have an HTML-element. Just look at the source code of the page you are currently viewing. ''The HTML 4.01 spec says that the start and end tags for the HTML element are optional. The pages have HTML elements; their tags are just implicit.'' ---- I just edited LinuxDistribution, but this did not show up on RecentChanges. It did not appear on QuickChanges either. It should not have been on the latter two anyway of course, but I checked them just in case. And no, I did not remove the line when I edited RecentChanges a little bit later. Maybe a grue hiding in the dark ate the line. ;-) -- MarkoSchulz ---- With OperaBrowser for the mac (which claims to be fully http 1.1 compliant), Wiki doesn't provide
tags for LF/CR even when such is specified on the edits page. This makes text that isn't supposed to run together do so. (9/2001) ''The data sent in a textarea field can basically be anything so http1.1 compliance doesnt come into it. Mac sends CR, windows sends CRLF, and unix sends LF for line ends in this embedded text (while the HTTP request as a whole is only supposed to use CRLF, your submission is often encoded and thus the original macness shines through). The regexp for para breaks probably needs changed to something like /\r{2,}|(?\r\n){2,}|\n{2,}/ , but you need to be careful about the magicness of \n in perl. -- BrianEwins'' ---- If the text contains '\ text', 'ext' is listed as a spelling error. ---- Jan 2, 2004: Is this a bug? Or am I doing something wrong? I haven't seen this before. I attempted to edit AutomaticLocking the ordinary (and only) way, and when it was saved, all the whitespace was encoded, and all the formatting characters were treated literally. It was like the cgi output from the form submission was not processed. This happened only in a recent version of Mozilla for Linux, and not Firebird. I was able to fix the damage (when others didn't get to it first) by using Firebird. I hope this edit works okay now. ---- Archived pages appear to be susceptible to deletion. See comment at the bottom of HistoryPages. ---- Question: Why do these both work, but the "," version not display the WikiWiki logo? http://www.c2.com/cgi/wiki,?FindPage http://www.c2.com/cgi/wiki?FindPage Microsoft Live-Search inserts commas in URL links sometimes. ---- ReverseIndex is not working when you click on the title. * ''Correction, you claim it is not working for you, but it works just fine for me. See my other comments on the page ReverseIndex'' * There is a delay on new entries as this depends on a catalog system which is only updated once every 24 hours. ---- When using features at the bottom of each page: Clicking on the (broken) image in the VisualTour item at the bottom currently produces an error from this page: "http://www2.research.att.com/~north/cgi-bin/webdot1.7.11/webdot.cgi/http://c2.com/cgi/locale/w2.d2/WikiWikiSuggestions.dot.dot.map?18,15" Clicking on LikePages link at the bottom currently produces: "The requested URL /cgi/like was not found on this server." ------ Why is this image not in-lining? Are the dashes throwing the reg-ex's off? http://4.bp.blogspot.com/-HpwWEkmsczQ/TsyAJ-yh4aI/AAAAAAAAIvI/dDXY_JSUfw0/s400/DSC_0134.jpg ''The extension is CaseSensitive. Upper-case 'JPG' extension is not recognised as an image format. LowerCase 'jpg' is recognised.'' Solved the mystery and provided a work-around, thanks! ---- CategoryWikiMaintenance CategoryWikiImplementation