Description

It would be nice to have all the <img> tags generated by MoinMoin belong to one of following classes:

• link -- for link icons

  • #page a img ?

    • This will also catch all the "action" icons in RecentChanges, drawings (drawing:), and any linked images the theme maker will move intothe page area.

      • There is recent changes class, used to design the rc table - you can use it to select those images.
        • What with drawings?

• smiley -- for smileys

• glyph -- for other inline symbols like arrows, stars, priorities, etc.

  • How they are different form smileys?
    • See below.

  • #page p img ?

    • Will also catch attachements, drawings, smileys and some icons.
      • Not if attachments and drawings have their own class
        • Yes, that would be an improvement

• icon like <!>. They are different form smileys and glyphs, at least the way they are used in this and similar wikis.

  • How they are different form smileys?
    • See below.

• attachment -- for attached images

  • Add class in the formatter, best put all attachments - not only images - in a <div class="attachment">

• button -- for the tool icons, clicked to perform actions

  • Add class in theme theme.py module

    • They are produced by macros such as RecentChanges.

Purpose

As it's now, it's very hard to write a CSS that would do anything with images. All you can do is to apply different styles for images outside the #page and inside it.

But suppose you wanted to:

• have a border around attached images
• have a width limit on attached images
  • width limit does not work on all browsers

    • Displaying images and colors doesn't work on all browsers too. Does it mean MoinMoin shoudn't use colors and graphics?

      • We should not base the design on stuff that is not well supported
        • Sure, there should be a mechanism to limit the width of images in the html generation code, and that would be much more universal.
        • You're not "basing the design" on it -- it won't look worse in the IE than it looks now -- it will only look better in w3c-compliant browsers.

• have the warning, error, etc. icons ( ) floated left

  • Why they should float? this will will prevent using them like I did here - this icon would float instead of stying inline.

    • I'm not saing they should necessarily float. It's an option. See below.
• have the attached images floated right

  • Use SectionParser or table with tableclass or tablestyle

    • Using tables is against W3C recommendations and cripples accessibility.
      • How does table cripple usability when you put a one cell one row table around an image?
        • The page becomes less readable and more complicated (also to read by automated parsers)
        • You're introducing non-semantic content.

    • SectionParser is cool, but it's "rocket science" for some users.

• have the link icons and smileys scale with text

Both are not really needed:

• have the link icons change on mouse hover
• have the tool icons change on click

etc.

• Maybe not needed, but look nice and increase responsiveness by giving additional feedback. It's a decission of the theme maker whether to use them or not.
  • It also increase the number of images served and the web traffic that each page generate, so they should be used with care.

    • Of course. But it's the decission of the admin, and it would be nice to have such an option -- especially for some light-weight wikis intended for young communities that thing such features are cool -- not all Wikis are supposed to be information-only.

I'm not sure adding classes for all images is the correct solution - better check if we can add class for the element enclosing the images, which means much less classes needed.

I see this simpler structure:

1. user interface
   • out of the page - header, footer, sidebar

     • logo? -- RadomirDopieralski

   • in elements inside the page, like RecentChanges macro generate

   • in the message area (no icons used currently)
   • most image are used as buttons

     • there could be some used as status notification in the future (along with text, of course), or just decoration -- RadomirDopieralski

     • when writing my own themes, I give the icon images (or rather their <a> tags) distinct id's or classes, so that I can for example give them thick outline (as a bckground image) on hover. -- RadomirDopieralski

   • Most of them, not counting the message area and macros, are easily controlled from the theme. -- RadomirDopieralski

2. inline images, used inside the text like this

   • usually are not links

     • there are several ways they are used and there could be benefits from distinguishing them (see below) -- RadomirDopieralski

3. external images - attachments or urls
   • usually display a bigger image
   • are not links

     • drawings are links -- clicking them allows you to edit them -- RadomirDopieralski

   • are rarely used inside text -- RadomirDopieralski

-- NirSoffer 2005-11-12 13:16:02

Differences between glyphs, smileys and icons

These three "classes" of images I wanted to isolate are not that different form each other, at least with current way they are handled.

I wanted to separate them because they are different semantically, and as such they might require different treatment in the future, or might be treated differently by the theme. I will try to describe how they are different.

This idea is pawned by the belief that the page source should contain semantic information rather than control the looks. This might not apply to WikiWiki, which is much more of a WYSIWYG thing than normal web pages.

Smileys

It's a large class among the images used in MoinMoin. A class so large, that other images also have been sometimes called smileys.

They are emoticons, like >:-( :-D :-P

They are put into the text, inline, to mark it's emotional meaning.

They are somewhat similar to glyphs, but I think there are different requirements to make them 'work right'. They are based on psychological mechanisms, not only the ability to recognize them as distict symbols, like the glyphs. We want them to look nice.

Glyphs

Since the smileys code was alredy there, it got used to display several things that were needed, but coudn't be displayed without graphics. The glyphs are usually considered a part of the text -- letters and symbols that were not available, and so got displayed as images.

There are not many glyphs in current MoinMoin, but there are some:

Note, that some images like can be also sometimes used as glyphs, but this is rare.

I think it would be good to separate this group of images as a class, because this would allow to treat them a lot like text they appear in.

Icons

They are often found in books and manuals, used to mark tips, notes, exercises or important parts. In books they are often printed on the margin or floated left -- but it depends on the graphical design, they can be placed as other images as well. Most of the time they appear at the beginning of a paragraph. The whole paragraph is often marked in some way -- with border, background, etc.

In the MoinMoins I've seen so far, those images are used as icons:

They can, of course, be used as glyphs as well.

I think it would be nice to have this group of images separated, because this would allow to make them bigger, nicer and generally better suited to the function they perform. There would be needed a second set to use as glyphs, probably, at least with some of them.

After some thought -- this effect would be much better accomplished using custom sections, like this: http://labs.wmid.amu.edu.pl/

• -- RadomirDopieralski

CategoryFeatureRequest