past edit time completions:
you really don’t manipulate the markup. you just remove whitespace, manipulate whitespace.
again, there are serious issues in the specs regarding whitespace. this isn’t one of them: keeping whitespace between elements because otherwise it means you’re interfering with presentation. neither this one: formatting a certain way will lead to clean-cut reading and modifying code problems. these are subjective points.
you don’t even want to know how many things modern ie and ff do better than their competitors, despite popular beliefs 
or at what costs the “js superior processing speed” is obtained by these competitors.
while i use ch for day to day common work, i’m not impressed at all but by its speed or compliance (?) but by the simple interface and use.
and op it’s just not user focused. saf loses in front of its webkit brother.
so, in my opinion, at this moment, ie8 and ff3.6 both have a well deserved 1st and 2nd place.
I don’t really have anything constructive to say… I just wanted to chime in on the fact that I love how the tiniest things are debated to death on Sitepoint (I see this as a positive).
For beginners, reading over some of these debates can be very enlightening to some of the finer points that books never get to.
Yeah, I was not to found of using the word/letter spacing combo either. It was just something that I stumbled upon when testing all this.
Right, I knew you could set absurd values on word-spacing and it would not collapse. I wasn’t sure about the letter-spacing and -.3em seemed very close at the time I ran those tests.
As I pointed out in this other thread you can get “X-browser centered widthless blocks” (without any whitespace hacking) by nesting the UL an extra wrapping div (as much as we dislike the extra div). There again it is only really suited for a nav when the LIs’ won’t wrap to another line. It’s just a matter of setting inline-block on the UL itself and floating the li/a, you could even do the display:inline; on the LI in that case too and keep everything centered.
It’s just one div (that serves a purpose) and it can save some headaches and hacks.
If the page you are working on is for yourself then it doesn’t really matter if you format the white space out of the equation but if you are creating a template to hand over to a client for further development work then you can’t risk the design breaking because the html has been re-formatted. In the latter case the adjustments need to be in the css and not the html.
The first thing that I do without fail when I am given an html template to work on is to auto format it. 
am i to understand that your take is to use insufficient, inexact and imperfect css: font-size:0 and negative word-spacing and letter-spacing values to solve a superfluous arbitrary and subjective html markup formatting issue ?
the reason i ask is because your css will never solve the problem completely, while correcting an whitespace abuse for formatting will.
i wish all our html css problems would have such a natural and easy solution. it looks quirky to me that hacks like * *+ /\\ are regarded as sound, but a simple solution like tag chaining makes such an opposition.
as for the danger about the code reformatting by the client or by anybody else for that matter, there are hidden dangers when not handling the hammer the way you suppose to, but this doesn’t stop the use of it one learns its lesson quickly or pays for it until he does 
No, I’d try and make sure I used something that works properly (or acceptably) cross-browser
as for the danger about the code reformatting by the client or by anybody else for that matter, there are hidden dangers when not handling the hammer the way you suppose to, but this doesn’t stop the use of it
If you code as many templates as I do then you know that you just cannot trust the client. Most people work on one or two projects a year but some weeks I complete a different template every day for different clients and you have to make them as robust as possible. You cannot afford the time to have to go back and fix the formatting for the client or indeed impose formatting restrictions on them.
Of course as I have found out many times a determined client can find ways to break most things (e.g. adding comments above the doctype, removing the doctype…)
On the other hand if this is just your hobby or you have total control over the project then you can do basically what you like but dealing with clients is a whole different ballgame. The sensible solution of course is not to make the display dependent on how the page is formatted as all presentations should be handled by CSS and html defines the structure.
I know things are never as clear cut as that but I have a saying and that is “keep your hacks in the CSS and not in the mark up”
what more can i say
“something that works properly (or acceptably) cross-browser” is the whitespace elimination by chaining. it’s guaranteed to work perfectly.
“all presentations should be handled by CSS and html defines the structure”: i fail to see where there is any sign of presentation in the whitespace removal or how html doesn’t define the structure if you play around with whitespace. saying that is like expecting the world to come to a stop every time you use indentation.
it looks to me that you are saying that every time you format your markup you are in fact interfering with presentation. no, you are in fact creating useless white space nodes that end up screwing your web page rendering in some cases. that means formatting is wrong. so, fix it. and don’t try to fix a screw up by causing a chain of screw ups
formatting is optional. good html and css are mandatory for a normal web dev mind formating does not make a bad html markup into a best html markup. nor the other way around. formatting has NOTHING to do with css. whitespace manipulation is pure html business: creating or removing white space nodes. NOTHING PRESENTATIONAL!
the fact that you are formatting your html markup is the hacking action you complain in the first place: white space nodes do count for something, as you can clearly can view in the case of inline blocks.
this tag chaining is clear cut. removing or adding whitespace is not a hack. otherwise, you are hacking your web page constantly by formatting your markup.
in the end i fail to see how one refuses the obvious best solution to go around using css palliatives for an non-existent problem
the argument for not using it is just weak. it’s based on the presumption that some ppl could do something wrong with it.
? ? ? that’s the general picture anyway, ppl will always do something wrong, you can’t help it! it’s like saying “it’s no use to ever code a web page, it’ll be ruined anyway”.
having a clear cut solution but going instead after a twisted css x-browser journey for all the wrong reasons seems just like the writer’s blockage to me
let me end with a saying also: you control the formatting, it doesn’t control you. you have the power, you put it there based on assumptions that are proving wrong and quickly changing from one dev to another.
if you were to keep out all the techniques ppl don’t get and might screw them up, all your web pages would look like text in notepad
Paul has stated in a more eloquent way what my concern was. Noonnope’s solution , I think, is cleaner and more cross browser compatible but it is HARDLY client proof… or even CMS proof. and that’s why I had been looking for an alternative. Yeah the CSS hack is just that a hack, and as such it has it drawbacks. but I it is nice to have options for when the situation arises.
Going back to the CODE… and I might get FLAMED for this… but the .3em correction is touchy. I did some torture tests : adding borders, trying to line up bg/images, changing the BODY text size. But based on the advice given I kept experimenting and came up with the following solution-- CSS only, of course:
ul {
background:#333;
margin:0;
padding:0;
font-size:1%; /* my 'asymptote' solution to font-size:0 problem!!! Gotta love math*/
/*as each font stack I tested seemed to have its own optimal letter-spacing and word-spacing values, i found it best to use a "specific" stack; sans , serif, or monospaced, font family can easily be reset later. */
font-family:Georgia, "Times New Roman", Times, serif;
/* the following values go best with the serif stack*/
letter-spacing:-.25em;
word-spacing:-.25em;
}
li {
padding:10px;
display:inline-block;
vertical-align:top;
background:#FFA500;
font-size:10000%;/* resets font-size to 100% of parent's parent--nice!*/
font-family:"what ever it was before", Arial, sans-serif;/* resets font fam*/
letter-spacing:0; /*spacing resets*/
word-spacing:0; /*spacing resets*/
}
It seems to work in: FF, O, and Saf and Chr. ( I am on a mac so I haven’t tested IE… but i figure worst comes to worst… it’s a conditional comment fix)
== : )
Keep in mind, the font stack is just an ADDED safety, and normally I do typography CSS separately so, the reset doesn’t even have much if any CSS overhead in actual applications
That 0.25/1% bombs here in Opera due to opera’s minimum font size restrictor.
Also if you are using word-spacing you can set it to -2em and it won’t collapse, which would make the only place it isn’t perfect be webkit.
Oh, and can someone translate noonope’s last post into ENGLISH? I can’t figure out if he’s agreeing with me or taking me to task…
Jason, I read noonnope’s last post several times and still couldn’t tell?
Steve
I checked Opera again. The code holds up!
==: )
I am guessing O only applies the min-size restriction if there is actual text in the node, this not being the case… my method survives. It also makes sense because if the O min-size restriction applied then setting font-size:0 would definitely NOT work. Still, I will keep a close eye on it.
Here are my final conclusions on:
Webkit’s Buggy Word-Spacing Model
Even though the letter/word spacing specs state that “Word spacing algorithms are user agent-dependent”, I still see this as a gross error in Webkit. Their inline-blocks should at least follow the same rules as their inline elements do.
Word-spacing is completely ignored with both positive and negative values on inline-blocks.
Large negative word-spacing values collapse on inline elements causing text overlap. There again the specs state that: “Values may be negative, but there may be implementation-specific limits”, so they found a loophole there.
Firefox, IE8, & Opera all render my four test-cases as expected. Webkit only passes one out of four (positive word-spacing on display:inline).
Even if they don’t consider it a bug they should improve upon it.
@ds60
translation:
if the white space nodes created by your formatting of the html markup are screwing up with the rendering in some cases = html problem != css problem. hence, it’s weird to employ a css weirder solution to solve a white space nodes problem.
at the most, if you don’t want to give up your way of formatting html markup to solve the problem, which is a totally bogus rule, you could use js to alter DOM and remove white space nodes among inline block elements. but css, and even more, ineffective css!, that’s an abnormal option for such a clean cut problem.
noonnope’s notary translation&authentication office
Still not entirely sure I understand you… but if I’m getting the gist of it my response would be anything in the markup that just changing the formatting/white-space would change the layout shouldn’t be done in the first place.
ESPECIALLY when HTML is for structure, CSS is for appearance. What we want to fix here is APPEARANCE, so there’s no reason to be changing the white-space formatting to fix it.
At that point you might as well just declare white-space: pre; on everything and say to hell with CSS formatting… well, that or go back to using HTML 3.2
The REAL problem is one browser not behaving as it likely should or unlike everyone else. You want to strip the collapsed whitespace, that’s what word-spacing is FOR. It would be the best answer to the problem if webkit didn’t have it’s head wedged up it’s backside about it. It’s STILL the best solution in a lot of cases! (where you can skew it to 1px overlap and then make it so that doesn’t matter).
— edit — Christmas on a cracker, I think I found a CSS solution that will work, gotta test it first though but…
Nevermind – I was thinking monospace spaces would always be the same size, but it’s rounded off funny.
HAH, I found another way of handling it!!!
It uses a display property I am usually hesitant to resort to…
table and table-cell.
Naturally IE7- doesn’t like them, but IE handles display:inline just fine so we send it the word-spacing version… and I forgot that IE will collapse elements over each-other with word-spacing unless you set zoomfix. (zoom:1; – and in this case it’s NOT haslayout fixing it!).
I also hate using them because it ALWAYS feels like a cheat – if we want the behavior of a table why aren’t we just using a table… though the answer is that semantically this content probably isn’t a table.
table-cells normally don’t render white space between them – set the li to table-cell and the anchors to inline-block, and you’re close to what we want-- but for some screwy reason all browsers will put a cell-width of padding on the left you can’t control unless to set both table-layout:fixed and border-collapse:collapse; – of course then it’s narrow and we have to set margin:0 auto; – so you can’t render full width without another element - for testing I’m adding a DIV around it, in production I’d probably just use the background-image on the h1 above it (assuming we’re talking about a main menu).
SO:
First up, I made a markup guaranteed to make sure ANY formatting you can come up with is going to render the same way… No human being would write code like this
<div id="testMenu"><ul>
<li><a href="#">test</a></li><li><a href="#">test</a></li>
<li> <a href="#">test</a></li>
<li><a href="#"> test </a></li>
<li><a href="#">test</a> </li>
<li>
<a href="#">test</a>
</li><li>
<a href="#">test</a>
</li>
</ul></div>
All the different spacing types you could possibly have.
The UL gets:
#testMenu ul {
list-style:none;
margin:0 auto;
display:table;
table-layout:fixed;
border-collapse:collapse;
text-align:center;
word-spacing:-2em;
height:1%;
}
display:table to normalize the table-cell behavior and so we can set the fixed layout/collapsed borders. (both properties are ignored otherwise). We then set text-align:center and word-spacing for IE. Really wierd is that FF will often wrap table-cells almost at random when you refresh or hit a new page – this crops up from time to time and the fix is mindblowing…
The Holly Hack!!! The traditional IE haslayout trigger ALSO fixes quirky behavior in FF’s display:table.
The LI get:
#testMenu li {
display:table-cell;
display:inline !ie;
zoom:1;
}
NORMALLY we’d just set the display:inline first since IE doesn’t know table-cell and should be ignoring it… but IE is a total retard on the display property. I hate resorting to !IE, but it’s a quick and easy way to send this one property.
The anchors are just your normal inline-blocks
#testMenu a {
display:-moz-inline-block;
display:-moz-inline-box;
display:inline-block;
padding:8px;
white-space:nowrap;
word-spacing:0;
}
Inside table-cells the text will wrap funny even when there’s enough room for all the cells in FF and sometimes webkit. Adding the white-space:nowrap makes all the browsers behave the same way.
So putting that all together into a demo page:
http://battletech.hopto.org/html_tutorials/inlineMenu.html
We can see that it works – amazingly it works in FF 2 and 3, Opera 9.6+, the latest flavors of Safari and Chrome, and miracle of miracles even works back to IE 5.5.
No IE 5.0 though, it doesn’t know what inline-block is. (Like we give a flying Wallenda!)
So… another technique for pulling it off at least!
@ds60
that’s what i was talking about when mentioning css palliatives.
isn’t your latest in fact Rayzur’s solution, in essence?
as for
anything in the markup that just changing the formatting/white-space would change the layout shouldn’t be done in the first place
the moment you start formatting it’s the moment you alter the DOM. that’s changing the layout. is only that UAs are nice enough to make a “garbage collection” for you instead
Yes and No… It adds something not yet mentioned in this thread; using display:table-cell to remove the white-space. The word-spacing from his (which I’ve used long before this thread ever came up) is only used for IE7 or lower. It throws out the letter-spacing for webkit completely.
Except those textnodes are only checked for a boolean “iswhitespace” when rendering the page, and is ignored outright on display:block and floats… dissappears like it doesn’t even exist.
That’s all we want to do here, is get that same removal of it so we can control the appearance – since APPEARANCE is CSS’ job, not the markup’s.
If we’re gonna let white-space formatting dictate appearance, we’d end up asking “what the devil is this, Python?”
no. i don’t want a removal of something wrong i’m guilty of putting in there in the first place. that’s not css’s job, it’s mine. i simply choose not to put it there. css’s job is to improve on the markup’s appearance not to correct my errors when following bogus formatting rules.
and i believe that basic appearance is html’s job: making a decision on what SEMANTIC element to choose it’s also a decision about appearance. after all, not all elements render the same, right?
to sum it up: you are making a conscious decision to respect too much a bogus rule: formatting your code, no matter at what price. then, you say: “i know it’s a mistake, but i’ll solve it later”. and you do: you employ a wild west css to “bury” the problem. my question is: why make the “kill” in the first place. based on a bogus formatting rule? 
your answer: keeping a format will be impossible. really? how about <pre>? it’s the same thing: a client would have to keep the format inside it, disregarding the fact that it may not match the rest of the page formatting.
the existence of <pre> element is, by it self, proof enough that a simple solution like disregarding stupid formatting rules to fix a rendering problem is viable. you are forced to do the same thing: disregard the overall formatting for the content inside
it.
did i mention simple? which means it can be implemented and understood by devs of all flavours and sorts? leading to less problems than the odd css garbage involving text declarations for block element appearance? that’s a big question mark right there: text declarations for block element appearance!
so, there you are in the same square: #1, solving a formatting problem by css, only to have it demolished by the <pre> element rules. that means that the only viable solutions are:
i believe the above proposals are not so hard to follow and sure enough they will not generate more garbage for you to collect upon later on: exploding some tangled and obscure css in there that will later hinder your vision on the page’s overall behaviour