Caption not going where I want it

As a general rule, it’s better not to advise that, because there should be no transitional sites around these days. It was a bridge for old, poorly coded sites hold their head up on the modern web. It’s better to face the reality that any site needing a transitional doctype should have been scrapped and rebuilt many years ago.

I hear the mantra and have a hard time buying it in the absence of supporting evidence.

As I recall, HTML4 transitional is a bridge between HTML4 strict and HTML4 frameset. It existed before the “modern web”, not because of it.

What is the recommended replacement for the target attribute, and how should the coder/user handle that effect?

Things like _target are still supported by browsers, whatever doctype is used, but it’s worth asking why things like _target were dropped from HTML. It’s because it failed usability tests, which showed that it confused a lot of people. There are JavaScript replacements for it, but again, that still begs the question of whether it should be used at all. It’s a pity it’s so hard to get the message out to the general community that you can easily open a page in a new tab with a simple key stroke. That’s vastly preferable to me than having it forced upon me.

Indeed opening a new page in a new window may be “forced” by the coder with the target attribute. So far in my life as a user, I don’t find that objectionable. I’d rather the programmer make an intelligently thought out direction rather than leave it to me to wish I’d known to open the link in another window. It is unreasonable to expect casual users to make that decision ahead of time, especially without a recommendation from the web page that effectively says “might be best to open in another window”. User’s rarely know if a link goes to another page on the same site, therefore the “back” button works, or links to another page with hooks to keep them there. Personally, I like the fact that SitePoint opens most links in a new tab. Javascript? or transitional _blank? who cares? I don’t give a hoot about religious badges. Solid code and reliable performance, YES! If the worse thing you can say about the transitional doctype is that it is a “badge”, that’s weak. It IS an established doctype.

And horse and cart is an established means of transport. :stuck_out_tongue:

Anyhow, _blank has been deprecated for a reason, so it’s worth being mindful of that.

Yes, big guy, I’m mindful of it. :slight_smile:

It’s important to me to emphasize the value of validation. In this case, that’s best accomplished with the transitional doctype. More experienced coders can understand and differentiate between errors that need to be fixed, like stray tags, and those that are less significant. Noobs haven’t learned that yet; so they make the page work somehow, and shy away from the uncomplimentary validator. I believe validation should be and is meaningful. “transitional”, IN THIS CASE, helps. Otherwise, I’d go strict.

I’m not pushing horses and carriages. I am picking my lessons, though.

When the page is finished change the doctype to strict, if preferred, and publish.

Gotta go. My cat brought me a fuzzy. She wants to play “fetch”.

Is there really any point in changing “strict” to “transitional” or “loose”, just to get a “flawless coding” certificate?
There may be other reasons to change from “strict” that I am not aware of and have a detremental effect, but at the moment it seems like the tail wagging the dog.

I know target has been dropped, and will replace it with the accepted alternative when I find it; in the mean time I’ll live with the validator’s disapproval. I’m hesitant to change to “loose” as it will also let other things slip past, and I probably would not want those things in.
I do strive for fault free coding, but sometimes you have no choice. The Google+1 button will increase in seo importance over time, but it is not accepted in “strict” coding for some reason; I could drop the “target”, but no way I’ll drop the Google+1 button.

Is there really any point in changing “strict” to “transitional” or “loose”, just to get a “flawless coding” certificate?

No.

A “flawless coding” certificate is not the purpose. The purpose is to reduce the distraction of the target attribute flags and bring more attention to “errors” that could be harmful, such as unmatched tags. It would be counterproductive to employ a “transitional” doctype if errors caused by other deprecated tags for which acceptable css solutions existed.

Over the years, I have never found an example where a 401 “strict” doctype worked and a “transitional” doctype on the same file producted unexpected results. There are plenty of knowledgable writers on the web who “deprecate” the transitional doctype, but, as I told Ralph, so far I have seen no evidence to substantiate their position. The problem with transitional, as you mentioned, is that it allows deprecated tags to slip into the code. You are astute enough not to allow that to happen. It does not send any browser into quirks mode and produce unexpected effects. That presumption seems to be based on fear (or maybe genuinely antiquated browsers) rather than evidence. If in doubt, change to “strict” before publishing for a “strict” housecleaning. You haven’t risked or lost a darned thing.

