L.Adlon

Here's a weird one... Is there a way to code it so that you can insert some text before the 'first letter' of a paragraph? (Ya, I know, then that part is not the 'first letter'.... sure, you got me there.... but bear with me here!) The reason I make such a strange request is because I'm using first-letter to make the first letter of each paragraph larger (like a storybook effect).... BUT, in cases where I have quotes around that paragraph (such as in a testimonial) the open quote ends up getting affected, since it is... the first letter. I'd want the paragraph in quotes, but technically the SECOND character (the first actual letter) to be affected. I suppose I could just do it with a direct <span> type thing, although you loose the keen automation of something like the first-letter definition. I kind of need a 'second-letter' attribute.

Hey, that's neat. I keep forgetting the true control possibilities of elements and CSS. The thing I'm still wondering about, is the built-in 'shading' attribute of <hr>. What does that translate to as far as CSS attributes? Is the <hr> shading just a border set with different colours (lighter on top and left, darker on bottom and right)? If so, I see that you'd be turning that off (on by default) with your 'remove default styles' sections.

Ah, that's kinda clever! I see what you did there! Well, the lines I'm after are more as graphical elements that aren't involved with text. I have a long, horizontal image strip (840px by 70px), and I was just putting a shorter set of lines above and below it... kind of like bookends, but on the top and bottom, rather than at either side... kind of like a partial frame or caps. The stretched pixel method seems to work nice here, since I just have to put: <img alt="" src="image/pixel.gif" class="cap"> wherever I need that line, and then do the appropriate defining in the class definition. Does that sound solid? (Compatible, stable, not entirely stupid...?) The only thing I ran into, so far, is that some browsers may not play nice as far as the margin-top and margin-bottom are concerned... making them slightly different, so they are not the same distance from the image as each other. I have to lok further into that. (Your border method would work, but the lines would be forced to be the same length as my image, whereas this method allows for any length)

Damn, I almost made it out..... Okay, davej... so you are saying I am best to leave the closing slash out of standalone tags? Since either ideology 'works', I'm cool with either one... but if one is considered 'more right' (or futureproof), then I'll gladly favour it. No closing tags it is.... (...waits momentarily, then makes a run for the door)

To make simple horizontal lines, what is currently the best method? Previously, if <hr> wouldn't do the trick, I would use the old 'stretched single pixel' trick. Now that I'm trying to do everything (that I can) with CSS, I'm a bit confused as to how to use <hr> now... The main thing I am not clear on is the noshade attribute. Is that a valid attribute in a css class definition... or is there some equivelant? If it's a valid attribute, what is the value? In the HTML tag, the attribute seems to be a bit of an orphan... a parameter with no value (...or a value with no parameter?). I'm not sure how that would translate into CSS, as I assume all parameters need to be parameter:value pairs. I could use the stretched pixel thing, but I'm just checking to see if there's some simpler (less code) method available these days, that is fully compatible and stable.

Yep.

A few years ago, I was looking for a very simple way to display a bunch of images on my website, aside from the usual group of hyperlinked thumbnails, each leading to a separate 'larger version' page. One of the things I came up with was a scrolling window that contained a single long, horizontal image (consisting of each of the images I wanted in the gallery, placed side by side on this 'strip'). The image itself was bigger than the window, and so you would scroll (horizontally) to reveal the other images. Seemed to work, and was a (seemingly) good way to have a lot of images, yet the only space taken up was the (set) size of the window. To add more images, I simply edited the image strip (added more images to the long image file, extending the size as needed when I ran out of room). I had researched a number of options, and even though I found a few really nice methods, compatibility seemed to always be an issue. For example, the use of iFrames initially seemed perfect, but then there seemed to be talk of compatibility issues. I think it was something like it wouldn't work on mobile devices? Macs? So, the coding for my scrolling window method was simply: <div class="gallerywindow"><img src="image/gallerystrip1.jpg" width="2700" height="200" border="0"></div> And the gallerywindow class was defined as gallerywindow {width:800px; height:216px; overflow:x-scroll; ....} (the extra 16 of the 216 width was to make room for the scroll bar) Now, I know anyone even remotely professional or well-versed in HTML probably just dry heaved, but please keep in mind I was just learning, and wanted a simple solution, without resorting to scripting or HTML methods that were unfamiliar to me.... as I was hand-coding all this stuff, and I was the only one working on it (and therefore had to fix things if they weren't working). So, simplicity and familiarity were key. That all said, is this method 'valid'... in that it would work on all browsers and platforms, and not break or do anything other than work properly? Is there a similarly simple method that would be more ideal? I would be open to any type of gallery display (scrolling window, thumbnails that zoom up to bigger versions... whatever.... as long as it's on the same page). I'd prefer one that doesn't use javascript, only in that I don't know javascript, so I can't fix/modify it, if needed... plus, I worry that relying on it might result in the site gallery being non-functional if they have javascript blocked. So, I'm curious how you guys would approach this sort of thing, these days... again, keeping in mind I'm talking about a very simple method (...as I have to understand it, be able to fix/modify it, and my site is just a simple, low-traffic site with very simple requirements). Currently (for my new version of the site), I'm simply selecting a few images, and displaying them at a medium size directly on the page.... No larger version when you click on it or anything. Works fine for me, but I'm curious how a simple gallery might be done these days.

I'm curious about something... I'm seeing examples of horizontal nav buttons being done using <ul>, and I'm not entirely sure I understand what the reasoning is. I'm currently doing it with just a bunch of <a> tags: <a href="page1.html" alt="" class="navbutton">PAGE 1</a> <a href="page2.html" alt="" class="navbutton">PAGE 2</a> <a href="page3.html" alt="" class="navbutton">PAGE 3</a> ....whereas other samples are putting that as a unordered list, and I'm not seeing what that adds to it, compared to what I'm doing. What am I missing here? BTW, I tried adding "display:block; float:left; width:100px;" to the navbutton class definition, and it seems to work (as far as allowing me to specify the width, and not have the inherant carriage return of making it a block element. I'm still paranoid about the browser support... but that's just me. Thanks for the tip! BTW2, I'm still curious why writing the code as I did in the sample (with a carriage return between each 'button') results in that small area of between the resulting links in the page display that triggers the mouse pointer to change to a text editing cursor (...but is remedied by putting all the <a> tags together in one line, eliminating the carriage returns in the code.

( Head explodes ) So... the ideal then is to keep them in?

From what I've seen in articles on the web, it seems that leaving the slashes out is the 'ideal'. Both may or not be valid, but the (seeming) proper method is to leave it out. ...from what I've seen. ....at least for now.

Wacky... The last few years, I started doing the close tag (ex. <br /> and more recently <img src= .... />. I guess now I'll go back to not using the close tags! What a kooky, zany world this web thing is. Cool. Thanks!

For example <img src="images/picture.jpg" alt="" /> I thought this was unanimously considered proper, but now I'm reading that there's debate about its validity, since some argue that it's never 'open' in the first place. In the interest of doing things right (as far as proper HTML/CSS standards are concerned), what is the official (if there is such a thing!) stand on this?

Oh, ya, for sure... I scale the images down to the actual size they will be on the site, as that also eliminates the need for the HTML to scale it (which, I'm assuming, is a pretty low-tech scale!). Scaling them UP is obviously a bad idea in any aspect! I was just not sure about DPI. The images I'm using, in this case, are for print (as opposed to the usual ones I made specifically for the site), so they have DPI's of 300, as opposed to the usual 72 (which, I'm assuming is still the general standard for regular web?). I wasn't sure if that 300 DPI should be reduced, or was beneficial, or irrelevant. As I mentioned, I reduced the DPI to 72 for those images, as I figured myself the added resolution was irrelevant in this case... plus it made for much smaller files. Looks fine. All good. Just wanted to ask and be sure. Thanks, davej.

Awesome. Thanks. Just didn't want to assume!

I'm convinced! Thanks, Ingolme.

Yep, I'm definitely trying that Float thing again! Scared me off last time.

Hi, Ingolme. Thanks so much for that complete response! Very much appreciated. That helps a lot. Ya, the colour thing was just a typo when I made the post. I do put a # in there normally! Oops. I only really have Firefox and Explorer to test things on, although I now have a friend on a Mac with Safari and some other browser to test things on as well. I'm just a hobbyist, really, so I don't have the full, proper setup, unfortunately. I had tried doing the site without tables, but found weird quirks (...in most cases, probably the fault of my coding or understanding of things), and so I was forced to fall back on tables. I keep looking into it,though... and have certainly reduced the amount of tables and other 'old school' methods I use so far, as I can. A lot of times, I keep with old school methods (rather than embracing proper CSS methods) simply out of a fear that browser support is not (currently) fully realized.... as was the case in shorthands, for example. That's why I ask. Now that I know, I'll be using shorthands! (Whoo-hoo!) Re question 2... What I was finding is that if I did standard <a> tags, but had a carriage return after each (in the html code... solely to make it visually cleanear in the coding, not the actual page display), I would get a small area between the resulting text hyperlinks that would trigger the 'I-bar' text editor mouse pointer. By simply removing the carriage returns after each hyperlink (and have them all as one string in the code), that disappeared. So, it's some sort of 'editable' space character that is introduced between the hyperlinks (in the actual webpage display) when you have carriage returns in the code between each hyperlink. I'll try out the float property and see if that will allow me to use block element hyperlinks (which will in turn allow me to use width!). I've tried Float in previous sites/tests, and got odd results... but, again, that was most likely me not fully understanding things, or other elements interfering. I'll give it another go, thanks! Re question 4... ya, it seems weird to me, too! As far as the coding is concerned, it SHOULD be centered... even by default. It is centered in non-Firefox browsers, as far as I can see. Maybe some other element/aspect is affecting it, but I can't see anything obvious. I'll play around wtih the same kind of thing, outside of that actual page, just to see. If I end up finding out what was causing it, I'll be sure to post the findings here. Re question 5... Yep, could be a number of factors. I seem to have at least reduced the variation. It's totaly useable now. Maybe a 1 pixel discrepency between browsers. I haven't tried the line height, though. I'll give that a shot. That actually was the solution to another issue I was battling, where there was a gap between my embedded Flash movie and an image graphic that were supposed to be right up against each other...and seemingly should have, based on the code. The line height attribute was part of the solution to that. Excellent. That was really helpful! Thanks. If my tests reveal anything of use, I'll post them here, just in case others are wondering about any of this.

Ya, I sort of figured it probably wouldn't really matter. The images in question are displayed at 320x400, locked. I just changed them now from 300dpi to 72dpi, as I figured that only served to make the file size bigger. Visually looks the same, but I just wanted to make sure I wasn't missing out on some info about it being important in this case. Cool, thanks.

Hello. For images that I will have on my webpage (shown at their actual size), is there a particular dpi I should be using? I have some images I did for print, which are at 300dpi, which I shrunk down to about 320x400 for the webpage. The current ones are still 300dpi though (after being scaled down). Is that a problem... a benefit.... or irrelevant? Does that extra dpi only serve to increase file size, with no visual benefit? If so, should I convert them to something like 72dpi (keeping the 320x400 size they are at currently)?

Hi, Ingolme. Sorry, help me out here, as I'm not terribly well-versed in the whole coding thing. I get what you mean by presentational, at least at a conceptual level... but I just want to be sure of the specifics. Are you saying that an image tag could simply be <img src="images/photo1.jpg" alt="First photo" class="gallery" />, as long as the other attributes that would normally be included in the html tag are addressed in the class definition ('gallery') in the style sheet? No harm in keeping them out of the <img> tag? I would only tend to keep them in there (even if redundant) in fear that there may not be 100% support for the CSS, and the attributes in the image would then serve as a backup for it to fall on. Is support for the CSS 100% now (for the standard <img> attribues)?

Hi. If, for example, I have an image tag, and I have a CSS style class defined for all images, are the standard <img> attributes (ex. width, border, etc), aside from the src attribute required if the class definition sets them? Do you include them anyway, just as a backup? As an example, if I define this: img.gallery {width:300px; height:400px; border-style:solid; border-width: 2px; border-color:black; .... } Would my image tags only need to be something like this: <img src="images/photo1.jpg" alt="First photo" class="gallery" /> ...or, are the attributes like width, height, border, etc still required? Is putting the <img> attributes that are also defined in the class redundant, or required?

I don't have access to every browser and platform to test, and trying every CSS command in existance would be a large effort. So, I figured I'd just ask for a yes or no from someone who knows the current compatibilities.

If I want to have a horizontal row of text hyperlinks with a set width, is there either a way to get some sort of width property working (on inline elements), or eliminate the carriage return caused by setting the elements to block display? I'm kind of stumped... as the width parameter doesn't work unless the text hyperlink is a block element, and setting it to a block element (to get width to work), causes a carriage return, preventing them from being positioned side to side/horizontally.

By that, things like border:2px solid blue. Are they fully supported by all browsers these days, and are safe to use, or is there scattered support? I'm currently still using the full-length form, just in case.

Sorry, I just figured out what was happening. The Win7 one was on a seriously old version of Firefox. The updater wasn't working properly.... even when I tried to do it manually. I just went to the Firefox website, downloaded the latest version, installed it, and now the display matches that of the XP. [Embarrassed smile]