The problem with the first format is that it would produce an img tag without an appropriate alt attribute - and thus not be valid XHTML, nor accessible.
IMO, only the second format should be allowed and the use of an alt parameter (attribute) enforced.
Comment by david.bus.ucf.edu
2004-10-07 14:35:51
I see no problem with the first format, if a slight modification is applied to it, like [[http://uri.to.the.image/image.png ALT for the image]]. If the image is not to have alt, them default alt to "".
Comment by JavaWoman
2004-10-07 17:22:03
[[http://uri.to.the.image/image.png ALT for the image]] would work, I think - as long as ALT (or alt) is required. No defaults (in compliance with WAI guidelines) but purely decorative images _should_ have an empty alt attribute, so "" (explicitly defined rather than defaulted) would work for that.
Then again - purely decorative images on a WikiPage?? Requiring alt (even other than an empty string) may actually help to discourage those :)
Comment by JsnX
2004-10-08 00:15:01
Inline images do have an alt defined. As JavaWoman points out, it is not valid without an alt parameter, which I picked up on a few versions back. All inline images in Wikka have the alternate text "image" applied. Check the Google image above.
Comment by JavaWoman
2004-10-08 06:57:56
"All inline images in Wikka have the alternate text "image" applied". Unfortunately that will make thge code only *syntactically* valid, but not *semantically* valid. And in terms of accessibility it's just as bad as not having an alt attribute at all - someone with a screen reader will usually hear "image" for an image without an alt attribute - and for an image with the alt attribute "image" they will hear the same! It's utterly meaningless and unhelpful.
I pointed out that an image needs an _appropriate_ alt attribute: - that means either an empty string for a decorative image, or a short text that can *replace* the image when it's not shown (or seen): it has to be something meaningful. There is no way you can produce a *meaningful* alternative with just a URL (as in the first syntax), which is why I'm pleading for that format being abolished, and the alt attribute in the second format made required.
- The HTML standard specifically states: "Do not specify meaningless alternate text (e.g., "dummy text")." - http://www.w3.org/TR/html401/struct/objects.html#adef-alt
- WAI - Web Content Accessibility Guidelines 1.0 - has a whole section devoted to this: Guideline 1. Provide equivalent alternatives to auditory and visual content. at http://www.w3.org/TR/WAI-WEBCONTENT/#gl-provide-equivalents
- And since a Wiki *generates* HTML, the WAI Authoring Tool Accessibility Guidelines 1.0 applies as well, in particular: Guideline 3. Support the creation of accessible content at http://www.w3.org/TR/ATAG10/#gl-prewritten-descs: "For example, prompting authors to include equivalent alternative information such as text equivalents, captions, and auditory descriptions at appropriate times can greatly ease the burden for authors." (there's more - read it!)
Comment by DavidKeltie
2005-01-18 17:41:04
How do you wrap text round an image with some padding i.e. so that the text doesn't run right up to the image?
Thanks
Comment by DarTar
2005-01-18 23:01:09
In the css class used for positioning the image (e.g., center) add a line like:
margin: 5%;
Note that in CSS markup "margin" means "external margin" while "padding" means "internal margin".
Comment by host217-43-109-50.range217-43.btcentralplus.com
2005-01-20 11:23:17
Great - thanks!
Comment by JasRandal
2005-04-13 14:50:30
Still experimenting here. I've uploaded images, but they don't show up. With just the URL, I get the word "image." With the URL in square brackets, says there's no info. With the ""{{image}}"" tag, just the alt text shows up. I even set the uploads directory to 777 with no luck, though I couldn't set the specific page directory to 777 for some reason. I did the upload through the ""{{files}}"" action. What am I doing wrong? Here's where I'm working: http://www.alcanceweb.com/wikka/SaoJosedosCamposSP
Comment by NilsLindenberg
2005-04-13 15:49:26
Take a look at AttachmentInfo for a solution (thx to JavaWoman)
Comment by 64-51-116-24.client.dsl.net
2005-06-03 17:47:18
I took a look at AttachmentInfo but I don't see a solution. Is it the mod_rewrite thing? Create a placeholder page?
Comment by NilsLindenberg
2005-06-03 17:53:32
You have the same problem as JasRandal? I.e. not possible using the uploaded images with the image-action?
Comment by 64-51-116-24.client.dsl.net
2005-06-03 18:00:09
Well, I'm not sure. I created a page, added a {{files}} control. Uploaded an image file, then added an {{image}} control to display the image. All I got was the word "image". I can link using the absolute url (http://localhost/wikka/uploads/MyPage/myimage.gif) but I figured there would be a relative path that could be used.
Comment by NilsLindenberg
2005-06-03 18:14:08
"the image action is perfectly able to handle relative paths - but if mod-rewrite is active in the directory it sits in, that takes priority before the imag eaction even gets at it" (quote from JavaWoman)
So if you have mode_rewrite turned on, it is not possible.
Comment by 64-51-116-24.client.dsl.net
2005-06-03 19:03:26
I have "rewrite_mode" => "0". Is that what you meant? It seems as though I don't have rewrite on, so what should a relative link look like? Can you give me an example of an {{image}} url that points to a file attached to the same document the {{image}} tag is in? Thanks.
Comment by JavaWoman
2005-06-03 19:26:37
Actually, no - "rewrite_mode" => "0" only states whether Wikka is taking advantage of mod_rewrite if it's supported on the server - not whether mod_rewrite is *active* on the server which is determined by httpd.conf and .htaccess files.
What's confusing is that with the default .htaccess file we distribute with Wikka in the install directory, URL rewriting is actually *taking place* for Wikka if it's supported by teh web server.
It's certainly possible for files (like the image action) to refer to pages in a subdirectory but when the server supports URL rewriting this will only work this is disabled for that subdirectory *first* - otherwise you'll get an "endless" redirection (until the browser gives up or crashes). To prevent this from happening, copy the .htaccess file from the /images directory to whatever other directory you want to use to for uploaded images to link to.
See also http://wikka.jsnx.com/HtaccessConfig for furture development that will make this a lot easier.
Comment by JohnC
2006-04-03 10:26:56
I've got a question about images in wikka. Is rollover included? If not, is there a simple way of including that on a page?
Thanks in advance!
Comment by BlueShirt
2006-08-06 09:54:25
Option #1 (for inline images) no longer seems to work. Does anyone know if there is still a minimalist path to inserting images?
Comment by NilsLindenberg
2006-08-06 13:32:20
Depends on what you would call minimalist. It is best to use the image action (with the alt param which will become mandatory in future versions).
IMO, only the second format should be allowed and the use of an alt parameter (attribute) enforced.
Then again - purely decorative images on a WikiPage?? Requiring alt (even other than an empty string) may actually help to discourage those :)
I pointed out that an image needs an _appropriate_ alt attribute: - that means either an empty string for a decorative image, or a short text that can *replace* the image when it's not shown (or seen): it has to be something meaningful. There is no way you can produce a *meaningful* alternative with just a URL (as in the first syntax), which is why I'm pleading for that format being abolished, and the alt attribute in the second format made required.
- The HTML standard specifically states: "Do not specify meaningless alternate text (e.g., "dummy text")." - http://www.w3.org/TR/html401/struct/objects.html#adef-alt
- WAI - Web Content Accessibility Guidelines 1.0 - has a whole section devoted to this: Guideline 1. Provide equivalent alternatives to auditory and visual content. at http://www.w3.org/TR/WAI-WEBCONTENT/#gl-provide-equivalents
- And since a Wiki *generates* HTML, the WAI Authoring Tool Accessibility Guidelines 1.0 applies as well, in particular: Guideline 3. Support the creation of accessible content at http://www.w3.org/TR/ATAG10/#gl-prewritten-descs: "For example, prompting authors to include equivalent alternative information such as text equivalents, captions, and auditory descriptions at appropriate times can greatly ease the burden for authors." (there's more - read it!)
Thanks
margin: 5%;
Note that in CSS markup "margin" means "external margin" while "padding" means "internal margin".
So if you have mode_rewrite turned on, it is not possible.
What's confusing is that with the default .htaccess file we distribute with Wikka in the install directory, URL rewriting is actually *taking place* for Wikka if it's supported by teh web server.
It's certainly possible for files (like the image action) to refer to pages in a subdirectory but when the server supports URL rewriting this will only work this is disabled for that subdirectory *first* - otherwise you'll get an "endless" redirection (until the browser gives up or crashes). To prevent this from happening, copy the .htaccess file from the /images directory to whatever other directory you want to use to for uploaded images to link to.
See also http://wikka.jsnx.com/HtaccessConfig for furture development that will make this a lot easier.
Thanks in advance!