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.Linebreaks
    Discussion Promotion Recent Changes Talk Index wiki node Sandbox Copyright C by the contributors Some rights reserved license BY SA Sponsored by the Wiki Symposium and the Nuveon GmbH view find Quick search type ahead Recent Searches Clear Talk Linebreaks Your trail Talk JohnMcClure Home Talk JuanMtnezPineda Home Talk Keyboards Home Talk LanguageChanges Home Talk LineBreaks Home View Page Discussion V iew A ttach I nfo discussion moved to Talk

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


  • Talk.Link Extensibility Proposal
    just my preference but I always added this kind of functionality using macros in MoinMoin sure it s a little more awkaward to type Link Page Text Extension Extension but you have a generic mechanism for extending that s guaranteed to not collide with anything If you extend the links then soon you will have to extend tables to allow styling them headings blocks of preformatted text for syntax coloring etc and what was a well known standard markup becomes some complicated replacement for HTML RadomirDopieralski 2007 02 26 I agree that if a Wiki has such a functionality it may be used as an alternative At least for rare and special kind of links like with pop up descriptions or window targets However I and I believe many are really waiting for links to become semantic I think placing semantic web info there would soon mean just forget that you had any old style markup I think the proposal to alert developers that in future creole there may be more than one which their parsers should ignore is easily done and does not cost Gregor Hagedorn A link spec can be extended on the front end too I have a link syntax for instance that precedes and annotation operators with an xml id value and values for the rel and rev attributes of the anchor tag On the back end I use plus signs for global attributes such as style and ones pertinent to generated HTML and I use parentheses for non formatted author notes id01 rel path rev path title path URL label style s1 v1 s2 v2 comment Extensibility options for each syntax item in Creole should be documented to allow parsers to ignore unwanted positional parameters a syntactic hazard offset by the tactic of special characters

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

  • Talk.Links
    nobody will kill you if you skip them at the worst you get some users complaining that they miss it RadomirDopieralski 2007 Apr 28 It s only mandatory if you have an implementation of InterWiki in your wiki If you don t use InterWiki you can safely ignore it ChuckSmith 2007 Apr 30 Mailto links I propose the usage of mailto test example com to be rendered in output as mailto test example com for email urls even if this is not standards friendly Any opinion about this Is there a better place where to post this suggestion Or should we postpone the discussion to the next Creole specification DanieleC 2007 Jul 03 Why YvesPiguet 2007 Jul 03 In WikiOnAStick there is no automatic URL decoration so external URLs with protocol have to be specified using square brackets protocol uniformresourcelocator if we d parse mailto test example com as test example com a page titled mailto something would never get the internal wiki hyperlink Using the double slashes also on mailto protocol would prevent this This is our solution to our problem I still have to understand if it has relevance in WikiCreole DanieleC 2007 Jul 05 Inner Page Anchors and Links For inner page anchors the following syntax is recommend 1 Suggested HTML a name 1 For inner page links the following syntax is recommended 1 text Suggested HTML a href 1 text a Note without optional link text using the results in an inner page anchor However when using the optional link text using the results in a link to an inner page anchor JohnCook I d prefer a clearer way to disambiguate anchors and links so that links don t need text e g Chater1 for anchor and Chapter1 or Chapter1 Chapter 1 for link The at

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

  • Talk.Links Reasoning
    like in MediaWiki If the URL does contain a whitespace however it should either be encoded as 20 or the pipe character could be used instead as fallback option for the separator FND 2007 12 14 11 56 UTC I ve found that a pipe character makes it easier to extend the link syntax e g text link attributes The text often has spaces so therefore using space as a separator char makes extension difficult My preference is of course text first link next I think we should ignore what HTML does since HTML was never designed to be human readable and the way it works is an artifact of the language structure itself HTML syntax should not be used to justify any design decisions on WikiCreole unless it would result in something which would be impossible to do in HTML CSS of course JanneJalkanen Okay if you want to add more parameters then you absolutely need a special separator like the pipe char As for text first link next I guess that s a personal preference I personally wouldn t like that at all it s one of the few things I hate about TiddlyWiki That s mainly because I usually grab a URL first and only think about a title description afterwards FND 2007 12 14 18 22 UTC Please note that for consistency the same syntax is used both for external and for internal links Many wiki engines allow spaces in the page names and not all of them encode the space as or similar character Of course it s up to the specific wiki to translate the spaces Many modern web browsers will not display the encoded urls in the location bar instead they attempt to decode them and present the user a human readable decoded

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

  • Talk.List Markup Alternatives
    different markup for just and different for just that the users don t have to care RadomirDopieralski 2007 Mar 04 I agree that it somehow makes sense to use the indenting markup for lists also But it doesn t look very nice and it s not intuitive Both bulleted lists and hyphened lists just look like lists and are used that way in plain text already On the other hand it seems there is no list markup that fulfills all our needs of GoodPractices SteffenSchramm 2007 Mar 04 Usually things that make sense are intuitive I d rather say that it s not widespread popular widely known traditional which is kind of related to intuition of course But if we had the basic two three levels handled with asterisks and hyphens plus numbered lists the additional nesting levels could be left in additions together with the indentation markup Jus a loose idea I m not advocating it RadomirDopieralski 2007 Mar 04 I d like to note that the markup for bold in Creole that we agreed upon is double asterisk not single asterisk hence not every markup using the asterisk will conflict with it in particular it is certainly possible to avoid collision using some of the features described on this page That s why I used the word may On the other hand the hyphen is commonly used in text both alone and in combinations making the conflict inevitable and requiring escaping no matter which features from among described on this page are used Radomir Dopieralski 2007 Mar 06 You sound like we would open the burning hell if we use hyphens Conflicts with hyphens only occur if they are used as the first character in a line after a hard line break Don t let us get into bikeshedding again here we already discussed that in HyphenListMarkupProposal Let s keep cooling down the issue I just would like to make sure here with this post that my opinion is heard as much as yours Christoph Sauer 2007 Mar 06 Trouble is I hardly see any uses of a hyphen at the beginning of a line except for wiki signatures horizontal lines and Polish dialogs The question is Which is more annoying hyphens or asterisks Chuck Smith 2007 Mar 07 You can add French dialogs Actually I wouldn t mind But I don t mind keeping left aligned asterisks either and bold s double asterisks following a space for disambiguation because we ll also need such a rule for monospace We re running out of ASCII characters anyway so here again I d prefer a simple rule double stars and double sharps at the beginning of lines are list markers in the context of lists start with a space for other uses or alternatively double stars and double sharps at the beginning of lines are list markers if and only if they are followed by a space rather than three exceptions one for sharps one for rules and one

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

  • Talk.List Markup Decision
    Home View Page Discussion V iew A ttach I nfo I don t think that the character used is in itself that important here I m all for dash minus for single level lists for example Radomir Dopieralski 2007 Mar 08 Space required only after a second level bullet list item doesn t correspond to what s implied in BoldAndListsAmbiguity That s what I d implemented first before failing the

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

  • Talk.Lists
    is a second level element Option two with dash Option 2 This is a bold text element 1 element 2 this is a bold text element 3 this is a second level element Christoph 28 Aug 06 There is a somewhat weird behavior of some web browsers so far tested it only on the Gecko based ones that convert first level bullets to some characters when copied as text So far I ve seen and used and I m not sure what it depends on I know it might not be very important As for conflicts with bold and hr I think the hr conflict can be resolved easier is this text bold or are these just two second level list items This is a fourth level list item This is a horizontal rule It must be alone on a line Also note that 4th level list items are going to be rather rare One problem with dashes for bullets is for lists of numbers 10 15 32 Are those number positive or negative This can be confusing I know that YAML also uses dashes for lists maybe we could learn from their experiences RadomirDopieralski 2006 08 30 I like the idea of dashes as a separate character from asterisks for bold As you note this allows for bold within a list easily Hey I d like the idea of different characters for different actions where possible right across Creole MarkGaved 31 Aug 06 I wonder what is the rationale behind forbiding white space before the bullets I can guess it s about ambiguity but I d like to have it written I can tell that I often indent lists just by reflex and also many text editors do that automatically RadomirDopieralski 2006 09 01 The next revision of the recommendation should be explicit about multiline list items and empty lines between list items AlexSchroeder Should there be a limit to the nesting depth of the lists It would greatly simplify writing regular expression based parsers And there is a limit to what can fit on a page anyways RadomirDopieralski 2006 09 04 i like the idea of limiting it to 4 levels someone noted at the workshop I think it was Janne that more than this is considered bad style in writing anyway Christoph 4 Sep 06 If we choose to support multi level lists these examples could be useful Good One Two Three One One One One Two One Two One Two One One One One Two One Two One Two Some paragraph text One Some text One Two One Bad Zero One One One One One One Zero Two One One Two One One One Some text Zero One Zero One Anon Christoph convinced me that allowing leading whitespace is a good thing When I read other blog entries however I see that you reached a totally different conclusion whitespace before not allowed bullet list number list See http www blogschmog net blog p 420 What s

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

  • Talk.Lists Reasoning
    are elsewhere Also it becomes much harder to fool naive users any change to the structure is unjustified during a vote since the plugin does the job of ordering at HTML presentation so you ll spot anyone mucking around easily and can lock the vote receiving structure if required Changing the list of option s would for instance invalidate the vote unless until it was restored to a previous state Variants could support prefernence and allocation or other types of votes Anonymous 2007 02 05 What you are describing is totally up to the plugin you envision and Creole has nothing to do with it We certainly can t require such a plugin to be present in all wikis supporting Creole Note that both input and output is up for the plugin creator to decide RadomirDopieralski 2007 02 05 Reserving combinations of the two list characters for extensions of this kind is not the same as requiring any such thing to be supported Interpreting these extensions as ordinary ordered lists is perfectly valid default behaviour and it makes it very easy also to manually track the votes that are going on everywhere So there s utility to reserving these character combinations for this even without a plugin and the default behaviour when there is no plugin at all present is graceful enough it simply defaults to the way this is done now Plugin creators will flock in to do a better job if they see a lot of demand and lists presented specifically as votes ranks polls surveys will attract them to do a good job supporting the real need Anonymous 2007 02 05 I don t think it is the role of Creole to encourage writing specific plugins Personally I never ever encoutered the use cases you describe in a wild on any wiki I know Moreover the markup you re proposing conflicts with existing Creole markup for mixed lists first level bullet list second level numbered list RadomirDopieralski 2007 02 05 Creole certainly does have an obligation to reserve characters and respect some patterns of use like use of colons and slashes already established by W3 and so on Reserving combinations of the two list characters for extensions of this kind is not the same as requiring any such thing to be supported Interpreting these extensions as ordinary ordered lists is perfectly valid default behaviour and it makes it very easy also to manually track the votes that are going on everywhere So there s utility to reserving these character combinations for this even without a plugin and the default behaviour when there is no plugin at all present is graceful enough it simply defaults to the way this is done now Plugin creators will flock in to do a better job if they see a lot of demand and lists presented specifically as votes ranks polls surveys will attract them to do a good job supporting the real need Anonymous 2007 02 05 on encouraging writing plugins

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



  •