I’ve got a problem with the oversized html: http://www.myairportsedan.com/redesign/new_2.html
What’s the problem? You set huge font sizes on the :before (I assume you are talking about the 3 abbreviated words).
nono, the font sizes are intentional. The big whitespace at the bottom between the content and footer is the problem. I made the body and html height 100% so I can change the height of the two divs on the left and right (outgrad1 and 2 are the names of the divs) of the main content div.
That’s because on #outGrad2 you move it via top:-60% (and it’s relatively positioned). The reason that’s the issue is because relative positioned items that are moved via coordinates are moved VISUALLY but not physically. Meaning the space they occupy is still the same.
If you wanted them side by side, you just need to remove that top:60% and on "#main " float it :).
So I float the main div to the left? Well that didn’t work out so well. If I try to float OR the outGrad2, then it gets pushed down which is why that -60% was there to move it back up.
Bump, please help: http://www.myairportsedan.com/redesign/new_2.html
Floating it to the right keeps wrapping down.
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.
<!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">> 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>
> Book a Lincoln Towncar Sedan
</a>
</li>
<li class="limo">
<a href="bookLimo.html">
<span></span>
> Book a Lincoln Towncar Stretch Limo
</a>
</li>
<li class="bus">
<a href="bookBus.html">
<span></span>
> 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>
> Book a reservation to/from BWI
</a>
</li>
<li class="IAD">
<a href="iad-airport.html">
<span></span>
<strong>Dulles International Airport</strong>
> Book a reservation to/from IAD
</a>
</li>
<li class="DCA">
<a href="iad-airport.html">
<span></span>
<strong>Reagan National Airport</strong>
> 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.
Here’s what I came up with:
http://www.cutcodedown.com/for_others/an_alien/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.
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 
Oh wow, I can’t believe I missed that last line, lol sorry. Well I’ll be looking forward to the breakdown :).
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.
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.
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.
[b]* html #top,
- html Content,
- html #footer[/b] – 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_others/an_alien/images/socialIcons.png
I do this several more times:
http://www.cutcodedown.com/for_others/an_alien/images/airportIcons.png
http://www.cutcodedown.com/for_others/an_alien/images/fleetIcons.png
http://www.cutcodedown.com/for_others/an_alien/images/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.
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.
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.
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.
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!