Consider it a temporary developmental doctype that serves an arguably useful purpose. If it doesn’t work for you, don’t waste your time with it. Your call. I use it frequently when the target attribute is found on the page, and absolutely nothing has ever broken, thus my choice.

The “target” attribute is likewise your choice. You expressed great hesitation about making ANY changes in your style of presentation and programming. I am sensitive to your hesitation and have no desire to push unrequested changes (thus the suggestion to use the transitional doctype). While examining your page, I clicked on a dozen or more of the links and found an equal number of tabs open on my browser (as expected, and each of which had to be closed) and wondered if that really serves the user, but it’s not an issue… it’s your design choice… so be it.

The Google button seems pretty clear as “error” flags go. Easy to distinguish from those that beg attention.

I consider myself something of a secular coder. Labels, mantras, fads leave me cold. Facts are my compass. It is adjusted frequently as I learn more.

I completed a structural revision of your page on my PC. Unfortunately, it is far more complicated (more layers of html tags) than I had originally envisioned; so it fails the goal of “Easy to Manage”. It’s very logical, but heavily nested… too different. Will try another approach if you’re still interested.


This measure addresses your original issue about the caption without considering your future plans.

Replace your html:


<div class="logo"><img src="http://www.boiler-breakdown-repair-london.co.uk/pics/GSR GIF 200.gif" alt="gas safe logo" width="200" height="200"
style="float: left; margin: .1em 1em 61em 1em;  "><br> CAPTION
</div>

With this:


<div class="logo">
    <img src="http://www.boiler-breakdown-repair-london.co.uk/pics/GSR GIF 200.gif" alt="gas safe logo" width="200" height="200">
    <p>CAPTION - Hey diddle diddle, the cat and the fiddle.</p>
    <img src="http://www.boiler-breakdown-repair-london.co.uk/pics/GSR GIF 200.gif" alt="gas safe logo" width="140" height="200">
    <p>CAPTION - Hey diddle diddle, the cat and the fiddle.</p>
    <img src="http://www.boiler-breakdown-repair-london.co.uk/pics/GSR GIF 200.gif" alt="gas safe logo" width="240" height="200">
    <p>CAPTION - Hey diddle diddle, the cat and the fiddle.</p>
</div>

Replace your css:


.logo {float: right; margin: 1em .1em .1em .1em;}

With this:


.logo {
    float:right;
    display:table;
    width:100px;         /* must be lte image */
    height:1100px;       /* fixed height; adjust to suit */
    padding-left:20px;   /* adjust space to left of "column" */
    margin:16px 2px 0px;
}
.logo img {
    display:block;
    padding-bottom:8px;  /* adjust space between image and caption, here */
    margin:0px auto;
}
.logo p {
    font-size:.8em;      /* size of caption */
    line-height:1.32;    /* a good idea, IMHO */
    text-align:justify;  /* style as desired */
    margin:0;            /* another good idea */
}
.logo p + img {
    margin-top:25px;     /* space above another image if preceeded by a caption */
}
.logo img + img {
    margin-top:50px;     /* space above another image if preceeded by an image without a caption */
}

NOTES:

The extra images in html are for demonstration purposes and are expected to be deleted.

The images in the floating column auto-center to the width of the widest image as do the captions.

The height of the div.logo is still fixed at whatever height you choose. pixels are a better unit of measure than ems in this case.

It is good practice to remove all spaces from the name of images. Use dashes, underscores, pluses or run the words together instead. (eg: GSR GIF 200.gif should be GSR-GIF-200.gif or thereabouts.)

Always try before you buy… (test thoroughly).

Deprecated elements and attributes were done so for a good reason many of them to do with semantics; separating structure (markup) from presentation (style sheets), e.g. “Separation of Concerns”, Content (HTML), Presentational (CSS) and Behaviour (JavaScript) - spawning windows is behaviour. Plus accessibly related issues. APPLET, BASEFONT, CENTER, DIR, FONT, ISINDEX, MENU, S, STRIKE, and U (all deprecated).

An advantage of applying none deprecated markup can be interoperability. Misusing the target _blank solely for spawning a ‘popup’ style window can become an accessibility and usability issue since it breaks the back button, etc. If you absolutely must open a link in a new window (or tab), explicitly warn the user with a clear indication that the page will open in a different window.

