font-size:0 DOES NOT kill white space bug in Saf/Chr

[noonnope]

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

[Paul O'B]

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 ?

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 one learns its lesson quickly or pays for it until he does

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"

[noonnope]

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

[dresden_phoenix]

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

[deathshadow60]

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...

[ServerStorm]

Jason, I read noonnope's last post several times and still couldn't tell?

Steve

[dresden_phoenix]

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.

[Rayzur]

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.

[noonnope]

@ds60

translation:

- formatting html markup: newlines, indentation etc produces white space nodes = html action
- manipulating white space nodes = html action != presentation != css
- removing whitespace between the end tag and the start tag of two sibling inline block elements: html related action, not a presentation problem or a css related action.


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

[deathshadow60]

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...

[deathshadow60]

Nevermind -- I was thinking monospace spaces would always be the same size, but it's rounded off funny.

[deathshadow60]

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_tut...nlineMenu.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!

[noonnope]

@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

[deathshadow60]

@ds60
isn't your latest in fact Rayzur's solution, in essence?

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.

@ds60as for 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

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?"

[noonnope]

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.

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:

• repairing what a cms does wrong
• teach your clients/let other devs know where and what not to screw up

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

[deathshadow60]

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.

NO, it isn't. See, that's what I think you're missing about semantics -- it's about saying what things are NOT how they appear! The default appearance of HTML in the browser without CSS is in fact ENTIRELY up to the browser -- that's the original POINT of HTML; Device independance. Allow the user agent (browser) to best decide how to present the content.

We got away from that during the browser wars with all the pointless presentational crap that got added to the specifications as Netscape and IE sat there endlessly trying to one-up each other... hence the resulting disaster known as HTML 3.2 -- HTML 4 and more specifically STRICT is supposed to throw all that away and put HTML back doing what it's supposed to do.

The default appearance may be conveying the meaning, but that appearance and behavior is NOT the meaning of the tags. User agents in fact are fully free to display HTML however they like -- check the specification; there's lots of 'user agents usually' or 'user agents may' and not a whole lot of "user agents should".

CSS was created to say what the appearance should be - that's it's JOB.

to sum it up: you are making a conscious to follow a bogus rule: formatting your code, no matter at what price.

No, we're making the decision to say that the formatting shouldn't matter one way or the other; that way developers can use any formatting they want since you never know what the next guy is going to try and do.

There's a big difference on that.

then, you say: "i know it's a mistake, but i'll solve it later"

Not sure where you get a 'mistake' out of that.

you employ a wild west css to "bury" the problem.

No, we're just using CSS to apply the appearance we want -- which is CSS' JOB

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 may not match the rest of the page formatting.

Actually that's why I made the comparison as PRE is there as a tool to say "this is preformatted content".

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.

No, it's for presenting preformatted content. HTML outside of PRE is not pre-formatted content... though if you REALLY want to treat it that way, that's why CSS has "white-spacere;" -- since that's controlling appearance. There's actually nothing stopping you from turning white-space back to normal on a PRE element if you are applying just a monospace font and your own formatting elements to it. PRE does not mean white-spacere; it just happens to be the default appearance.

It's that separation that I think you're not quite grasping.

did i mention simple? which means it can be implemented and understood by devs of all flavours and sorts?

... and when the first joker to come along and run it through pretty-print breaks the layout? Or runs it through that white-space stripping nonsense and breaks it the other way?

leading to less problems than the odd css garbage involving text declarations for block elements appearance? that's a big question mark right there: text declarations for block element appearance!

Not even sure what you mean by that... unless you mean the two text-aligns for IE5 support which is... odd... either that or you don't understand what word-spacing is for (controlling collapsed white-space between textnodes and inline styled dom elements)... If that's "confusing" then they probably have no business screwing with the CSS.

[noonnope]

The default appearance of HTML in the browser without CSS is in fact ENTIRELY up to the browser...

funny, all browsers seem to show h1 the same way. must be a conspiracy of some sort... the same about p. oh, they render the font differently, yes, but ...

We got away from that during the browser wars with all the pointless presentational crap that got added to the specifications as Netscape and IE sat there endlessly trying to one-up each other... hence the resulting disaster known as HTML 3.2 -- HTML 4 and more specifically STRICT is supposed to throw all that away and put HTML back doing what it's supposed to do.

i don't see anything related to the whitespace problem in the above paragraph. the white space nodes are not a css problem. since it's a node, it's DOM. it's not presentation nor appearance, it's existence. hence, not a css problem.

you don't need to hide it to show it later, you need it not to exist. not a css problem, is it? if not html, than a js problem. but css... no way.

No, it's for presenting preformatted content. HTML outside of PRE is not pre-formatted content...

it's breaking your rules about formatting. so you have a subjective way to keep this rule. and wrong.

... and when the first joker to come along...

what's different for <pre>? the problem about formatting remains: you need to enforce some rules to make it work, rules that will step over your formatting. why wouldn't you enforce a good one? beats me.




let's say i'm the client. you come along and guide me step by step through your template code and tell me "it's a must, a wonderful solution for a browser mishap". a complicated solution in fact that he has to grasp and maintain, because otherwise it may break.


than the client wises up. he learns that he could have less code to maintain, less to worry (only a chaining of the tags vs. a css plethora), less to keep in place when changes apply. the logic conclusion: shake down.

the client then concludes you're a slick pushing up the envelope at his expense. he'll try to make some savings in the future i would too if i was put in a situation like this: a complicated solution and probably more money versus a simpler solution, that's easy to fix if forgotten, it's easy to maintain and easy to understand.




let's say i'm a dev. i have to maintain a site implementing css frenzy like that. i learn later on about a better way, but i keep getting sites to maintain having the same overcomplicated solution. what do i do: do i choose to continue maintaining a whole new css chapter, or do i just enforce a simple, dumb even formatting rule, that's easy to fix if forgotten?




let's say i'm a dev and maintain my own sites. i learn that for one of my necessary css hacks there is a very simple solution: tag chaining of some elements. what do i do: i choose to stay with the same methods, methods that mean a overly complicated code, overly complicated code that's easy to mess up, messing up that means lost time for debugging, or do i just make a notch on my tally to remember an easy to maintain and easy to understand solution?




finally, there is no way i'm using formatting to help me with presentation, by chaining tags. nor a certain way to format ensures an unblemished html markup. if my bogus formatting is dumb enough to cause a white nodes creation that's leads to a rendering "problem" (it's a node doing its thing, what would you expect?), do i stay dumb? do i use the smartphone i get for my birthday as a tire stop for my uphill parked car? i mean:

WHO SAYS I SHOULD EVER USE FORMATTING? NOBODY IN THIS WORLD IS SAYING THAT! THE PROBLEMS AND PRESENTATIONAL IMPLICATIONS CAUSED BY MANIPULATING THE FORMATTING ONLY EXISTS IN ALICE'S WONDER WORLD WHERE HEADS FLY BODILESS AND CATS TALK!

[deathshadow60]

funny, all browsers seem to show h1 the same way. must be a conspiracy of some sort... the same about p. oh, they render the font differently, yes, but ...

You mean like Lynx? where it's all the same size and in most user styles everything after it is indented one tabstop to indicate that it's the HEADING for all content that follows? You mean like on a screen reader where many of them will say "start of section ______"? H1 does not mean "bold font in 200&#37; size", it means the primary heading for the document content... Just as H2 means 'start of a subsection of the h1' and so on and so forth.

Or paragraph, which means PARAGRAPH, not "display:block; margin:1.2em 0;"... You might strip the margin off and use padding.... you might strip the margin off and set it to text-indent:2em.... doesn't change the meaning of the tag. The default presentation of an element is NOT it's meaning, though it may CONVEY that meaning.

i don't see anything related to the whitespace problem in the above paragraph. the white space nodes are not a css problem. since it's a node, it's DOM. it's not presentation nor appearance, it's existence. hence, not a css problem.

EXACTLY WHY it's relevant -- the DOM has NOTHING to do with presentation or application of style. What we want to do to PRESENT the content... application of presentation and style which is why it's CSS' job to give us the appearance we want; NOT HTML's. We don't want it to appear -- just like we might not want HR's to show up for screen while we want them when CSS is off, or how we might have an access key/jumpto menu for accessibility reasons that we don't want to show up and set display:none on. ALL we want to do is change the appearance for targeting screen...

Hell, if your arguement held any weight we wouldn't be setting display:inline EITHER... or floating them, or doing anything else to them since the DEFAULT behavior on the element we are most of the time fighting against is BLOCK. (NOTICE my fix puts it on the LI and not the anchor, but still sets the anchor to inline-block since we want to put dimensions on it!)

you don't need to hide it to show it later, you need it not to exist. not a css problem, is it? if not html, than a js problem. but css... no way.

Actually let's be specific - I used the wrong wording, we don't care if it exists or not -- we just don't want it to appear for SCREEN. Hell, we might WANT it to appear for print, or handheld... much less braille, embossed, speech, tty...

it's breaking your rules about formatting. so you have a subjective way to keep this rule. and wrong.

Again I'm not sure what you are referring to... the 'rules' I use for formatting my code is to make it easy to read and follow. In terms of the page rendering the formatting should make NO DIFFERENCE... or if it does I should be able to override it from CSS since APPEARANCE is CSS' job, and I might not want to override it EVERYWHERE.

Media types, they rock... when browsers pay attention to them properly. (Thanks Gecko and Trident for being #DDD)

what's different for <pre>? the problem about formatting remains: you need to enforce some rules to make it work, rules that will step over your formatting. why wouldn't you enforce a good one? beats me.

let's say i'm the client. you come along and guide me step by step through your template code and tell me "it's a must, a wonderful solution for a browser mishap". a complicated solution in fact that he has to grasp and maintain, because otherwise it may break.

That's going to go WAY over most clients heads in my experience, and people are MUCH more likely to start messing with the markup than they are to go anywhere NEAR the CSS.

than the client wises up. he learns that he could have less code to maintain, less to worry (only a chaining of the tags vs. a css plethora), less to keep in place when changes apply. the logic conclusion: shake down.

When something as simple as hitting <enter> in the document will break the layout -- you try explaining that to a client and be prepared to be laughed out of the room. As to less code, I'm a stickler for minimalism and using less code -- But the absurd extremes you seem to be willing to take it to make me look like someone who just slaps DIV's and classes around everything fifteen to twenty times per element "because I can".

Especially when the ONE code example we've had of your work so far was knee deep in said trap adding two or three pointless div's with four or five pointless presentational classes. Put your optimizations where they count!

let's say i'm a dev.

Wow, big assumption :P (that's a joke)

i have to maintain a site implementing css frenzy like that.

eight lines of CSS for three elements is a 'frenzy'? You don't do practical CSS a whole lot, do you? That or nothing you write actually works cross-browser, which I'm really starting to suspect is the case. Would probably be more the case if we could see some stuff that was more practical than anecdotal.

let's say i'm a dev and maintain my own sites. i learn that for one of my necessary css hacks there is a very simple solution: tag chaining of some elements.

What the ... is "tag chaining"?!? You mean white-space stripping?

what do i do: i choose to stay with the same methods, methods that mean a overly complicated code

We're in two different worlds on what overcomplicated means.

that's easy to mess up,

Which we also seem to disagree on what that means, as markup is usually much more prone to end user screwups than CSS.

finally, there is no way i'm using formatting to help me with presentation, by chaining tags. nor a certain way to format ensures an unblemished html markup.

Huh, you just contradicted your entire arguements in this thread!?! Ranguage barrier again?

if my bogus formatting is dumb enough to cause a white nodes creation that's leads to a rendering "problem" (it's a node, what you'd expect?), do i stay dumb?

Depends on if there's a REASON for the formatting, like clear concise easy to maintain and develop markup. Playing games with the white-space just for appearance is stupid, and much more prone to breakage than CSS that has no reason for a user to edit unless they are creating a new theme. (at which point they should know enough CSS to follow what's going on!)

WHO SAYS I SHOULD EVER USE FORMATTING? NOBODY IN THIS WORLD IS SAYING THAT! THE PROBLEMS AND PRESENTATIONAL IMPLICATIONS CAUSED BY MANIPULATING THE FORMATTING ONLY EXISTS IN ALICE'S WONDER WORLD WHERE HEADS FLY BODILESS AND CATS TALK!

Wow, rules 39 and 40 back to back Lemme guess, blown power steering pump?

Though it's really funny, I was making the same arguements you are now six years ago when I was still shitting out pages in a half assed manner since I didn't know enough HTML or CSS to see the value of doing the separation properly...

[noonnope]

it's really funny you keep linking a formatting issue to css and manage to intermingle assumptions about my knowledge. we seem to hit a ranguage barrier every time i make a point you don't like

you don't want to make a presentation in this case, you try to get rid of, to delete, to permanently hide something. css is not for that.

about being laughed out of a room: what say you when your moderate size and low difficulty css solution gets blown away by a simple end-tag start-tag chaining: </div><div>. like the one you're using: </head><body>. true, not for the same reason, but it's there, nonetheless.

i don't know why, but i really want to kiss you! that is, to make you see the truth behind keep it simple stupid! not that you are anything like that. i really don't mean "stupid", but that's how they decided to put it

[deathshadow60]

it's really funny you keep linking a formatting issues to css and manage to intermingle assumptions about my knowledge. we seem to hit a ranguage barrier every time i make a point you don't like

Actually it just comes up whenever you say something that contradicts what you just said one post or even one sentence earlier... Though really 90&#37; of the time I'm having to guess WILDLY at anything you are trying to say as it's all gibberish. Improper tenses, statements that I think you forget words like "not", etc...

Your overwhelming fear of the shift key and conjunctions doesn't help matters much either.

Conjunction junction, what's your function?
Hooking up words, or phrases and clauses...

I mean, the paragraph I quoted -- you basically said you'd never use the technique you are advocating in this thread!!! What are we supposed to think?!?

If you're saying we can't use the formatting changes and "tag chaining" as you call it to remove it.... and we're not supposed to use the CSS method --- what are you saying we should use? Strong language?

[noonnope]

Actually it just comes up whenever you say something that contradicts what you just said one post or even one sentence earlier...

i've been consistent all along. font:0 is not a solution, is a palliative. so is your css solution or any other css solution presented here.

i stayed loyal to one solution only: end-tag start-tag chaining for sibling inline block elements: </li><li>. which i use. i used to play with word-spacing, letter-spacing. but that was

six years ago when I was still shitting out pages in a half assed manner since I didn't know enough HTML or CSS to see the value of doing the separation properly...

a simple solution, affecting the formatting. or that can be break by the formatting.

if it's affecting the formatting, who cares. nobody has clear rules, there aren't any recommendation to follow, it's just an arbitrary dev whim. if it gets in the way of a simple solution, it isn't an issue.

if the breaking by applying a formatting seems like an issues, it isn't. not as long as the <pre> enforces formatting restrictions. and not as long as the rule is simpler than a whole new css hack chapter


to clear out even further your confusion about my position: yes, i believe manipulating the formatting you employ is not by far a mistake. and yes, i believe following formatting until it proves harmful for your code is a mistake. clear position: drop the formatting that breaks your rendering. formatting is nil. as such, it can be sacrificed. one more thing though, and there lies your confusion: make it sure it's in your own interest. and that means enforcing a formatting rule: end-tag start-tag sibling inline block elements. confused?

Off Topic:

about my

overwhelming fear of the shift key

it's how i write my html also

[deathshadow60]

i've been consistent all along. font:0 is not a solution, is a palliative. so is your css solution or any other css solution presented here.

No more so than white-space stripping... shoving an incorrect CSS behavior from one program under the rug in the wrong place! -- see rayzur's example that the ONLY real problem with it is that webkit is a retard not making inline-block behave like display:inline. If it did all we'd have to say in the CSS is word-spacing:-2em; (and maybe zoomfix for legacy IE).

i stayed loyal to one solution only: end-tag start-tag chaining for sibling inline block elements: </li><li>. which i use.

Which you then wrote a paragraph saying you'd never use.

if its affecting the formatting, who cares. nobody has clear rules, there aren't any recommendation to follow, it's just an arbitrary dev whim.

Which is why you should use a technique where whatever formatting is used DOESN'T MATTER.

not as long as the <pre> enforces formatting restrictions.

Which it doesn't 'enforce formatting restrictions' since you can apply any formatting to the tag you want, since <pre> means pre-formatted text, NOT white-spacere; You might add spans inside the PRE around tabs to force them to two space and set it back to white-space:normal so you get wrapping behavior (with a matching text-indent to tab in wrapped lines).... or white-spacere-wrap, pre-line or any of the other values. You might just turn it off and set it to monospace for showing ascii art or data-streams where you want word-break enabled.

That's one of the reasons CSS exists. To let the developer choose how they want the markup presented to the user.

See the CSS3 property "white-space-collapsing"

Wait, isn't webkit usually sitting their licking their own horn over their advanced CSS3 support? I wonder...

[noonnope]

Which you then wrote a paragraph saying you'd never use.

no, which you intentionally misinterpreted (read juggled) to appear so.

Wait, isn't webkit usually sitting their licking their own horn over their advanced CSS3 support? I wonder...

i've said it before, even here on SP. ie8 and ff3.6 have better implementations where it counts. so them being #1 and #2 it isn't really by chance or circumstance.


as for the reason css exists, in this case is a far stretch, since the action presented is about the total anihilation not about a presentation feat. a presentational feat requires a change in appearance not a total lack of it, all the time.

yes, you could hide a part at one point, but that's just to make it show later on. which is not the case here. and not a css job. that said, js would be out of a job if all nodes related actions would be managed by css code. and this is about a node: to make it disappear. not to dress him nice or to hocus-pocus it later. the goal here is to kill it. again, not a css job.


to make it simple: css is about appearance not disappearance

[deathshadow60]

to make it simple: css is about appearance not disappearance

Then why do we have display:none; and visibility:hidden; ? It's not about deleting it from the dom or making it not exist, it's just we don't want it to show -- JUST like it doesn't show between floats, or block level elements.

For example:

<div>Test1</div>&emsp;<div>Test1</div>
<br /><br />
<div>Test2</div> <div>Test2</div>

By using a non-whitespace EM width space, we are making a cdata textnode, identical to the textnode of whitespace except that it doesn't have the whitespace boolean on it. Whitespace's default behavior may be to collapse to a single space, but it's ignored between floats and blocks... all we want is a inline-block that does that too.

Oh, and apparantly NO browsers support that particular CSS3 property yet. Shame, that would have been a easy fix. TECHNICALLY

http://www.w3.org/TR/css3-text/#white-space-collapsing0

Is the EXACT CSS property to do what we're talking about -- so apparently it's so much CSS' job, it's planned for part of the CSS3 text module.

[noonnope]

Then why do we have display:none; and visibility:hidden; ? It's not about deleting it from the dom or making it not exist, it's just we don't want it to show --

yet


using the above implies you plan on changing it's appearance later to display:block, visibility:visible or whatever. but in our case, your intention is to terminate its existence you don't have a later use for it. even more, you don't plan a later use for it.