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

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.

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.

Not sure where you get a ‘mistake’ out of that.

No, we’re just using CSS to apply the appearance we want – which is CSS’ JOB

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

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-space:pre;” – 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-space:pre; it just happens to be the default appearance.

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

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

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.

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 …

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.

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

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!

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

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!)

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…

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)

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.

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!

Wow, big assumption (that’s a joke)

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.

What the … is “tag chaining”?!? You mean white-space stripping?

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

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

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

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!)

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…

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

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

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?

[ot]about my

overwhelming fear of the shift key
it’s how i write my html also [/ot]

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

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

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

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-space:pre; 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-space:pre-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…

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

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

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.

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.

So you’ve never seen a jumpto menu or written a media=“print” CSS file then? It doesn’t imply we EVER plan on showing it… in this stylesheet since we can have stylesheets target DEVICES using MEDIA types.

Like my normal print.css

.jumpto,
#mainMenu,
.borderTop,
.borderBottom { display:none; }

and no I don’t set them to re-appear in the same stylesheet.

or in screen.css

hr,
.jumpto { display:none; }

I use horizontal rules for CSS off and print, they don’t style well for screen so I hide them and set borders instead. .jumpto menus are only for CSS off or handheld, not screen… (well excepting opera’s accesskeys menus, which work display:none or not!)

yet you seem to have a purpose for all of the above, or at least for some use cases.

but this doesn’t seem to be the case with the subject at hand.

White space is a presentational issue. Whether white space exists is a content and markup issue, and its collapse rules are defined in html for the nonce. White space presentation, or rendering, is defined by word-space and letter-space properties, and that’s where the cure belongs. Font size is simply a multiplier, and setting it to zero affects the white space value.

Jiggering the document’s markup formatting to remove certain white spaces will work as a non-robust solution. Its downfall lies in that changing the formatting breaks the solution. If something as simple as that causes breakage, formatting is not the solution.

Most of my work is about fixing html/css problems for developers and, more often, for maintainers. It would seem that most of the world’s sites are coded by non-professionals (to judge by the markup), the formatting often makes the pages unreadable by the Mark I mod 0 human eye. Like Paul, my first step is often to run the source against a reformatting tool; usually Tidy. If someone’s “fix” for a white space anomaly was a formatting hack, it’s now broken. Or, maybe the maintainer had already broken the hack in his editing.

Noonnope, you seem to have only a tenuous grip on the functions of html markup and css rulesets. HTML does not define how an element shall be rendered. As Jason pointed out, html is for rendering in any and every kind of user agent. Only the stylesheet built into every browser defines the default presentation. To see how this works, go to wherever Firefox lives on your machine. In the res directory is a file named html.css. Rename that file (e.g. html.css.orig), and touch html.css. (For those using a legacy OS, create an empty file named html.css) Now open an html document, preferably one without its own stylesheet. Even a pure text browser like Lynx has its own rendering rules; lynx.cfg.

cheers,

gary

i assume you mean sophisticated, but didn’t manage to find the right word your comments are “precious” as always

as for the rest, i’m sorry, but you are just grinding stone to hurt my ears.

really?

HTML does not define how an element shall be rendered[…] html is for rendering in any and every kind of user agent.

you’re savy sounds like infatuation. and if you still believe that a bogus formating rule that breakes the layout is stronger than a sensible solution like removing that formating, you’re just trolling.

removing whitespace between elements has absolutely nothing to do with html. it doesn’t affect the html in any way. also, whitespace between elements has nothing to do with presentation.

so, if UAs don’t know how to always handle your format, don’t resort to css. css is not there to corect your format, but to offer a presentation. that is, in this case you suggest to use css to remove presentation for good, not to alter it, or to make it show later or whatever. correcting formating is your job, not css’s. ponder about it tenuously griping the concept, please

there are three wrongs:

• formating whitespace does not equal to whitespace used in presentation, default or otherwise
• using css to solve a bogus formating markup option is like using html to solve a presentation problem
• believing that removing format means altering the markup

adding elements, that’s true manipulation of the markup.

adding format to your markup does not alter the markup, it’s messing up with the DOM, by adding whitespace nodes.

these nodes have no business being there in the first place. there is no fourth layer: formating. only three: HTML, CSS, JS. and neither impose rules about formating.

so, your problem about removing whitespace OUTSIDE elements, and considering that whistespace manipulation OUTSIDE elements is about presentation and about markup manipulation, that is a complete false problem.

using css to remove whitespace introduced NOT by markup NOR by presentation, but by markup formating, that’s the wrong use for what it supposed to be a tool to introduce presentation, not remove it.

yes, you do manipulate whitespace with css. but let’s be clear, that’s presentation whitespace, whether author’s or user’s. the whitespace we discuss it’s not that. it’s a rendering bug of the formating whitespace. a complet different type. forced in there by bogus formating rules.

yes, you maybe use hide elements with css. but if you never ever show them again, if they are not needed for a graceful degradation, they don’t belong in the markup in the first place. you need to remove them. and so it is about formating whitespace. you need to remove it as you never have a need for it. don’t use css as a palliative for what it should be a DOM modification.

Rendering != “visual appearance”, though usually graphical desktop browsers choose the appearance as they bring the content to the screen. However, a scraper bot also gets text rendered to it… without form or style.

adding format to your markup does not alter the markup, it’s messing up with the DOM, by adding whitespace nodes.

these nodes have no business being there in the first place.

When first learning Javascript, this really pissed me off: some browsers would consider newlines the same way as markup whitespace, while others didn’t (correctly I believe… look, IE doing something right!).

Whitespace between words, and between inline tags, has meaning. They should not be removed in order to achieve some particular visual setup.

Newlines, however, are usually something the developer (or client) does to ease reading, not because they want to change the meaning. Ideally the user agent should ignore these newlines because they are not content. But, browsers aren’t ideal, so we hack for them.

I’d rather use CSS for the hacking because of the reasons mentioned above: I can’t have my code break depending on whether someone ran the HTML through a newline-remover/code optimiser or not. I don’t think it SHOULD be able to break my visual styles, but here it does, so in an imperfect situation, I’ll choose CSS.
Similarly, while I’d like to remove whitespace so I can more easily find children of DOM nodes in Javascript, I instead add extra loops checking for nodeType ==3 or not because someone somewhere may add a newline, and that should NOT be able to affect the children I’m after… so I make my JS more robust.

hmmm…

so you say: html is pure text. i agree.

so, why the tags then? since it’s only text, there is no need for any tags notepad as a UA will do just fine.

only for semantic? but semantic alone, w/o any visual distinction, is only useful for “scaper bots”. i thought those are not the primary targets. users are. and users need a consistent visual representation of the written web. which is why you use tags. to give a distinct meaning&visual representation for different part of your message.

there is an equal weight for semantic and visual representation there. you choose a semantic element because it’s having also a default inherited presentation, by default. inherited from what old scribes learned it’s best to pass on the written word, that you can mess now with using styles. lynx can’t handle visual. guess what: that’s the reason GUI UAs have been thought off. to overcome text-mode confusion.

semantic alone means s%*t. you talk to the user, not the seo. you talk about user styles, agent styles, author style like it has nothing to do with the markup. it has everything to do with it. yeah, you can change each and everyone of them. and i can try and make square U-turns

stop pretending web gave the written word a new meaning. web it’s just a conveyer for the Gutenberg old way.

don’t try and say: web has changed the way a written item looks and feel. web has brought one new thing alone: spreading speed. that’s it. all the rest have been thought off and invented far long ago. and web obeys this system.

stop looking for hidden meanings when things are so simple. there is no wisdom in hotchpotch, only self-absorbance of a narrow-mind

so, why the tags then? since it’s only text, there is no need for any tags notepad as a UA will do just fine.

Please, please, use a screen reader. I dare you to experience it. Learn how to use it. Then navigate your favourite web pages. The ones built out of all tables or all divs will not delight you. The ones using headers, lists, and proper structure will speed up your use of the page immensely.

They are not scraper bots. Quit downplaying who semantics are for. They are for people, and occasionally for other programs since, why not?

you choose a semantic element because it’s having also a default inherited presentation, by default.

No; if I did, why am I always changing the default presentation?

lynx can’t handle visual.

Actually, it does… in a strange way. These forums, for example, are in tables… and Lynx does show that.
I’m on these forums about half the time using Lynx or Elinks. The problem is they don’t show where quotes are or when quoted text ends : ( which is vBulletin’s bad code I assume.

semantic alone means s%*t.

True. If there is no UA or user who understands their meaning, they have no meaning.

stop pretending web gave the written word a new meaning. web it’s just a conveyer for the Gutenberg old way.

Not really: watching my husband struggle with a German client who wanted their newpaper ads (which were archived as PDFs) to be searchable on the web was quite eye-opening in how easy HTML is. In the PDFs, like print, there are no words, no letters even: everything is a glyph, with a size, and a placement on the page with page locators. Your closest “context” is that there is another glyph of x-size whose coordinates may be “close” to the spot your glyph is. Hubby ended up writing a Perl Module (postscript::textDecode) which looked for the largest glyphs, then went through several pages of rules looking for things that should match… luckily, in the PDFs, the person’s name was the largest text but almost never the first text, so a lot could be eliminated by looking at glyph size.
Everything was coded with strange PostScript codes with Adobe proprietary glyph maps. You couldn’t just “read” it, nor could the program. A lot like if you had large, relief words on a wall and you were blind: you could feel the shapes of the letters but it’s not like you could just “read” them.

web has brought one new thing alone: spreading speed. that’s it. all the rest have been thought off and invented far long ago. and web obeys this system.

The web has brought the world into the homes of the locked in and the visually impaired. Before, it was Audio Books and recordings of the news sent through the mail, or your family came to read to you. : ( This is huge. Absolutely huge.

i would, but i’m afraid that by your own words, it wouldn’t do me any good.

remember?

Rendering != “visual appearance”

now, that also means

Rendering != “aural representation”

since visually it has no importance, why would it aural?

let’s get to basics and logic. we’re talking words here. let’s make a comparison. words vs. people.

words w/o tags. people w/o specifics.

words w/ tags. <h1>Big words</h1>. people w/ specifics. <height7">Tall people</height7">.

that means that, in order to convey semantics, you rely on visuals.

now, about why you change the default style. because you’re advertising. you know, like flowers hopping to get visited by many bees. but changing default style also leads to confusion. it can also lead to error. you could convey the wrong meaning, like making h3 bigger than h1. would that make it semantically wrong? yes. why? you answer me but i have an idea: visuals!

as for aural. what if you start changing aural style the wrong way? it’s like someone threatening your life while smiling. is that making you misunderstand the threat? are you smiling back? that’s why default style has its place. conveying semantic.

above is 7ft not 7".

the problem with that is that you assume. you assume nobody would break your css solution. you assume nobody will trip or mess with it. you assume they will understand where the css hack for your inline-block bug starts and where it ends. you assume they will remember and have skills to make it work and provide good assimilation with complex css code.

i say you assume wrong. i say it’s easier to remember and fix this whitespace bug in the markup formatting. messing or tripping with this solution it’s far less likely to provoke future complex problems.

even more, that whitespace in the markup formatting has no use as far as the content is regarded. but you keep it there to indulge your code writing aesthetics. i say you’re vain missy

one more thing, the most important one: changing formatting markup whitespace IT’S NOT THE SAME OR EVEN NEAR with changing markup. you are changing the WAY you place your markup in your file, not the ACTUAL markup used for content. that’s the misunderstanding leading to this false problem in the first place.

why false? because you may:

• use formatting for your markup
• use some formatting for your markup
• use no formatting for your markup

and all these w/o degrading or improving your markup, but your in-file placement of your markup bits.

it has no ties to the actual content, apart from causing your content to break sometimes. that says that the one to be sacrificed is it: formatting, not html, nor css. sacrificing formatting has no “manipulate presentation in markup” meaning. it says “sacrifice visual placement of the markup in the file, w/o interfering at all with the markup and saving the css interference later on”.