Template talk:Flickr image xhtml 1.0 strict
| This is the discussion page for Flickr image xhtml 1.0 strict. Click here to start a new topic.
|
Can you explain on the google mailing list what changes you are planning for this? I want to make sure that you and Steve work together on future evolution of the Flickr template.--Vox 07:36, 25 April 2011 (PDT)
- I plan no changes, I try to fulfill the wishes of the XHTMLists roaming around here.
- Just see template page validation (XTML strict). The errors shown are in the framework of Mediawiki, not in the page as designed by me. So the core is strict XHTML, but that's useless because MediaWiki wraps it in XHTML(strict)-incompatible code!
- Seeing the limitations by strict XHTML leaves a load of doubts if that could be a goal. A main example is that the "align"-attribute shall not be conforming XHTML (except XHTML Transitional).
- MediaWiki just supports XHTML Transitional, see http://www.mediawiki.org/wiki/XHTML
- After all I definitely can NOT recommend to switch Template:Flickr image to strict XHTML since it would loose a feature because of the alignment limitation. It must be foolish guys who develop such incompatible standards. U. Kulick 08:35, 25 April 2011 (PDT)
- This template is very simple. It consists of a table. The table consists of two rows. Each row consists of one cell. What all of this boils down to is: one unit on top of another unit. That's all. Table markup seems a curiously old-fashioned method of achieving this. True, nothing about the table infringes the XHTML 1.0 Strict DTD; but lack of any description of tables here implies that they're the same as in HTML 4.01; for that, they're described here; this in turn makes it clear that tables are for a different purpose. So to me it seems bizarre to call this misuse (in W3C terms) of table markup "XHTML 1.0 Strict". Zuleika 09:08, 25 April 2011 (PDT)
- The purpose of tables is just how they are actually used. Any thought that a nicely page-structuring mark-up syntax like that for tables shall NOT be used for nice page structuring is useless. U. Kulick 09:26, 25 April 2011 (PDT)
Now we have a table-free Flickr_image template. That's just because the sample above didn't work with syntax for an unsized table. Thanks to User:Zuleika for delivering the decisive piece of code. U. Kulick 11:11, 26 April 2011 (PDT)
Here a comparison with the original template Template:Flickr_image in reverse size order
|
| Camera image example image by Laurie.pettitt (Image rights) |
|
| Camera image example image by Laurie.pettitt (Image rights) |
|
| Camera image example image by Laurie.pettitt (Image rights) |
new and old variant w/o all optional attributes in a frame and a double image sample (new and old template) (now the problems of a DIV solution are almost solved)
 