Though obviously you are supposed to use scripts if you want to spawn a new window not related to a frame and that is why Strict doesn’t use it. So it’s best to use unobtrusive JavaScript for the new window. Everything client side is under the control of the visitors to the site.

The ‘target’ attribute (when applied to an anchor) can be used in any Transitional document and typically is supposed to be associated with a Frameset hence why is has never been deprecated for Transitional documents.

Essentially the ‘target’ attribute is used with frames to specify in which frame the link should be rendered obviously you can have target on more elements than the anchor; _blank renders the link in a new, unnamed window.

Why historically people got upset about “target” attribute disappearing from Strict onwards is because it could also be referenced via scripting languages. In either case the anchor target was specifically designed for the Frameset rather than Transitional.

The user is a blackbox, if you use _blank for the sake of spawning then the ‘web author’ is essentially ‘dictating’ that the user will have to view the new page somewhere else. Leaving no direct means of getting back or focus or indication the new window has opened for that matter.

Looking at SPF links, I’d agree that the forum has members that login, in which case they may want to have more than one page instance open. Therefore if you wanted external site links to be opening in a ‘new instance’ then you could alter the browser configuration file to allow that or use client-side script. Thus those both user groups are catered for, i.e. user-agents with or without JS. Therefore the web author would allow the ‘user freedom’ instead of restricting user freedom and imposing the author’s own idea onto the visitor.

Going onto a tangent: Flock mentality? Allow the site to dictate their actions and thus many ‘mindless comply’ and resign themselves to a new window (or tab) spawning as ‘normal’ behaviour. Because they cannot; or do not know how to do otherwise; or are happy being oblivious; or don’t think for themselves.

I assume in essence what is being asked; is why would something as perverse as _blank have to be used when obviously JS is the appropriate tool? Thus this mystic figure of 5% sometimes touted (non JS enabled browsers) is likely to be the people that would prefer not to see a new instance being spawned by default. Thus those people can make up their own minds of how to open a new page. What is worse; when there isn’t indication that the link on many sites will attempt such a feat.

I don’t think anyone is arguing that in some instances a new window would be good; it’s more the case of how the author writes the method or (informs or doesn’t) the user that the link has been designed to open in such a way.

benbob, are these images arranged in a manner that appeals to you, or do they miss the mark?

It is more or less what I have in mind. Precise positioning, size etc to be determined by my (lack of) taste and judgement as to what would be a proportional and relevant image to support the text.
Apart from a rare occasion, I would not have 2 images juxtaposed, but one flanking the text on either side. For example a section on burners would look like:

h3 burner repairs for white boilers /h3
image on left . . . text
. . . . . . . . . . . . about
. . . . . . . . . . . . burner
. . . . . . . . . . . . repairs . . image on right

h4 burner flame corrections /h4

The dots are put in to simulate the “column of text”; spaces alone are not displayed on the forum.

That came across wronly then. I am hesitant in OVERALL changes e.g. “classic” 2-3 columb or tables, nav bars and so on. On the other hand, I am very keen on any changes/additions that either improve the looks of my site ( in my opinion or based on feedback from users ) or style alterations that make the site more flexible, more easily adaptable/changeable, or in any other way actually help performance.

My site is typically used by owners of a particular boiler who will got to the particular page about that boiler if there is one or general page if there isn’t. From there they may want to visit a page dedicated to a particular problem that is common for many boilers, read that and then kill that page to go back to where they were. Due to the nature of the type of visitor, it is unlikely they would be interested in more than 3 or 4 pages; the scenario with a dozen open tabs will simply not happen. Added to that, is the rather large proportion of utterly a-technical people that have absolutely no idea you can do other things than just click on a link and back-track to the previous page. The use of “target” is something I find most helpful, deprecated or not

Nevertheless, I would much prefer it if I could make it so that the “Google+” error would not flag up. If I undertand your statements on this correctly, you don’t particularly care wheter a method is “approved” by the coding community or “frowned upon”, as long as it works flawlessly.
That would be exactly my attitude; pragmatic is the word for me, not approval.

