| At line 1 added 4 lines |
| [{TableOfContents}] |
|
| == General == |
|
| At line 35 changed one line |
| !Collision analysis for images |
| == Collision analysis for images == |
|
| At line 166 added 285 lines |
|
| == 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 [[JSPWiki:WikiCreole|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 are completely different, and it's impossible (or just very hard and awkward) to use the same solution for all of them. Actually, I have a hard time imagining a solution for tables that wouldn't be based on using varied separators for changing attributes of single cells (and maybe special content of cells for spanning). |
|
| -- [[RadomirDopieralski]], 2007-Aug-30 |
|
| What's wrong with using plugin syntax instead of extending image syntax? |
|
| //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?// Do you mean a separate style sheet? Not always practical. But I don't advocate table extensions, I just don't like the idea of extending image syntax, then links, and then the wish list will continue growing. I'd prefer a generic way to add attributes, or to stick with what we have now: plugins. |
|
| -- [[YvesPiguet]], 2007-Aug-31 |
|
| The {{{{{...}} }}}markup was from the start supposed to be used for transclusion of various objects: Creole is defining only images, because it's the only case common among wiki engines, but I don't see any reason to use completely different markup to include e.g. a movie or an SVG picture. |
| Differentiating markup between "constructs that are defined in Creole" vs. "constructs that are not in core standard", even when there are little differences in semantics and use cases seems to me to burden the design with unnecessary "branding" information that users doesn't give a damn about. |
|
| On the other hand, using consistent Creole-like markup for particular wiki engine's native markup is going to actually strengthen the ideas behind Creole and increase ease of use and habituation. The markup for a particular element should be influenced by many factors, but "whether it's in core creole or not" is not one of them. |
|
| "How do I include an image?" -- "Use Creole's standard markup." |
| "How do I include and resize an image?" -- "Use one of 700 custom plugins that are completely unlike anything like Creole. Actually, you can use the same plugin for including normal, non-resized images too -- you don't have to learn Creole this way." |
|
| Note also, that all the "extending" we need is adding the rule about the second pipe character ending the comments. All the rest is just an non-standard extension to Creole. We don't define any actual parameters. We don't define any format for them. We just leave place for them to be introduced. |
|
| There is one more thing: this is a need that came up during actual use of many wikis by many hundreds of users. It's not proposed because someone thinks that Creole doesn't "feel round" without it, or because someone likes this particular solution more than others, or because someone would like to change all the existing wikis in the world to make them more "intuitive" and WYSIWYG-like. It's a purely practical thing that is needed in a number of particular cases. |
|
| -- [[RadomirDopieralski]], 2007-Aug-31 |
|
| I see your point, but the same argument applies to other elements, such as tables and headings (and pre blocks as indicated by one of your own proposals), doesn't it? |
|
| -- [[YvesPiguet]], 2007-Aug-31 |
|
| It surely does. |
|
| -- [[RadomirDopieralski]], 2007-Aug-31 |
|
| As far as the headings are concerned, there could be {{{== heading text | more stuff ==}}}. |
|
| For tables, this does not work, as tables already use {{{|}}} as column separator. But, for this discussion, we could just ignore tables, as we already have {{{|}}} as separator for links and transclusion, so they already have a different use of {{{|}}} than tables. |
|
| Anyway, as there does not seem to be a fast decision here soon, but I'll have to go on soon due to the moin 1.6 release schedule, I'll just use the proposed method and don't wait any longer. |
|
| As the moin wiki parser does not need to be creole compatible (it can be just "inspired by creole"), this is no big problem in that case, although being able to stick to the creole specs would have been the preferred way for me. |
|
| -- [[ThomasWaldmann]], 2007-09-08 |
|
| --------------- |
| Refactored from Talk: |
|
| Hi all, |
| As you may know, I try to implement the exact Creole 0.6 specification. In the links section, I found "At least images inside links must be supported." |
| Does this mean, that the link description could consist of exact one picture? Or does the specification allow multiple images, or text mixed with an image, in one description? Is an image (inline) in a table cell allowed? It was not mentioned in the specification. |
| Thank you very much for your reply! |
|
| -- Martin Junghans, 2007-04-30 |
|
| I read it that the spec allowed for multiple images or text mixed with an image, just like HTML. Inline images are allowed in table cells. |
|
| -- Chuck Smith, 2007-May-02 |
|
| --------------- |
| A few comments on images. |
|
| 1. The test case I found (I think here) gave: |
|
| This should be a flower with the ALT text "this is a flower" if your wiki supports ALT text on images: |
| {{{[{ImagePro src='Red-Flower.jpg' caption='here is a red flower' }]}}} |
|
| Couldn't work out what that was supposed to do but {{{ {{Red-Flower.jpg}} }}}seemed sensible/ |
|
| 2. Using Mozilla, **IT IS ESSENTIAL** that the title is set so that the alternative text displays when you hover over it as unlike Mico$oft IE the alt tag is not displayed by default. BY DEFAULT, you put in an image expecting people to be able to view it, so the DEFAULT use of the text should be for the DEFAULT use i.e. the hover over text. |
|
| Or to put it another way, in the vast majority of cases the 'alt' and 'title' tags should be identical by DEFAULT and it should be an option to include a separate title tag. |
|
| 3. What on earth does:- |
| {{{ |
| [[some link|{{myimage name}}]] - if you click on the image, will goto "some link" |
| [[http://example.com/|{{myimage name}}]] - same as above: picture links to url" |
| }}} |
| mean?????? |
|
| What is {{myimage name}} when it is at home? For my example is it "Red-Flower" or "Red-Flower.jpg" or some kind of internal tag?? |
|
| Isonomia Ides of April 2007 |
|
| Reply to Isonomia: |
|
| 1. This isn't defined in Creole 1.0. |
|
| 2. Seems to me like an implementation issue. |
|
| 3. //myimage name// is the link to the image, usually with the same syntax as what's accepted as double-bracketed links. Whether it must be a valid relative or absolute URL or something else depends on the application and isn't defined in Creole. The string "myimage name" shouldn't be understood as an illustration of the required syntax. |
|
| -- [[YvesPiguet]], 2008-Apr-28 |
|
| YvesPiguet ... all standards stand or fall on their implementation. |
|
| I've got the test document that I have seeming to work in its entirety (?). The 'implementation' that seems sensible is as follows:- |
|
| E.g {{{ {{Red-Flower.jpg|here is a red flower}} }}} |
|
| # When the text is given the title and alt tags are both alt = "here is a red flower" title = "here is a red flower". |
| # When the text is not given {{{ {{Red-Flower.jpg}} }}}the alt tag is: alt = "Red-Flower.jpg" , but the title is: title = "" |
|
| The result is that on both Firefox and IE6 the hover over function will return the same text (whereas if the title tag is not set the implementation will mean that IE and firefox differ (although I supsect it is a failing of IE rather than firefox). |
|
| However, if text is not given, then it would be better not to display the file name, when you hover over it. |
|
| -- [[Isonomia]], 2008-Apr-28 |
|
| YvesPiguet, on the {{{ {{some link}} }}} thing. Because I didn't understand it, Ive assumed "some link" is just a url and is the same as the two preceeding image links on the page. Logic, however tells me that the two are not the same as it would be extraordinary on a page of around four lines to use two different naming conventions for the same thing. |
|
| I hope these comments help. |
|
| -- [[Isonomia]], 2008-Apr-28 |
|
| I agree; I've put "myimage.jpg" everywhere to be clearer. |
|
| Concerning the use of image text, I'm not an expert in cross-platform compatibility. But I believe it isn't the purpose of Creole to specify what the exact translation to HTML should be. By default, [[Nyctergatis|NME]] image text is put in the alt attribute. |
|
| -- [[YvesPiguet]], 2008-Apr-28 |
|
.