|
| same with old template images by Uwe Kulick (Image rights) |
|
|
|
added at 00:08, 27 April 2011 by U. kulick
- I do not understand you at all. Although you say now we see the problems of a DIV solution, the wikitext here contains a grand total of zero (0) DIV tags. (More precisely, I am now editing this version of the page.)
- Oh yes, the XHTML page that results, and that is displayed by a browser, has a lot of DIV tags. (And it has a lot of tables too.) But I thought that you were talking about edits to wikitext made by human editors. If I'm wrong, please correct me.
- Please explain below just what it is that you want to do with the flower and other photos above. Then perhaps somebody can work out whether table-free markup can accomplish this. Zuleika 02:50, 27 April 2011 (PDT)
- Here it is, the table-free markup. The old template with table structure is still rendered a little better when You narrow the window. It renders the caption in a nicer distance to the picture. But the general rendering problem for the caption is solved now in the new template. The centered image application variant is now optimized for ..._m.jpg images (medium size Flicker images). The approach is still experimental. U. Kulick 09:57, 27 April 2011 (PDT)
Centered image
Can you please explain this portion of code: width:{{#if: {{{image2|}}} | 500px | 250px }}; ? It has the curious effect of making the "image_align=center" option valid for 250px-wide images only, and gives the following result with a larger image:
--NihonCamera 08:52, 4 May 2011 (PDT)
- The Template:Flickr image is slightly better, especially when handling centered images. The attempt to make the same with strict XHTML 1.0 makes us dependent of dirty tricks. The main trick is to have an item of a certain size enclosed in the div since that div must have almost the same width. The medium Flickr images are 240 Pixels wide, and the enclosing div is 250px, except when image2 is defined. Then the div width is 500px. The reason is that circumvention of the non-strict attribute align which we can use with no problem in Template:Flickr image. Thus I recommend the center alignment with this new Template:Flickr_image_xhtml_1.0_strict only for medium-sized Flickr images.U. Kulick 12:04, 4 May 2011 (PDT)
- Can you describe exactly what is the problem with the following two examples, with div and with table, not using the align attribute?
Camera image example (with div).
Image by Laurie.pettitt. (Image rights)
- --NihonCamera 00:49, 5 May 2011 (PDT)
Camera image example (with div).
Image by Laurie.pettitt. (Image rights)
- I added a border to the sample above to show where the div is located. If You want to have it located in the middle of the image You must make it narrower by giving it a width. If You want to have it floating on the page like a table object You must guarantee that the div's contents is not wider than the div's width definition. That's the "dirty trick" necessary to make a clean image placement template which is based on a div solution like strongly wished for highly philosopical reasons by some project mates, and which is compatible to Template:Flickr image, thus enabling centred alignment. As the name of this template implicitely says: It is strictly XHTML 1.0. This is an attempt to fulfill XHTML dreams of some project mates too. It's good enough now to replace Template:Flickr image. But centred image alignment will be a compromise because it's restricted to application of images which are 240px wide! U. Kulick 08:17, 5 May 2011 (PDT)
- But I do not want a border around the div, do you? Why should the div have the same width as the image, and why should the div have a fixed width? Who cares that it extends all the way on both sides, provided it is invisible when using the template??? --NihonCamera 09:26, 5 May 2011 (PDT)
- Don't worry, I don't want a border, too. I used that border to explain You what's the problem. But it was just the first part of the answer.U. Kulick 10:40, 5 May 2011 (PDT)
table vs. div
|
|
| Camera image example (with table). Image by Laurie.pettitt. (Image rights) |
- The example with a table arguably looks slightly better because of the spacing between the image and caption. Here is another example with div achieving about the same effect:
Camera image example (with div).
Image by Laurie.pettitt. (Image rights)
- --NihonCamera 00:49, 5 May 2011 (PDT)
- That's definitely not the solution. Let's pair the sample with a smaller image on the right side:
Camera image example (with div and a longer caption with much more text text text text text).
Image by Laurie.pettitt. (Image rights)
- That's better:
Camera image example (with div and a longer caption with much more text text text text text).
Image by Laurie.pettitt. (Image rights)
- The trick: I've sized the div in the middle to width 500px. Thus the caption is centered as wanted. If the wiki template syntax wouldn't be so lousy it would offer string-functions to enable ifeq-requests on parts of the JPEG-filename. With such ifs we would have the perfect solution for all image sizes. U. Kulick 10:42, 5 May 2011 (PDT)
- I'm starting to understand what you mean (I just ran into the same problem in the sandbox). This is problematic indeed: the floated element offsets the position of the image, but not of the caption below, hence the caption does not fall right under the image. Of course this inconvenient is eliminated when using a table. --NihonCamera 10:56, 5 May 2011 (PDT)
I enhanced the template by a div for the caption. code looks ugly, but therefore keeps compatibility to Template:Flickr image. Thus we have the caption in nicer distance to the image like with the table solution.U. Kulick 10:48, 5 May 2011 (PDT)
plainlinks
I read U. Kulick's comment and reread it and reread it, and I think that what he has in mind is what's pointed out below the first image within "Other block elements", but I'm not sure.
Everybody's busily using class="plainlinks". This is interesting. I quote shared.css:
/* Plainlinks - this can be used to switch
* off special external link styling */
.plainlinks a {
background: none !important;
padding: 0 !important;
}
I wonder how we ever benefit from "external link styling" (i.e. the addition of the little box-and-arrow graphic). But let's assume that we do, and that we do want it on by default. Note the specification: ".plainlinks a"; this means a link as a descendant, no matter how distant, of anything of class "plainlinks". So if we wanted, we could put entire sections, or indeed entire articles, within <div class="plainlinks"> ... </div>, and within that not have to bother with any further mention of "plainlinks". -- Hoarier 01:32, 5 May 2011 (PDT)
- You need not to wonder about what You know since years: An external link has a slightly other look in this wiki than an internal link. But in the most cases of image placement on wiki pages the image back-links to Flickr shall not look like external links. class=plainlinks helps, and the Flickr image templates use that class too.U. Kulick 10:33, 5 May 2011 (PDT)