Yes, please, pretty please, sugar on top; I am very interested indeed.
I’ve gone through several online courses and a dozen or so books on HTML and/or CSS, and found precious little new after the first 3 or 4. Evidently, there is still much I need to learn past the basic implementation, but I am at a total loss what to do and where to go to accomplish this.
I count myself very lucky to have found this forum and to be able to get advice from accomplished professionals. At the same time, I find it utterly frustrating that I have to take this route, rather than being able to learn what I need and not having to bother others.

Many thanks for this.
If nothing unforeseen pops up, I’ll have the time this weekend to study the code, (try to) understand what it does as well as HOW it does that, and then integrate it in my site if it doesn’t raise any conflicts with current coding or future plans. There are still a variety of items in CSS that I can sort of implement, but faill to grasp the structure/concept of. I need to read about these things, play about with them, and then at some point follows the EUREKA experience. I have an unusual and particular learning style where understanding has little to do with complexity; the “presentation” needs to be suited to my style. If it is, I can absorb amazing amounts of material in a very short time. If it is not, I struggle to understand even very simple concepts.

Why is that?
I thought with the arrival of 32-bit operating systems, the old limitations had become redundant.

Why?
Why is JS “better”? How is JS better?
Why is _blank perverse?
Why is JS the “obvious” tool? To me, using _blank is a damn site quicker and easier than writing a JS routine, not to mention the fact that it will work 100% of the time which can not be said for JS.
Apart from that, what is the difference between usingn JS to automatically open a new window/tab and _blank doing exactly the same? :confused:

Why is that?
I thought with the arrival of 32-bit operating systems, the old limitations had become redundant.

8-bit, 16-bit, 32-bit, 64-bit has nothing to do with the issue.

The simple rule is that a URI (internet path) cannot contain spaces. Browsers delightfully fill in those spaces with %20 or plus marks IF the URI is surrounded by quote marks. If no quote marks, the browser stops reading at the first space. If that space occurs before the end of the intended URI, it fails. The easiest (best) practice, is to habitually eliminate spaces within all parts of a URI which typically means no spaces within image names and directory names (the full path).

You can demonstrate the effect of spaces in image names and URIs on your PC by accessing a page which contains spaces in image names. In Firefox, right-click in the browser window on a web page and select “Save Page As…”; in IE, click the “File” menu and select “Save As…”. Then save as a “Complete Web Page”. (NOTE: this is NOT “View Page Source” then “Save As”). On a PC, you will find that the files associated with the web page have been placed in an associated folder whose name ends in “_files”. Images in that folder have been renamed with %20 where there were spaces. The HTML file (the web page) also shows %20 where there were spaces in the URI.

That’s just the way PCs, browsers, and servers work.

Back to the layout of your web page, a couple of questions, please…

You are now describing that you would put images along both edges of any section in the page. That’s different than floating the image boxes to the right column (which is what the screenshot demonstrates).

This is important. Note on the latest screenshot that the text flows beneath the images. Is that behavior acceptable or do you want the image/s and caption in a “column/s” from which the other text is excluded?

…integrate it in my site if it doesn’t raise any conflicts with current coding or future plans.

It shouldn’t cause any problems with present coding but it DOES NOT support your future plans. It is the “bandaid” measure you requested in your first post in this thread. It uses a similar fixed length container for the images which means that it does not change heights when the width of the browser window changes, and it does not make easy the positioning of additional images. Although probably useful to study, it is not really a step forward, in my opinion.

Future plans are still being discovered but we’re getting closer <smile>.

Oops, I made a mistake. The previous screenshot does NOT show text flowing beneath floated images. Sorry. This screenshot does because the window is narrow. Nothing different otherwise.

This page still needs a bit more work, but apart from being longer and better organised, it is fairly close to the desired endresult.
example page

