SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 47 of 47
  1. #26
    SitePoint Enthusiast An Alien's Avatar
    Join Date
    May 2011
    Posts
    75
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Bump, please help: http://www.myairportsedan.com/redesign/new_2.html
    Floating it to the right keeps wrapping down.

  2. #27
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Ok, let me show you how this is done -- despite it NOT being what I consider a viable for web deployment design with the fixed width and massive image for nothing.

    Some changes to your workflow might help too. First step I suggest is getting your CSS out of your markup; it has no business there in the first place and if you edit it in a separate editor window, you can put it side-by-side with the markup so you can see both at once.

    I'll be doing this in XHTML just because it's where my comfort zone is. I only really use XHTML 1.0 Strict instead of 4.01 because I like the more consistent formatting rules.

    You seem to have a description as your title; waste of code and kind of misses what title is for...

    With this new attempt of yours you've got MUCH better markup than before; the changes I'd make are mostly cosmetic.

    Code:
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    <html
    	xmlns="http://www.w3.org/1999/xhtml"
    	lang="en"
    	xml:lang="en"
    ><head>
    
    <meta
    	http-equiv="Content-Type"
    	content="text/html; charset=utf-8"
    />
    
    <meta
    	http-equiv="Content-Language"
    	content="en"
    />
    
    <meta
    	name="description"
    	content="Your affordable limo, sedan, and SUV company serving BWI, IAD, and DCA airport."
    /> 
    
    <link
    	type="text/css"
    	rel="stylesheet"
    	href="screen.css"
    	media="screen,projection,tv"
    />
    
    <title>
    	My Airport Sedan
    </title>
    	
    </head><body>
    
    <!--
    	empty or oddball spans below either contain non-css
    	content like hyphens, or are image sandbags for 
    	"CSS Sprites" or image replacement techniques.
    -->
    
    <div id="pageWrapper">
    
    	<div id="top">
    
    		<h1>
    			<span>My</span> Airport Sedan 
    			<small>
    				<span>
    					<span> - </span>
    					Your
    				</span>
    				Affordable Luxury
    			</small>
    		</h1>
    		
    		<ul id="social">
    			<li class="facebook">
    				<a href="#">
    					Facebook
    					<span></span>
    				</a>
    			</li>
    			<li class="twitter">
    				<a href="#">
    					Twitter
    					<span></span>
    				</a></li>
    			<li class="google">
    				<a href="#">
    					Google
    					<span></span>
    				</a>
    			</li>
    		</ul>
    		
    		<ul id="mainMenu">
    			<li><a class="current" href="#">Home</a></li>
    			<li><a href="services.html">Services</a></li>
    			<li><a href="rates.html">Rates</a></li>
    			<li><a href="bookUs.html">Book Us</a></li>
    			<li><a href="aboutUs.html">About Us</a></li>
    		</ul>
    		
    	<!-- #top --></div>
    
    	<hr />
    
    	<div id="slideShow">
    		<img src="images/slide1.jpg" alt="slideshow pane" />
    	<!-- #slideShow --></div>
    
    	<hr />
    
    	<div id="contentWrapper"><div id="content">
    		<p>
    			Anyone who has ever lived, worked or traveled to the Washington D.C. or Baltimore area will agree; there is nothing more frustrating than driving in DC traffic, especially in the traffic that thrives around the area's major airports. Don't make your trip any more stressful than it needs to be, but take advantage of <b><i><span class="my">Your</span> Airport Sedan</i></b> and let us do the driving!
    			<br />
    			<a href="aboutUs.html">&gt; Read More.</a>
    		</p>
    		
    		<h2 class="review">
    			What People are Saying
    		</h2>
    		<p>
    			Waiting for google content to be fixed/working
    		</p>
    		
    		<h2 class="yourFleet">
    			Your Fleet
    		</h2>
    		<ul class="fleet">
    			<li class="sedan">
    				<a href="bookSedan.html">
    					<span></span>
    					&gt; Book a Lincoln Towncar Sedan
    				</a>
    			</li>
    			<li class="limo">
    				<a href="bookLimo.html">
    					<span></span>
    					&gt; Book a Lincoln Towncar Stretch Limo
    				</a>
    			</li>
    			<li class="bus">
    				<a href="bookBus.html">
    					<span></span>
    					&gt; Book a coach bus
    				</a>
    			</li>
    		</ul>
    		
    		<h2 class="airportTransfers">
    			Airport Transfers
    		</h2>
    		<ul class="airport">					
    			<li class="BWI">
    				<a href="bwi-airport.html">
    					<span></span>
    					<strong>Baltimore Washington Intl Airport</strong>
    					&gt; Book a reservation to/from BWI
    				</a>
    			</li>
    			<li class="IAD">
    				<a href="iad-airport.html">
    					<span></span>
    					<strong>Dulles International Airport</strong>
    					&gt; Book a reservation to/from IAD
    				</a>
    			</li>
    			<li class="DCA">
    				<a href="iad-airport.html">
    					<span></span>
    					<strong>Reagan National Airport</strong>
    					&gt; Book a reservation to/from DCA
    				</a>
    			</li>
    		</ul>
    		
    	<!-- #content, #contentWrapper --></div></div>
    
    	<hr />
    				
    	<div id="footerWrapper"><div id="footer">
    		footer content
    	<!-- #footer, #footerWrapper --></div></div>
    	
    <!-- #pageWrapper --></div>
    
    </body></html>
    Gimme a few and I'll put together the CSS to go with that, with some remastered images... should take like... ten to fifteen minutes. I'll base as close to the original picture as possible, though I may replace few blurry bits from my stock images and open it up semi-fluid.

  3. #28
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Here's what I came up with:

    http://www.cutcodedown.com/for_other.../template.html

    as with all my examples the directory:
    http://www.cutcodedown.com/for_others/an_alien/

    is wide open for easy access to the bits and pieces. Valid XHTML 1.0 Strict, tested working all the way back to IE 5.5; I used CSS3 for the shadows so naturally IE8 and lower don't get those, and IE6/lower don't get the semi fluid width -- OH WELL.

    I used CSS sprites where possible for each subsection, while keeping the total filesize below the 72k maximum size I usually aim for. (though once you add some stupid slide rotating nonsense to it that goes right out the window). At only 8 files total handshaking overhead is effectively a non-issue... and you could probably go to 8 slides before you'd really have loading time issues in terms of connection limits effecting speed.

    I'm on my way out the door, but I'll work up a line-by-line breakdown of the code to explain the how/what/why of it.

  4. #29
    SitePoint Enthusiast An Alien's Avatar
    Join Date
    May 2011
    Posts
    75
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I really am grateful for you coding it up for me, but can you tell me exactly why my previous markup was bad and why it didn't work? If I just use your code, I won't learn anything. So if you could please do me a favor and explain it a bit more, I would really appreciate it. Thank you

  5. #30
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,296
    Mentioned
    179 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by An Alien View Post
    I really am grateful for you coding it up for me, but can you tell me exactly why my previous markup was bad and why it didn't work? If I just use your code, I won't learn anything. So if you could please do me a favor and explain it a bit more, I would really appreciate it. Thank you
    @deathshadow60 has mentioned in the last line of his last post that he will do a line by line breakdown for you so I won't jump in. I'm sure it will be on its way soon

  6. #31
    SitePoint Enthusiast An Alien's Avatar
    Join Date
    May 2011
    Posts
    75
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Oh wow, I can't believe I missed that last line, lol sorry. Well I'll be looking forward to the breakdown .

  7. #32
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Sorry for the delay, I've been knee deep in one of my own projects and already forgot about this thread. My bad.

    Gimme a hour or so and I'll type up a explanation.

  8. #33
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Sorry for the additional delay, early dinner took longer than planned.

    Ok, in the HTML as I said your most recent version wasn't too bad. The only real difference is my switching to XHTML 1.0 because I'm more comfortable with it's stricter formatting rules (the only really valid reason to use XHTML instead of HTML at this point); rules I believe prevent you from making mistakes in the first place by making clearer code.

    The CSS as mentioned doesn't belong in the markup -- that's not just for deployment IMHO. It's a lot easier to work with your CSS in a separate file as you can have both the markup and CSS open side-by-side, so you can refer to the markup you're applying that CSS to. No more constantly scrolling up and down going "now how did I nest that again?"

    The CSS embed gets media="screen,projection,tv" -- all those devices should get the screen CSS; Opera uses projection running full screen as do several internet kiosks -- and strange as it sounds there are still a few Web TV users out there.

    You'll notice my first post with a recode has pretty much (+/- 5%) the same markup as the final version. I'm a firm believer in writing semantic markup BEFORE you even think CSS or layout. To me, drawing a goofy picture of a layout before you have semantic markup of the content is putting the cart before the horse. While certainly there are some stock containers and elements that can go in before the layout, if you're thinking layout first when writing your HTML, you're probably doing it wrong.

    A lot of the "difference" code-wise is just names. I hate "nav" as a name; short, cryptic, and since every anchor on a page is navigation, pretty vague. Hence why I'm not a fan of the HTML5 tag either.

    In the H1 the spans are obviously for color, but notice the extra nested span (I space everything out nice and clear so every element is obvious). That's present for non screen.css users. When making a page first and foremost I design for what happens when CSS or images aren't present. This gives me a baseline I can 'progressively enhance' with CSS and images, which then "gracefully degrades" when people turn off or don't have such technologies available. If you are practicing separation of presentation from content (which it looks like you are) what you get CSS and images off is what search engines, screen readers, and other 'less capable' user agents deliver... do write to that FIRST. That span is hidden in the CSS, as are other elements like horizontal rules.

    Semantically horizontal rules mean a change in topic or new subsection WITHOUT a heading. This is why I put them around the slideshow so as to differentiate the menu from the slideshow from the content area. If the content area had a H2, I'd be tempted to omit the HR, but that would really depend on the page. You'll see another HR before the footer for the same reason -- to make it clear that the footer content is NOT part of the H2 preceeding it (Airport transfers).

    Heading orders aren't just about numbered heading tags -- HR has a part to play too; too many people think it just means "a bar across the page"; that's presentation, not semantics.

    You can see some of that graceful degredation in the social networking icons, where I'm using spans as image replacement sandbags that in the CSS end up placed over the anchors text. I used opacity to make the text show through on hover, but one could just as easily make two rows of icons for hover states there instead. It also means all three icons AND any hover states can be stored in a single file -- the incorrectly named "CSS Sprites" in action.

    Notice my commenting style? It's handy to know just what DIV is being closed on longer sections... putting the comment before the close means that a rare (but hair-pulling annoying) bug in some versions of FF and IE where comments can cause rendering errors (yes, I said COMMENTS causing errors) is avoided. Comments between sibling inline-block or floated elements can often trigger the "disappearing content" and "double render" bugs in IE, and the "double bottom margin" bug in some versions of FF3... solution, put the comments where they cannot possibly end up between sibling elements -- before the element being closed.

    Many of your extra DIV were axed though as unneccessary. You were getting a bit too complex on things like the slideshow (NOT that I'd put a slideshow wasting space at the top of a website!) or even the gradients (div#outgrad1 and div#outgrad2 on yours). That's all presentation, so they have little business even being in the markup.

    In the same way you went a little overboar on your classes; like the HR class -- if all your H2 in #content are getting that appearance, none of them need classes.

    I also used actual ID's and meaningful names for the extra wrappers. If they share the same values just declare them together in the CSS; this leaves the door open to target them separately as well.

    Ok, enough about the HTML. Gimme a bit and I'll belt out where the real magic happens, the CSS... which I'll go into much more detail on since we're WAY different on handling this.

  9. #34
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    On to the CSS.

    The first major difference is the resets -- I use a small (less than quarter k) reset JUST nabbing the margins and borders that are different cross browser. That large reset you are using isn't a reset; 90%+ of what it does have NOTHING to do with resetting anything, and borders on being a framework. Waste of time.

    The universal reset
    * { margin:0; padding:0; }

    Is problematic as it nabs form elements, making cross browser appearance of forms a royal pain in the backside; though it's gotten better since FF abandoned styling form elements like Nyetscape 4. (wow, that only took a decade.). I avoid that one as a rule.

    At the same time, massive resets like the Eric Meyer Weiner one wastes time setting values on elements that don't need them, sets values that already ARE the same cross browser, and defines a bunch of crap that there's no real point to. The one you were using is a laugh since it even targets elements that don't exist in the doctype you were using. (Specifically the HTML 5 ones)

    hr,
    h1 small span span
    -- Comment before it says it all. Hide these elements which are present for maintaining logical document structure and for non screen.css appearance.

    body -- I kept the IE 5.x fix becuase it's just one small line. You have to remember that IE6 was new on windows mobile as of just three years ago, so it's not a big deal to support them. While I use a lot of CSS3 that IE8/lower won't render (Oh noes, not that) I still take the time to feed legacy browsers a functioning page. It takes little if any extra time to support them if you keep your head on straight and don't fill up the page with crap that shouldn't be on websites in the first place.

    I use the condensed font declaration because line-height cannot be trusted cross browser, and it's easier than saying font-style, font-family, font-size and line-height separately. Line height in particular you have to watch for as the CSS specification only 'suggests' somewhere between 110% to 130%... MOST browsers use 120% (allegedly) though FF often seems to just pull a number at random out of it's backside. I always state a metric; people claim you can omit a metric and use EM scale and it will inherit, I've NEVER had that work right. Oh noes, one extra character.

    The background color I set here is to stretch behind the entire document and past the footer. This way on really tall screens the footer looks ok without resorting to more complex layout concepts like 100% min-height.

    a:psuedos -- Just set them up ahead of time. Anything that hits elements globally I like to hit up top.

    #pageWrapper -- this element shouldn't be needed, but FF will auto-expand elements to show all of CSS3 box-shadows. Overflow:hidden will chop off at the edges when the screen is too small to show them or when we just don't want them showing. Since we're going to have this element present anyways, I set the white background for the header/content areas ahead of time here.

    #top,
    #content,
    #footer
    -- Our width constraints. As I said just give them proper names for what they are, then target them for width together this way. I made the layout semi-fluid with a narrow min-width, a max-width in EM's so the maximum size is related to font-size (good for large font users like myself), and the 95% width means on most displays there'll be a little bit of padding at the sides. You naturally know how to center a DIV with margin:0 auto;... and then the text-align gives us normal alignment after the IE 5 centering trick.

    * html #top,
    * html #content,
    * html #footer
    -- Again comment explains it. Just target IE with a fixed width since, well... IE sucks.

    h1 -- float it, pad it, set the font. Instead of playing all those games with span for caps, I just use the font-variant property "small-caps" which works fine. It's a little inconsistent between browser makers, but not horribly so.

    h1 span -- the ones with different colors.

    h1 small -- another different color, block to put it on it's own line, and the smaller font. 45% of 200% gives us 90% of our body size.

    #social -- I pad it to push it down and float it... kill the bullets. Pretty simple.

    #social li -- IE7 is a total gimboid about floated LI, the heights of LI with anchors inside them, and a whole host of other issues... so usually I'll just set them to inline and be done with it. Basically strips them of formatting so we can do what's needed with the anchors instead.

    #social a -- left floats inside a right floated parent puts them in source order while still on the right. Position:relative allows me to absolute position the sandbag spans in relation to this element. The overflow chops off excessive width of the apo elements -- this is so if you want image based hovers (instead of the opacity I use) you can just do 'left:-56px' on the spans instead of doubling the number of background-position declarations. Width and height are big enough to contain the text...

    A cute 'trick' I'm using here is the negative top margin. Because these images are PX sized elements, it's hard to center them next to the H1 when the fonts there are dynamic (%/em)... by padding the top of the UL down in EM, then 'riding up' the anchors half their height, it centers them vertically.

    I dislike using px fonts, but since we're behind images there's not a lot of wiggle room for doing much else with them.

    #social a span -- our APO span image replacement; basically a gilder-levin type. Just position it over them, and load the icon image file as it's background. Poof, erases the text.

    Mentioned this earlier, now to point it out -- all three of those icons are in a single file:
    http://www.cutcodedown.com/for_other...ocialIcons.png

    I do this several more times:
    http://www.cutcodedown.com/for_other...rportIcons.png

    http://www.cutcodedown.com/for_other...fleetIcons.png

    http://www.cutcodedown.com/for_other...ages/icons.png

    Less files means faster page loads. Similar images in one file means if you palette reduce (a good idea at all times for production images) means a smaller overall filesize. Part of how I got your page down to 71k in 8 files -- when your original "new_2" was over 120k in 15 files.


    #social .twitter span
    and
    #social .google span -- just slide the background to reveal the part of the image we want actually showing.

    #social a:active span,
    #social a:focus span,
    #social a:hover span
    -- I just make them transparent to give a hover effect and reveal the text. You could just as easily make the span double-wide and slide it sideways to add actual image hover states instead.

    #mainMenu -- clear the floats, kill the bullets, pad the bottom. Nothing fancy.

    #mainMenu li -- again, just kill the LI on menus if you're not going to have dropdowns.

    #mainMenu a -- margin on the right means no playing with detecting 'first', kill the underlines, set the size and color.

    #mainMenu a.current,
    #mainMenu a:active,
    #mainMenu a:focus,
    #mainMenu a:hover
    -- hover states and current get color. Again, nothing fancy there.

    #slideShow -- the overflow prevents our box-shadow on the image inside it from rendering outside this element. I also apply that top gradient using box-shadow. This means at the edges of the screen you can see a bit of rounding, but big deal.

    Though I HATE the vendor prefixes, it beats using a image for this. IE8/lower doesn't get the gradients, OH WELL! So long as they still get a useable page, I don't care about it being as pretty as in modern browsers. Some people will waste time trying to use javascript shivs/polyfills/whatever they're calling it this week to make them work; it doesn't and often breaks the layout worse than just saying "OH WELL!"

    #slideShow img -- I cut the borders off the image since the jpeg artifacting was pissing all over them, and instead apply them using border and background. If you pad a image, the background-color will show around it, hence the padding. Just center it, border it, and then box-shadow it. The box-shadow is how I apply those side gradients. UNFORTUNATELY most browsers won't render box-shadow larger than 128px... but that's fine in this case.

    Doing it this way means no real layout headaches apart from making sure the unwanted shadow top and bottom is cut off by the parent -- which we do with all those overflow:hidden I keep pointing out.

    #contentWrapper -- used to apply that blue gradient. I used an image for this because box-shadow doesn't go far enough, and CSS3's linear-gradient is still... buggy. I made it 512px tall so that in IE8 and lower it would still look decent, but it looks best when background-size can stretch the height to fit. Top padding just makes it purty.

    #content -- more top padding, in this case it's because I like to use padding instead of margins on elements. The container (in this case #content) gets a top padding, the child elements all get no top padding, and 1em side and bottom padding for a nice consistent appearance. Margin collapse is well worth avoiding when possible.

    From there it's just the background, borders, and the top box-shadow replicating that gradient. (or at least, close enough for gov't work)

    #content p -- and here's that padding I mentioned.

    #content h2 -- I do end up using margin on this one, because of that bottom gradient 'rule' type line uses our padding. Apart from that, font size and color, no biggy. I use 125% for size since that makes the math for 1 parent EM easy --80%/0.8em.

    #content h2:after -- Instead of dummy span I chose to use generated content to put the icons in the h2. IE6/lower doesn't get the icons on the H2 -- OH WELL. You really care you could add the spans back in... I don't think it's neccessary. A wee bit of positioning fixes their alignments, and the inline-block is there so we can set their widths. Pretty simple.

    #content h2.yourFleet:after
    [i]and[/b]
    #content h2.airportTransfers:after -- again the incorrectly named "CSS Sprites", we just slide the background up to reveal the other icons in the file.

    #content ul -- Again some simple padding. I don't pad the right since we'll let the LI handle that as appropriate.

    ul.fleet,
    ul.airport
    -- these have a lot in common, so declare them together.

    This type of 'three across' element is what I like to call "Not viable for web deployment" -- they're fragile, they're a pain in the **** to code for, and they often restrict what you can do for dynamic width AND dynamic fonts... in any case though I did what I could with them.

    For these two parent elements, we just kill bullets and set up float wrapping.

    .fleet li,
    .airport li
    -- floated at 33% width... we lose 1%, oh well.

    .fleet .bus -- IE will often incorrectly calculate 33% at certain widths, this was cropping up here making it 'drop' to a new line. This negative margin tricks IE into thinking the element is narrower than what is being rendered, preventing the float drop.

    .fleet span,
    .airport span
    -- they share being blocks for the images, and a bit of bottom margin to make 'em pretty. Doing this instead of a background-image means we can use CSS Sprites.

    .fleet span -- width, height, the proper icon file.

    .fleet .limo span
    and
    .fleet .bus span -- again, slide the backgrounds to reveal the proper part of the image.

    .airport span
    and
    .ariport .IAD span
    and
    .ariport .DCA span -- lather, rinse, repeat.

    .airport strong -- block to put it on it's own line, set the color.

    .airport a:active strong,
    .airport a:focus strong,
    .airport a:hover strong
    -- hover colors.

    .fleet a:active span,
    .fleet a:focus span,
    .fleet a:hover span,
    .airport a:active span,
    .airport a:focus span,
    .airport a:hover span
    -- opacity on the spans makes it appear to 'lighten' when hovered.

    #footerWrapper -- Background, top shadow. Nothing fancy.

    #footer -- padding, color... again, simple.

    ... and that's it. How I'd go about it.

    To say what's wrong with your original is actually difficult because I wasn't really able to track down any specific issues per se... but a lot of that was your painful to read lack of formatting and stuffing everything onto single lines -- makes it impossible to follow and explains a lot of your redundancies... the lack of condensed properties and trying to use url type generated content (which does NOT work right cross browser!) only further made what should be a relatively simple page more complex than need be.

    In a lot of ways I think you just overused generated content, in some places in a manner that I know IE7 would choke on. You were also APO'ing many elements (like #social and .fleet a) that shouldn't have needed to be positioned. Let flow do it's job.

    Likewise you used a couple complex selectors that IMHO if you need on a page, there's something wrong with the page. "#footer>*{margin: 0 20%;}" for example.

    In several places I think the breakage came from setting font sizes without adjusting the line height. NEVER trust the inherited line-height on a element. Anyone tells you otherwise or tries to say you can use some sort of trick like omitting a metric, they're packing you so full of sand you could change your name to Sahara.

    So... to sum up the 'obvious' issues yours had -- bad reset, selectors not ready for primetime, overuse of generated content, lack of properly setting line-heights... apart from that it's hard to say -- which is why I took a stab at a rewrite to see if I encountered similar issues doing it 'my way'... and came up with a result that's "functional" all the way back to IE 5.5.

  10. #35
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,296
    Mentioned
    179 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    Anyone tells you otherwise or tries to say you can use some sort of trick like omitting a metric, they're packing you so full of sand you could change your name to Sahara.
    You keep mentioning this Jason so can you give me some concrete examples and I'll be willing to change my mind. I've never encountered an issue and I've been using unitless line-heights before everyone knew what they were for (apart form Eric). I'm willing to change my mind though

  11. #36
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Paul O'B View Post
    You keep mentioning this Jason so can you give me some concrete examples and I'll be willing to change my mind. I've never encountered an issue and I've been using unitless line-heights before everyone knew what they were for (apart form Eric). I'm willing to change my mind though
    Ok, how about the page you linked to...
    http://www.deathshadow.com/images/brokenMeyer.jpg

    Fails to inherit properly to headings, PRE, or TABLE. Opera 10, Large fonts/120 dpi system. That one doesn't exactly surprise me given we're talking Meyer -- I've NEVER seen ANYTHING from him that was worth even looking at in terms of use in making sites. How in blazes did he end up a 'big name' in the industry again, because, well... I lack the words in polite company for what I think about EVERYTHING I've seen of his. In fact, I would credit his 'advice' and writings with being responsible for more fat bloated broken websites than I would WYSIWYGs!

    Or better,first link in your sig:
    http://www.deathshadow.com/images/brokenPmob.jpg

    Same thing. I see the same results in IE once I kill the 'lets use zoom and instead use em properly' on modern browsers, so I assume IE7 is similarly afflicted. This is on my Core2 laptop -- I do NOT see it breaking on my i7 870 workstation, despite using the same browsers and OS, so it's very hit or miss, possibly depending on hardware and not browser/OS... popping down to the garage the i7 920 is rendering it like the laptop, while my media center is not showing the problem. (interesting since it's set to 200%)

    Much of the above seems to be due to breaking or failing to follow rules I've set up for myself the past decade; rules like 'never restate font-size without redeclaring the line-height' and 'always use a metric'... Which prevents these oddball types of bugs from cropping up.

    -- edit -- Oh, and Paul... 13px font-size? On content? Seriously? My faith in your abilities is shattered.

  12. #37
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,296
    Mentioned
    179 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    Ok, how about the page you linked to...
    http://www.deathshadow.com/images/brokenMeyer.jpg
    Yes that is a crappy page but I don't see that the problems are down to unitless line-height but to the fact that some elements need to have the line-height specifically defined unitless or otherwise. There are always going to be exceptions and bugs to deal with either way

    Or better,first link in your sig:
    http://www.deathshadow.com/images/brokenPmob.jpg
    -- edit -- Oh, and Paul... 13px font-size? On content?
    Yes I haven't touched the code in that page for about 5 years and it could do with a good spring clean but I think its held up pretty well considering. I certainly wouldn't use the same font-sizing or reset that I did back then but hindsight is a wonderful thing.

    Seriously? My faith in your abilities is shattered.
    From your previous comments I always assumed that you thought that I had none anyway.

  13. #38
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Paul O'B View Post
    From your previous comments I always assumed that you thought that I had none anyway.
    When I say there are only three people on here I have any respect for the skills of, and one of them is dead... count yourself amongst the other two.

  14. #39
    billycundiff{float:left;} silver trophybronze trophy RyanReese's Avatar
    Join Date
    Oct 2008
    Location
    Whiteford, Maryland, United States
    Posts
    13,564
    Mentioned
    6 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    When I say there are only three people on here I have any respect for the skills of, and one of them is dead... count yourself amongst the other two.
    Off Topic:

    I doubt anyone could say they have no respect for Pauls skills, with a straight face.


    I gotta side with Paul on this one. I've never seen unitless line heights cause issues. It may have been set on a page with issues, although it's never directly caused issues, as far as I've seen.
    Twitter-@Ryan_Reese09
    http://www.ryanreese.us -Always looking for web design/development work

  15. #40
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by RyanReese View Post
    I gotta side with Paul on this one. I've never seen unitless line heights cause issues. It may have been set on a page with issues, although it's never directly caused issues, as far as I've seen.
    Doesn't inherit right; go in with opera's source editor or user.css, add * { line-height:1.2em !important; } and poof, problem goes away.

    You say unitless, you then fail to redeclare line-height every time you change font-size (or sometimes face, see PRE) it breaks. Not all the time and not on all systems, but enough you can't trust it unless you want it broken for people who don't have the same default size.

    Doesn't make any sense anyways; another of those uselessly vague idiocies to save what, 1 or two characters? Zero is always zero (well, unless it's first in a set) and that's fine now that Nyetscape 4 can be discounted, but with a value like line-height, all you are left asking is "1.4 what? Quijadas? Tacos? Pesos? Jimmies? Little Jimmies?"

    Seriously, what is this, RUBY? (elif? Really?)... Rust? (fn? i32? vec?) Rust, the programming language who thought C was a bit too clear and verbose!

  16. #41
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,296
    Mentioned
    179 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    Doesn't inherit right; go in with opera's source editor or user.css, add * { line-height:1.2em !important; } and poof, problem goes away.

    You say unitless, you then fail to redeclare line-height every time you change font-size (or sometimes face, see PRE) it breaks. Not all the time and not on all systems, but enough you can't trust it unless you want it broken for people who don't have the same default size.
    The point I was making is that the same problem applies to using values also. There is no extra problem with unit less values. I agreed that there are certain elements that you need to make sure you specify the line height for but that is the same whether you use units or not - unless I misunderstood. For divs and spans etc you don't need to worry.

    You obviously have to take care with what the UA is applying by default as that will win out over inherited styles - just like font-family doesn't inherit into form elements. I bet you never say div,span {margin:0;padding:0} as you know they aren't needed.

    I will say thanks for pointing out the ancient code in my site and soon as I get a few spare minutes (not this week though) I'll tidy it up.

  17. #42
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Paul O'B View Post
    that you need to make sure you specify the line height for but that is the same whether you use units or not - unless I misunderstood.
    You did... misunderstand that is. If my user.css read * {line-height:1.2 !important} it's still broken... just by a different amount; the inheritance is broken by omitting the metric!

  18. #43
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,296
    Mentioned
    179 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    You did... misunderstand that is. If my user.css read * {line-height:1.2 !important} it's still broken... just by a different amount; the inheritance is broken by omitting the metric!
    I'm still not convinced

    Your comment in the previous post leads me to think that you may have misunderstood what unitless line height really means.

    i.e.
    Quote Originally Posted by deathshadow60
    but with a value like line-height, all you are left asking is "1.4 what? Quijadas? Tacos? Pesos? Jimmies? Little Jimmies?"
    1.4 is a scaling factor unlike 1.4em which refers to a computed pixel size. With 1.4em you pass the computed pixel line height down to the child even if the child's font-size is only half that of the parent. If the parent is 30px then the line-height is 42px. If the child then has a font-size of only 14px then the line-height is still 42px which will be much too tall for the smaller text.

    On the other hand 1.4 passes a scaling factor of 1.4 down to the child so the child with a smaller or larger font-size will have a line-height based on its own font-size (1.4 x new font size) and therefore suit the text much better. As above if the parent has a font-size of the 30px the line height will be 42px but if the child has a font-size of 14px then the line height will automatically be 20px (19.6) without having to re declare anything.

    You say that line-height doesn't inherit into pre but this example works fine for me:

    Code:
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <title>Untitled Document</title>
    <style type="text/css">
    div {
    	line-height:5;
    }
    pre{
    	background:blue;
    	font-size:16px;
    }
    p {
    	line-height:5em;
    	background:red;
    	font-size:16px;
    }
    </style>
    </head>
    
    <body>
    <div>
    		<pre>
    test some text to see the effect of line-height
    </pre>
    </div>
    <p>test p element</p>
    </body>
    </html>

    If you change the div to 5em the results are exactly the same.

    However if you remove the font-size from pre then the results for unitless line-height will be different because the line-height will then be 5 times whatever the default font-size of the pre element is (13px in firefox). Unlike the em version which will take the default size of the divs font-size (16px in firefox) and pass that parents pixel line-height down to the child when the child actually only has a 13px font-size.

    I am willing to be convinced but at the moment I can't see it.

  19. #44
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    That example works because the size isn't set on that parent div. Set font-size:85% on the DIV, and you get 85%x120% on the pre instead of 5x 85% OR the 5x 16px (the latter being what people expect, the former being what it would do if you give it a metric). It doesn't inherit right when you change the size.

  20. #45
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,296
    Mentioned
    179 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    That example works because the size isn't set on that parent div. Set font-size:85% on the DIV, and you get 85%x120% on the pre instead of 5x 85% OR the 5x 16px (the latter being what people expect, the former being what it would do if you give it a metric). It doesn't inherit right when you change the size.
    No, you are incorrect and it still works exactly as it should. Whether or not that's what you or others expect is another matter .

    Setting 85% on the div will have no effect on the pre in my example because I set the font-size of the pre to 16px. The line height will still be 5 x16px = 80px. If I leave the div at 85% and remove the font-size from the pre then it still works as the font-size of the pre becomes 11px and the line height is thus 5 x 11px = 55px exactly as it should be. It works every way for me just as it should and just as I expect.

    It is not supposed to give the same results as using units as they are totally different things. The unitless value does not pass a computed pixel size down to the child it passes the scaling factor which is then tested against the font size of that child element to produce the line height. The scaling factor is inherited and not the computed pixel line height.

    Apologies though, I didn't mean to drag this thread off topic but I wanted to get to the bottom of why you feel unitless line heights are broken and then at least I could document any bugs found.

  21. #46
    SitePoint Enthusiast An Alien's Avatar
    Join Date
    May 2011
    Posts
    75
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks a lot DeathShadow, I can see you put a lot of time and effort into writing that up for me so I really appreciate that. I wish I had some input in your guys' debate going on here but I don't have enough knowledge nor experience yet to say anything. I wanted to ask, do you guys recommend any good CSS books?

  22. #47
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,296
    Mentioned
    179 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by An Alien View Post
    . I wanted to ask, do you guys recommend any good CSS books?
    If you do a search of the CSS forum for "CSS books" you should find many recommendations. Don't forget the Sitepoint online reference but is a manual rather than a tutorial. Desigining with progressive enhamcement is also a good read. You can read a review here.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •