archive-org.com » ORG » W » WIKICREOLE.ORG

Total: 1035

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • Talk.How To Use This Wiki
    for the help with the SpamFilterWordList I also activated the akismet net function Should you have problems to edit a page due to the spam filter let me know Christoph 18 Dec 06 Keuh You seem to have installed the latest from the dev branch which does not yet have all the features of the 2 4 stable branch incorporated including a fixed spam filter Please expect weirdosities as this is a known broken system now I would highly recommend the latest in the 2 4 branch not the 2 5 development JanneJalkanen 18 Dec 06 Thought to myself be bold Switched back to 2 4 82 latest stable Thanks again Janne ChristophSauer 19 Dec 06 Nononono use the latest from the JSPWIKI 2 4 BRANCH Any 2 4 branch prior to 2 4 85 has a broken SpamFilter I have not yet simply had time to release a new stable JanneJalkanen The JSON javascript seems broken in IE6sp1 Having a javascript error message appear Error A Runtime Error has occurred Do you wish to Debug Line 345 Error jsonrpc is undefined Yes No Quite frequently almost every keystroke on occasion I would recommended wrapping the javascript in a try catch block atleast to prevent javascript error warning messages appear JaredWilliams 2006 12 19 The unfortunate side effect of using CVS HEAD I hope it should now be fixed i e the AJAX stuff is no longer there It s a feature of the upcoming JSPWiki 2 6 of which you got a very bad preview of JanneJalkanen 2007 02 26 RadomirDopieralski I just thought of a minor improvement I d like to ask for to put the log in log out link right next to where it says G day insert your name here I find myself looking there to check if I m recognized authenticated and then searching the whole screen for the login link By the way it seems that this macro uses a different algorithm for recognizing users than the one generating recent changes ChristophSauer Thanks for the suggestion I will add that the next time I will update the software I also will place the RecentChanges somewhere more visible I will update the software anyway because I ve fixed the LostPassword problem so far JSPWiki was not able to use authentication for email server accounts when sending email that s why I was not able to activate that feature ok software update is done Reset password should work now Null user edits should be fixed as well ChristophSauer RadomirDopieralski Thank you so much for the work And for the login link I just noticed a strange thing initially it said G day Visitor then when I logged in it said G day RadomirDopieralski not logged in then I logged in a second time and it said G day RadomirDopieralski authenticated ChristophSauer Can you reproduce it I restarted the server several times yesterday evening Your login might got lost during this RadomirDopieralski No I can t

    Original URL path: http://wikicreole.org/wiki/Talk.HowToUseThisWiki (2016-02-11)
    Open archived version from archive


  • Talk.Hyphen List Markup Proposal
    we need a invisible space escape character for 25 of the lists usage People only have to learn the use of the tilde if it happens to them that they have to use minus to indicate a negative number as the first text in a line and don t want to use the nowiki markup this is an EdgeCase 0 1 With the Require Space After Bullet Proposal we would design our markup around EdgeCases because we would trade away easy usage of lists with bold 25 for being able to use negative numbers as first literal in a line 0 01 Many wiki engines select a different markup for nested lists indentation We already have been through this discussion We don t want the user to count whitespace Creole does not rely on whitespace in front of elements But we should document this better I think For a user it doesn t matter if a second level element is indented with two or three character but for a simple line based regex parser it does because it is hard to do a look ahead behind right thats how your parser expects it one two three and thats how the user does it one two three Now tell me in an wink of an eye what the difference in my second example is The wink of an eye is important here as soon as the user has to count this becomes a root of confusion and errors Coming back to the general escape character issue I therefore think that whitespace like proposed in the Add No Wiki Escape Proposal is not a good character It might work in the case of nowiki markup but not when you try to escape something at the beginning of a line To be consistent we should have one general escape character that works everywhere but let us discuss that in the new Escape Character Proposal not here Of course using an otherwise unused character for marking lists would work This is why nobody but me is complaining about the numbered lists I hardly use the numbered lists myself I even could live with it if it becomes an addition but it s just to frequently used I guess is it But we should not go into this discussion here Which ones do you like best Are there any other approaches we missed Using hyphens for lists of course ChristophSauer 2007 02 23 I really try to think outside the box that s why I enumerated all the sane markups I can think of no matter how wrong they seem to me I don t think we need a general escape character the ambigous lists is the only place where it is required headings and tables are required to start at the first column so it s easy to escape them with space like in pre block you don t even have to explain it in the spec I can t even see a sane way of actually implementing the escape character looking at the examples on the proposal pages the escape character doesn t apply to a single character but to an undefined context dependet piece of text Escape character also introduces something pretty evil markup that has no visible effect on the rendered page Really pleasy go and try to explain the idea of an escape character to a non programmer As for indenting lists for nesting I don t really advocate it I ve already written that it s unacceptable in Creole It just gives the best appearance But you are wrong about the space counting thing actually so wrong that I suspect you did it on purpose You don t have to count single spaces and match the indentation perfectly you can MakeTheMachineWorkHarder and just recognize changes in indetation not the exact amount of spaces used This works very well in MoinMoin and other wikis that use this technique That s just for the record as it s not going to be used in Creole anyways I think Now for the speciality of the cases Have you recently read any non technical book One that has some action I do sometimes read such books and I also read various stories published on the Internet often in wikis A good dialogue packed story has more than 70 of paragraphs starting with a hyphen Look at this particular wiki Every other page has about 25 of paragraphs starting with a hyphen I don t think there is a single use of an asterisk other than to show the actual asterisk in the text here I don t mind using single hyphens for lists it is so normal and common that it even has its own name hyphenated list It s the use of multiple hyphens for nested lists that I m opposing it s a totally new invention there is exactly one wiki that uses it on wikimatrix org PukiWiki It looks horrible I could look at it and think for hours and never guess it s a list It conflicts with markups for singature en dash em dash and horizontal line not to mention the Markdown like headings if one aims for a mixed mode Finally it looks extremely ugly And beauty is very important when you want passionate users who contribute their hard work just because they like it Ugliness really reduces user performance I can point you to actual usability experiments Looking at the wikimatrix org I can see that actually two wiki engines use the different bullet for different levels approach SnipSnap and LunaWiki Also two wikis use a exotic character for lists ProntoWiki and PodWiki And I see one approach I didn t think of WikkaWiki uses hyphens that can be indented with a visible charcter tilde One can imagine periods or colons used in similar manner Ok this is ugly too I believe that good list markup should have following features The users should be able to tell what the particular thing is without a need to read user manual or experimenting just by looking at it And without having to scroll to see the start of the list This works good with single level lists made with hyphens or asterisks It also works good with indented lists Repeated bullets are just alien and artifical This feature I view as the most important The list must be easy to navigate first with one s eyes then with the cursor It must be easy to locate the end of an item and beginning of a next one and also the beginning and end of the whole list Asterisk alone is bad at this as it has text color similar to an average letter at least in fonts made for reading prose not coding Hyphen is not good too it appears very frequently in the body of text You can either use a character with some very dark or very light color or lighten it using whitespace Indented lists do marvelous job here too The list must be easy to edit This means changing the order and nesting level of items moving items between different lists turning paragraphs into lists and vice versa This also partially relies on navigation but also on the number of characters used complexity of the markup availability of keys on the keyboard Here indentation does a horrible job but multiplying the list bullet is not really much better These three points are my main concerns If we could limit the nesting level of lists to two I woud t hesitate and would recommend this first list item second list item first sublist item second sublist item third list item first sublist item It s actually the most popular markup for not numbered lists I ve seen in text files when nested lists were involved The other even more popular approach was to use numbered or otherwise enumerated list mixed with bullet list Or a numbered list with several levels of numbering like 1 2 4 Note how the compulsory space after the bullets increase readability and navigability immensely But this nice apprach breaks if you need more nesting levels Introducing additional bullet characters like is artifical Indentation is evil Repeating hyphens is ugly Please tell me if I m repeating myself RadomirDopieralski 2007 02 23 Radomir I allowed myself to factor your ironic comments in the EdgeCases out here to discuss it They show how one could interpret using hyphens at the beginning of lists not being an edge case I never used it before in a wiki I never saw it Can you point us to occurrences to proof that this is quite frequent Why would anyone put a minus at the beginning of a line Yeah that s just plain silly It must be an edge case Unless they really mean a list of course Yeah or signature but it s so rare to sign your contributions on a wiki Yup you use list with multiple levels of nesting much more often I finally figured it out how to make dialogues without creating a list here Yeah How Well all you need is to emphasis the hyphen since dialogues are an edge case but emphasis at the beginning of a line or list is a counterexample of edge case Neat This was your suggestion Radomir Here s mine With the escape character we could allow this EdgeCase to be easily handled either hyphens I finally figured it out how to make dialogues without creating a list here Yeah How Well all you need is to use an escape character before the hyphens Neat or space I finally figured it out how to make dialogues without creating a list here Yeah How Well all you need is to use an escape character before the hyphens Neat You did not convince me that dashes at the beginning are not an edge case compared to bold lists with asterisk But I think you got me thinking about space as an escape character ChristophSauer 2007 02 27 Use cases http wikiindex org index php title Category Fantasy http wikiindex org index php title Category Fiction http wikiindex org index php title Category CollaborativeNovel http wikiindex org index php title Category Comedy http wikiindex org index php title Category Humor http wikiindex org index php title Category Jokes http wikiindex org index php title Category Literature http wikiindex org index php title Category Poetry http wikiindex org index php title Category Writers Or you can just go to a library and pick a book from a different shelf than software developers only I m sure it s going to contain a lot of these edge case minus at the beginning of a line thingies I m sory for my irony that page is just so obviously wrong and one sided It seems as if it was created to force a statement that even you don t believe is true I think I will Meatball ColdBlanket myself RadomirDopieralski 2007 02 27 Hi Radomir I followed your use cases links above but only found one page that used hyphens for dialog and those had spaces in front of the hyphens anyway so they wouldn t be affected by our hyphenated lists The one case I found is here http eversea org cgi bin wiki pl Nancy Funny that I couldn t find many considering that it s not an edge case Perhaps in Polish dialog is indicated by hyphens whereas it is not in other languages I ve personally never remember seeing this in the fiction I ve read As for indenting lists we ve already ruled that out due to InvisibleMarkup so I will not even address that As for putting spaces after the asterisk you have even seen in your own research that 25 of users do not put a space after the asterisk of a list so I also don t see how this could be a solution Which of the following is clearer Older programming languages Prolog for AI Cobol for business Modern programming languages Java popular cross platform solution Python popular for text processing Ruby invented in Japan Older programming languages Prolog for AI Cobol for business Modern programming languages Java popular cross platform solution Python popular for text processing Ruby invented in Japan As far as beauty I think the second example definitely is more beautiful but people could argue forever on which markup is aesthetically more beautiful That s mostly a matter of taste I know the head developer of MoinMoin finds Creole distasteful because it is ugly but I personally find MoinMoin s syntax very ugly Also when people start using wikis I have often seen that they try to use hyphens for lists instead of asterisks I would however really like to hear other developer s opinions on this issue rather than just us three What are others opinions ChuckSmith 2007 Feb 27 Gripes with current proposals Current standard having to escape the quite common bold at the beginning of a line is bad So Should my proposal prove inadequate or unpopular I m very much in favor of this proposal Still Strange escaping rules should be avoided at all costs Repeating the bullet character vs whitespace I am not sure that we are not making common things at most 2 indentation levels in lists harder while making uncommon things more than 2 nesting levels easier I m in favor of the following syntax hear me out I ll consider anti whitespace arguments one ul one one one two two ul two one ol Advantages Uniform ordered and unordered lists have similar bullets WYSIWY Commonly used in plain text looks a lot like the rendered output Clash with hr not an issue Clash with signature not an issue Works quite well in Python and Haskell This point is only partly humorous as wiki markup is a semi formal language and does have some rigid rules so the same kind of usability rules apply here as they do to programming languages Potential disadvantages User has to count spaces I would count relative indentation not the absolute amount of spaces then this is only a problem if one wants to continue a second level list see below But users look for visual feedback after entering wiki text anyway and will be very obviously alerted to the problem then first level second level counting is not a problem we just have MORE spaces than the line above third level 1 third level 2 counting is not a problem it is the same as the line above second level continued here we have to count Confusing tabs and spaces disallow tabs Clash with negative numbers make space after hyphen mandatory AxelRauschmayer 2007 02 28 I think that we have enough material to create a ListMarkupAlternatives page and try to summarize everything we have scattered around Even if we don t come up with a good solution we will at least have one good place to point people to The list markup has a lot of space for being creative and a lot of interesting features this invites Bikeshedding What I d like to propose is to allow a little creativity put the propositions on that page describe the good and bad things about them compare them etc and then leave it to cool down a little several days maybe I m sure that the one obvious solution will appear then Radomir Dopieralski Excellent idea I am all to familiar with bikeshedding urges myself so the cooling down period makes a lot of sense I ve started to put my ideas on ListMarkupAlternatives AxelRauschmayer 2007 02 29 Moved this potential disadvantages to discussion ambiguities in languages using dash with blanks before and after such as German As long as new lines may be part of paragraph this will lead to random occurrences of hyphen in first line by any line wrapping editor client In the wikis I know lists are commonly written without blank lines before and after Don t understand If a line wrapping client wraps a line it will not put a hard coded line break in So this does not create a random occurence If you write german at least I never put the dash at the beginning of a line if it occurs that I have to hard break the line I always put it on the end Here s a German sentence Dies ist ein Gedankenstrich so etwas kommt vor I usually don t use this Question is does some grammatical rule forbid it Dies ist ein Gedankenstrich so etwas kommt vor You would never separate a word like this Dies ist eine Sauerstoff flasche You would hard break the line after the dash not before it Dies ist eine Sauerstoff flasche So I guess the second example might happen but it s very rare and could be easily resolved by using the order of the first sentence Christoph Sauer 2007 Mar 06 In plain text there are only hard breaks at least with the text editors I know Soft breaks aren t encoded they just appear in some text editors or text edit fields So hyphen can be a problem when the client forces automatic hard word wrap like equal signs e g if the equal sign of equation a 2 wraps to the beginning of a line We can probably accept it YvesPiguet 2007 Mar 06 I ve added a page called List Markup Linebreak Argument since it repeatedly appeared to discuss it there Christoph Sauer 2007 Apr 14 Note that multiple dash minus characters for nested list are actually a new invention only used in PukiWiki together with other exotic markup for headlines in links for underline and strike ref for images I m all for allowing a hyphen list it is traditional and intuitive I m just against multiple dashes for nesting to me it is

    Original URL path: http://wikicreole.org/wiki/Talk.HyphenListMarkupProposal (2016-02-11)
    Open archived version from archive

  • Talk.Images
    already Why don t we just link to them instead of rolling our own I m pretty sure they are more complete and better prepared It s better to join efforts rather than work on separate projects in the same field RadomirDopieralski 2007 02 15 Haven t seen any spam attacks where images were used but have seen vandalism Recently on wikipedia where a unsuitable picture made it to the main front page As for external pictures changing well it depends how its implemented The wiki engine could retrieve the image and serve locally If the image formats involve javascript you could serve them from a different domain than the main wiki perhaps to prevent any exploits like stealing cookies Also has benefits for http request pipelining etc Also prevents images from changing until we wish them to JaredWilliams 2007 02 15 Images are the only Creole element where a straight implementation can lead the browser to have stealth connections to servers with arbitrary contents Everything else isn t more dangereous than the explicit goal of wiki i e permit anybody to write anything anonymously under the scrutiny of others That s why I d suggest a special warning I agree there are solutions Many RFC have a section about security and I think it s wise Spam and vandalism are well known problems which just show that all visitors aren t nice YvesPiguet 2007 02 15 Sigh This is really not the place for it but ok let us analyze the risk First let us look at similar threats present on other web pages Then we will look at how dangerous they are Finally we will examine ways of protecting against them Wiki is one kind of site that displays user submitted content There are other such web services too Lets see how common the threat is Most of the forum software allows users to have custom avatar icons and images in their signatures they are often required to be external images in order to conserve the bandwidth of the site hosting the forum Many forums also allow including images directly in the body of the post Even if they did not just putting an URL to the image practically guarantees that at least several people will click it Surprisingly so called image boards seem to be much safer as they host the images they serve Every big and trusted news site web portal etc allows commercials that are displayed in form of banner images or even embedded objects flash even movies This is not free but pretty cheap and they don t really check their clients Google images will display cached versions of images but you re only several clicks away from displaying the real thing Most internet sites have those external links that lead to other internet sites which can in turn contain malicious images not because they are on the wiki but simply because they are hosted by the attacker himself There are various redirectors domain aliases tinyurl like services that will allow hiding the real url There are many programs other than web browsers that will attept to download and display external images User friendly mail readers news readers feed readers various ad ware programs that are free to use but display banners etc It seems that a pretty large chunk of the Internet is buggy and requires fixing The security threats are everywhere to get you But lets assume that you are just a very dedicated wiki user and you don t really visit any web sites apart from your favorite wiki at least not from a workstation in your top secret corporation What can the attacker do to you He can discover your IP address Or the IP address of your gateway if you are behind NAT in a private network which is very likely If you are concerned about disclosing your IP address you use a proxy server or TOR anyways If he prepared the URL so that it is unique he can also see what page was downloaded by that IP address Unless of course one of several layers of caching kicks in in which case he will only see part of the traffic He can launch some javascript script on your browser The script can be abnoxious if you didn t disable relevant options in your browser allow to create windows replace popup menus etc or actually if you did enable them they come disabled by default recently As the script is launched from the attacker s domain not the wiki s it can t really steal cookies or perform actions in your name If your browser has a bug he can possibly exploit that bug In case of Linux this probably means crashing your browser or even crashing your session In case of Windows this probably means installing a troyan horse program or even getting administrator priviledges on your machine This is pretty nasty but these bugs are pretty rare in sane cases the patch is relesead quickly if you have unpatched known security bugs in your software you re risking by just having your computer connected to any kind of network not just by browsing wiki pages If the wiki engine uses logins and has a bug in its code the attacker can intercept your password Well this is an instance of if the software you use has security bugs you re not secure The attacker can include a malicious link to an evil action in your intranet application as described in the link I gave you before Again this is a security bug in the application and should be fixed there as there are multiple other entry points for it If you are still concerned your browser has an option to disable automatic loading of images It will still display the images from your cache and those that you tell it to download Looks like a perfect solution if you are paranoid and only want to browse the single wiki site Modern browsers even allow you to provide a list of allowed and disallowed domains Most firewalls allow for somethng similar too Similarily if you are afraid of javascript and only browse safe sites without javascript then why do you have javascript enabled at all To summarize the threat is very widespread defending from it on the user side is trivial defending from it on the server side is difficult costs resources bandwidth and server load and opens new opportunities for attack they are out to get you RadomirDopieralski 2007 02 15 I m not concerned as a user thanks but as a potential contributer to Creole History shows that a slightly less secure system is always abused and must eventually be fixed or abandoned SMTP open servers finger 15 years ago there was a nice way to forward requests WEP etc The current situation of the Web is the net result of millions of people thinking it s a fatality A warning for implementers wouldn t cost much imo that s all YvesPiguet 2007 02 15 You can trip and hurt yourself when walking This is very dangerous and can result in injury or even death Actually there many more documented cases of people tripping while walking and dying as a result of the injury that there are of users being attacked by extrnally linked images on a wiki I think that it is very probably that users will attempt to walk right after using Creole or even try to walk while using it Therefore I want to propose to include in the Creole formatting markup rules specification a section dealing with walking and the immediate dangers that can affect Creole users as an effect of it In particular I want to include this message Warning Be careful when you walk Otherwise the users could take this lightly and don t exercise apropriate care Especially youger users who are often not aware of all the dangers of walking and ignore the safety precautions I think that this is at least as relevant to Creole formatting markup rules specification RadomirDopieralski 2007 02 15 Additional attributes I just wanted to note that MoinMoin might support creole like linking and transclusion as part of its default wiki parser soon as moin s link syntax was a bit too complex partly not doing what people expected partly too limited partly broken etc there has been a long term plan to change it I didn t really plan to do a fundamental change now but it came as a consequence of another change I like the easy link syntax of creole much and even more to just have 2 fundamental things solved by some sane syntax you can either link to something or you can transclude something often used with images but not limited to Consistent usage of those 2 patterns will make stuff much easier better predictable and requiring less magic For later I plan to use the transclusion syntax not only for images but as a generic transclusion of other objects as far as technically possible For this additional parameters are needed Even for images you sometimes want to give more parameters maybe width height css class so it would be nice to have some generic way of giving transclusion parameters in creole I looked at how wikipedia is doing images and it seems to be target parm parm text So maybe it would be a good idea to change the creole image transclusion standard to tell that target can be followed by an arbitrary number of optional fields separated by and that the last of those should be taken as the description or alt tag if it makes sense for the type of transcluded object That way any creole parser could make something out of flower png foo bar Nice flower even if it does not know how to interpret the foo bar field and just ignores it The parsing of the middle field s would be up to the implementation Some implementations could choose to use multiple fields one per parameter some other could choose to just use one and parse that by some other means target foo bar text target what foo ever bar text ThomasWaldmann 2007 08 23 I like the parameter indication you suggested I was thinking about that too and came up with this in our CreolePageFilter for JSPWiki target jpg text description M X Where M X and are parameters for size positioning and border separated by comma If you don t need an image description but parameters you do something like this target jpg M X But how would your suggested syntax solve this Indicating only parameters with no description ChristophSauer 2007 Aug 23 08 44 CEST Couldn t we design a more generic solution which would also work for tables line width color locked heading headings numbering toc etc The way I d implement that while staying in the framework of Creole 1 0 would be with plugins which wouldn t break compatibility e g P maxwidth 2in float true caption true image jpg caption P tborder 1px hlock 1 Name Pet Bob dog Joe cat YvesPiguet 2007 Aug 23 Christoph your proposal of ever using the 2nd fragment as description and appending more fragments at the end is better than my idea The most important thing is to add that to the creole specs asap so people implementing creole do a multiple split on and expect a arbitrary number of fragments as result not just a single split with 2 fragments as result Then the spec should tell that 1st fragment is target 2nd fragment is description Later 3rd fragment could be defined as image style see below 4th fragment could be reserved for either future creole specs or wiki implementation specific A creole parser can support this to the level wanted a very simple parser would just support 1st and 2nd fragment and ignore everything following Or just use the keyword arguments from 3rd fragment that it understands and ignore the rest For the width height alignment etc parameters I guess I would prefer some syntax like width 100 height 100 align right so it would be target jpg description width 100 height 100 align right title a title more keyword arguments as needed BTW the same kind of extensions should be defined for link syntax ThomasWaldmann 2007 08 26 Adding some ideas after talking with RadomirDopieralski It would be sufficient to standardize 1 target 2 description 3 engine specific fragment n engine specific fragment Reasoning faster to standardize the expected fragment format the kind of parsing the implementor likes or has already available might differ the valid fragment content which keywords value are valid also depends on target often this is a image but you can also implement generic transclusion using html4 object tags so the target can be any type e g multimedia content BTW this pages should rather talk about transclusion and then about the most famous and the only required transclusion type images That shouldn t hold implementors back who want to try generic transclusion though Another thing needed is escaping for as it could be part of some fragment ThomasWaldmann 2007 08 27 Just wanting to clarify these would be the possible ways of including transcluding an object image or something else for simplicity I use image image image alt text image alt text some engine dependent content possibly including more s image alt text containing the symbol engine dependent content Note you can leave the alt text empty should the engine generate alt text for you from otherwise available information or just assume you know what you re doing and actually put an empty alt Personally I think the latter makes more sense as empty alts have their use I think it s the simplest way requiring the least defining and allowing maximum flexibility We could define the exact format in which the parameters should be given the names of parameters would still depend on the kind of content being included and the exact way it s being done But I think it doesn t really increase interoperability Good examples of recommended format for parameters might or good practices about them could be helpful though Update removed the escaped pipe form image in the last example as it cannot use for escaping according to the current spec Sorry about that RadomirDopieralski 2007 08 27 No comments Can we do that soon ThomasWaldmann 2007 08 29 If we need an extension mechanism for images I d prefer something which also works with other elements Pipes won t work with arrays So I m against the proposal above YvesPiguet 2007 Aug 30 Currently pipe is already used as separator for link text So may be its not a bad idea to reuse it Or it has to be probably changed there too link text ReimarBauer 2007 Aug 30 Unless we re certain there will never be parameters for other elements such as tables headings etc we should devise a syntax which will extend nicely for them or abstain Alternate text is so common it shouldn t be changed Some random thoughts reserve single angle brackets for embedded HTML or XML for elements which need more flexibility than what Creole 1 0 offers or add an optional element to specify attributes such as attr1 val1 attr2 val2 etc or use plugins see above YvesPiguet 2007 Aug 30 What attributes except for various presentational and styling issues that are better solved with css not wiki markup would tables by arrays you meant tables right require I can think of spanning multiple rows columns for table cells but that is better handled by using some kind of special marker in the cells themselves or just leaving them empty RadomirDopieralski 2007 Aug 30 Floating no floating captions spanning column or row separators etc I don t think they re required in Creole but if you want to add options to images why not to some other element Many attributes relevant for images borders size etc would also be useful for tables Or is it only to use double braces for transclusions YvesPiguet 2007 Aug 30 Spanning and captions seem to be things to be specified with attributes or some other special markup All the others can be easily done with styles and are presentational rather than semantic don t you think The attributes we are discussing here are indeed most needed for more general transclusion that just simple images in particular for specifying parameters for media players when embedding video for specifying floating frame size when including text or html files for specifying encoding of included text files etc as you can see they all are quite advanced depend heavily on the kind of object being transcluded and the method used for transclusion and generally are non compatibile between different wiki engines It is possible to imagine similar attributes applied to links for example to specify nolink attribute or to mark the link as a category link and solve the Meatball UseMentionProblem but they are not really that useful in there Since the attributes would not be compatible between the wiki engines anyways they can t really go into the CoreCreole All we need in CoreCreole is an additional rule that says if there is an unescaped pipe character in a link transclusion description it ends that description and the remaining part can be ignored or used by the engine in any way Note that these attributes are not just for visual sugar coloring of text styling adding icons or borders they are for changing how the transclusion actually works and are often required for many kinds of transclusion They change the behavior not the presentation Note how similarities of the link transclusion and plugin macro markup syntax allow us to use similar solution for all of them Note also how the heading table pre and list markups

    Original URL path: http://wikicreole.org/wiki/Talk.Images (2016-02-11)
    Open archived version from archive

  • Talk.Images Reasoning
    more standard notation Nicolas Wu 11 Feb 2008 Because is already taken for links and it s indeed the most standard notation for them apart from CamelCase Using teh same markup for both just doesn t work some wikis treat images as normal pages others as attachaments you often want to have the ability to choose whether to display the image or to link to it The markup is nicely consistent with and doesn t collide with most existing markups the mediawiki templates can be resolved I think there was a wiki using it for monospace too but it had a lot of other strange rules Besides MoinMoin now uses for images and page transclusion too RadomirDopieralski 11 Feb 2008 Thanks for the answer So taking this abstraction further would we say that always takes us to another page in the wiki or to an external link whereas will try to embed the content directly in to the page For example we might want to embed a flash video plug in some raw text or even directly insert the content of another wiki as far as I know this isn t done but I m wondering if it might be a useful extension Nicolas Wu 12 Feb 2008 Yes exactly There might be some magick involved in determining the type of the linked object and embedding it so it s definitely and advanced feature of any wiki engine but the intention is there square brackets link curly braces embed At least it s how I see it but I suspect others had similar ideas when this was introduced RadomirDopieralski 13 Feb 2008 I would like to note that can be seen as transclusion so embedding another static resource like images or videos but I think we should have a different

    Original URL path: http://wikicreole.org/wiki/Talk.ImagesReasoning (2016-02-11)
    Open archived version from archive

  • Talk.Inclusion
    Recent Searches Clear Talk Inclusion Your trail Home Talk HowToUseThisWiki Home Talk HyphenListMarkupProposal Home Talk HyphenListMarkupProposalWorks Talk Images Home Talk ImagesReasoning Home View Page Discussion V iew A ttach I nfo Could we lose the space inside the double curly brackets for inclusion so the markup is consistent with how we do links ah or is this an issue with wikis that have double curly brackets to indicate monospacing MarkGaved 31 Aug 2006 Not an issue for me I think the space is just for clarification not for syntax At least it makes no sense for me to require whitespace anywhere JanneJalkanen 31 Aug 2006 I have this idea about using the same markup for inclusion placeholder and images Maybe it will inspire some better ideas page name comment transclude local page pattern comment transclude multiple pages with used for globbing maybe image name alt insert an image for wikis that store images as pages url alt insert external image filename alt insert an image for wikis that store images as attachments 65345 comment placeholder page name image alt have an image linking somewhere else than itself Of course not all examples would work in all wikis The bad thing

    Original URL path: http://wikicreole.org/wiki/Talk.Inclusion (2016-02-11)
    Open archived version from archive

  • Talk.Indentation Markup Proposal
    indentation with multiple levels is supported nothing prevents the engine from producing HTML friendlier to people using a screenreader It s the same problem as nested lists Couldn t CSS also be tuned for screenreaders e g by inserting the indentation level before each indented paragraph I think that advices would be welcome by many implementers who aren t familiar with these technologies Screenreader friendly HTML CSS suggestions for each Creole construct would be a good starting point YvesPiguet 2007 Sep 20 I would be really great if we could attract some people with real experience with screen readers braille terminals etc and also people try to parse and analyze web pages programmatically most knowledge comes from various guidelines and regulations that are not always perfect Even if we don t include any indentation nesting subitem or quote markup into Creole maybe we can at least collect some material on the topic I don t have much experience with blind people but the idea of hierarchy in flowing text seems to me to be inherently visual so the user friendly method of presenting it would be to describe the hierarchy in terms different than just markup that is write it with words And no not automatically this doesn t really work I wonder do we need to consider different use cases How does screen readers treat nested structures on web pages such as lists blockquotes or tables inside tables RadomirDopieralski 2007 Sep 20 Yes having some real users would be great and is at a certain stage of work indespensable This stage is now reached But why an automatic insertation of a hidden text e g Indented text level 1 start Indenteed text level 1 end should not work is not clear to me Jaws reads list elements as follow

    Original URL path: http://wikicreole.org/wiki/Talk.IndentationMarkupProposal (2016-02-11)
    Open archived version from archive

  • Talk.Intra Page Links
    search type ahead Recent Searches Clear Talk Intra Page Links Your trail Home Talk HyphenListMarkupProposalWorks Talk Images Home Talk ImagesReasoning Home Talk Inclusion Home Talk IndentationMarkupProposal Home View Page Discussion V iew A ttach I nfo Only two elements are required in an intra page link a fairly ordinary href link ref a href ref link a And a id tag a name news Wikipedia I think gives all headings

    Original URL path: http://wikicreole.org/wiki/Talk.IntraPageLinks (2016-02-11)
    Open archived version from archive

  • Talk.Italics And Url Ambiguity
    RadomirDopieralski 2007 02 2007 Plain URLs without markup aren t supposed to be converted automatically to links are they If they aren t I suggest we stick with that It s easy enough to add brackets and there will always be cases where the engine won t recognize a whole URL correctly I ve already seen such cases on this site YvesPiguet 2007 02 27 They are I remember arguing against it initially but I changed my mind and actually would argue for it now It s the sane thing to do if you can avoid false positives and you can by listing the protocolas accepted RadomirDopieralski 2007 02 27 Ok thanks I see it s in Creole 0 5 but not in Links I guess I must look unsane I have the same concerns as Jared wrt unrecognized protocols do you support the whole list at http www iana org assignments uri schemes html but even afp Apple File Protocol or call aren t there I guess I m asking too much to Creole not only a kind of average between existing syntaxes but something unambiguous well defined consistent not outsmarting the user and with a good balance between simplicity and power YvesPiguet 2007 02 27 Just an additional test case some servers don t support https www wikicreole org is one of them On wikicreole it s rendered as follows some servers don t support https www wikicreole org is one of them the end of line disturbs the wikicreole engine YvesPiguet 2007 02 27 Looks like https link works to me You have malformed wiki markup there ChuckSmith 2007 Feb 28 But I wanted it to be rendered as https www wikicreole org is one of them note that the only difference with what I wrote above is that the closing italic tag is now on the same line so the parser understands I didn t want a link but italic I know the engine can t guess what I mean For me the best solution would be that URLs aren t converted automagically to links Since implementers are free to support more things than what s in Creole they re free to autoconvert what they want including smileys copyright signs signatures etc But what about developers who want a well defined behavior simple to describe and to understand If Creole is ambiguous and requires too much ad hoc processing to guess what the user means they won t use it YvesPiguet 2007 Feb 28 This is my understanding if you find any of http https ftp mailto then go on till the first space tab or newline everything in the middle is a url Well almost If the last char is some punctuation it s not part of the url http https ftp gopher news mailto n t w But yes the intended behaviour should be defined more precisely Michele Tomaiuolo 2007 02 28 I d like to note that when scanning the text which is

    Original URL path: http://wikicreole.org/wiki/Talk.ItalicsAndUrlAmbiguity (2016-02-11)
    Open archived version from archive



  •