Depending on availability of graphics, it will have an image on one side, or on both sides. If a large image is required for whatever reason, I would just have the one big photo (left or right).
I couldn’t quite see the details of your screenshot, but the idea is to float the images, but inside the “div” that wraps the “headline” of each section plus the text in that section, but not beyond. That may be lining up with the bottom OR the top of that text (haven’t learned yet how to line up with the bottom of the text between two h-tags, but that is a different story.

The main issue for the moment is to be able to position the images exactly where I want, WITH a caption directly under or above it.
The top part (logo plus first two images) is not quite to my liking yet, but can live with it for the moment. Serious lack of time during busiest period of the year prevents me from being too picky.
The next two sections, “back boiler ventilation repair” and “repairing backboiler lack of ventilation” are both acceptable variations. In some cases I will want the body text to wrap around the image, in others not.
The final version of that page will be a “neater” top section followed by 5 sections with an image on either side ( or one big one, either left or right), and maybe some images sprinkled around at the bottom section.

The bottom section will be redesigned at some point, when I have had inspiration/Eureka moment about what to do with it; not a priority for now.

That looks pretty much like what I have in mind. Most of the images I use will be relativly smaller than in the screenshot, ideally on both sides of the text if I’ve got enough graphic material, and “never” (never say never, but still) 2 directly next to each other.
Sometimes text will wrap like in the secon section, sometimes it won’t like in the top section.

It also depends what else I will discover on my journey mastering “fluid design”, plus adapting for mobile/tablet platforms. Compatibility/userfrienlyness for the latter is a high priority at the moment as it gives me at least two advantages over most of my competition; not only do most sites not display flawlessly on small screens, Google ranks my site better than those of my competitors on smartphones and other mobile devices.

You could have added the Google proprietary markup with JavaScript (and the Validator would have skipped it for all it’s worth else used extensibility) and since it requires JS to display and work it would be no hardship. I didn’t see it [G+] because I usually surf with JavaScript disabled.

It has proved quite useful this year having no JS when on some sites I’ve entered that have had encrypted scripts that were designed by some miscreants, which didn’t in the slightest, affect me. :wink:

Like I said, “Separation of Concerns” and accessibly and usability issues. The target attribute (for this use) doesn’t fit in with this paradigm. If I had hardcoded a FONT text ‘color’ as black and background using ‘bgcolor’ black; you’ll see the text yes, but I doubt you’d be able to read it… Now, instead if I were apply those colours with CSS I’d be separating structure from presentation. Thus all I would have to do is disable CSS or use user-stylesheets and problem solved.

I presume you know the basic differences between; HTML, CSS and JavaScript? In which case you should be able to appreciate markup is static and scripts are dynamic. When I said unobtrusive JavaScript is more apt, is because spawning a new unnamed window is behaviour not markup. In the absence of JS the link will completely function like a normal ‘standard’ hyperlink and allow you to navigate backwards and forwards - misusing _blank won’t.

Easier and quicker, etc., yes, I cannot fault that… just like wiring a 3-pin plug and choosing whichever colour wire you fancy to attach to each pin rather than bothering; to put brown to live and blue to neutral pin, etc.

Actually _blank doesn’t work 100% in all modern browsers for all it matters. Quite rightly the JS won’t always work (open a popup) and like I said that is up to the user and user-agent. You are focusing too hard on the web author’s point of view not the ‘visitors’ wishes or their choice.

If you use _blank you’ve; just broken my back button, disorientated me, forced more CPU cycles and gained very little, possibly even annoyed me and maybe lost me as a customer? Forcing new windows to open without warning is disrespectful and hostile. In most cases it will be counter-productive as an end result.

You do not know whether the user requires AT either or how they perceive the web through their user agent it may be vastly different to mine or your experience of browsing.

The user ‘never requested’ this “new window” spawned by the target attribute. Note that not using the target allows the user to decide whether a new window should be opened or not.

They aren’t the same thing and I’ve already covered this above and they don’t have the same function.

Example: Buy me and [URL=“http://www.sitepoint.com/forums/showthread.php?895775-Caption-not-going-where-I-want-it&p=5213110&viewfull=1#post5213110”]Buy me without inspecting these two links you don’t know what, how or where they’ll take you to?

Note with the former you have no flipping choice, of a window spawning (or for that matter no obvious indication). In other-words it has failed twice - and created a greyed-out back button and no clear way to return. The second would be considered the unobtrusive JS method when ‘block popup windows’ is “desired” and in effect by the user if the damn forum didn’t add additional markup.

Off Topic:

Therefore point proved the forum mutilated the hyperlink in the second example adding target _blank and forced a window to be spawned just to link to a post higher up the page. Argh! So just use your imagination (second hyperlink) and assume it was coded: <a href=“somelink”>…</a> as would have been the case if unobtrusive JavaScript had have been used. :rolleyes: