Burn in hell CSS. I'm using &nbsp; and <br>.

Me: Hey IE!
IE: what&apos;s&nbsp;up?
Me: Just DIE!

Why should we use CSS when we can just use "&nbsp" ?!

(Found at work...)

I'm editing the sidebar on one of our websites, and shuffling some entries. It involves moving some entries in/out of a dropdown and contextual sidebars, in/out of submenus, etc. It sounds a little tedious but overall pretty trivial, right?

This is day three.
I learned React+Redux from scratch (and rebuilt the latter for fun) in twice that long.

In my defense, I've been working on other tasks (see: Alerts), but mostly because I'd rather gouge my freaking eyes out than continue on this one.

Everything that could be wrong about this is. Everything that could be over-engineered is. Everything that could be written worse... can't, actually; it's awful.

Major grievances:
1) The sidebars (yes, there are several) are spread across a ridiculous number of folders. I stopped counting at 20.
2) Instead of icon fonts, this uses multiple images for entry states.
3) The image filenames don't match the menu entry names. at all. ("sb_gifts.png" -> orders); active filenames are e.g. "sb_giftsactive.png"
4) The actions don't match the menu entry names.
5) Menu state is handled within the root application controller, and doesn't use bools, but strings. (and these state flags never seem to get reset anywhere...)
6) These strings are used to construct the image filenames within the sidebar views/partials.
7) Sometimes access restrictions (employee, manager, etc.) are around the individual menu entries, sometimes they're around a partial include, meaning it's extremely difficult to determine which menu entries/sections/subsections are permission-locked without digging through everything.
8) Within different conditionals there are duplicate blocks markup, with duplicate includes, that end up render different partials/markup due to different state.
9) There are parent tags outside of includes, such as `<ul>#{render 'horrific-eye-stabbing'}</ul>`
10) The markup differs per location: sometimes it's a huge blob of non-semantic filthiness, sometimes it's a simple div+span. Example filth: section->p->a->(img,span) ... per menu entry.
11) In some places, the markup is broken, e.g. `<li><u>...</li></u>`
12) In other places, markup is used for layout adjustments, such as an single &nbsp; nested within several divs adorned with lots of styles/classes.
13) Per-device layouts are handled, not within separate views, but by conditionally enabling/disabling swaths of markup, e.g. (if is_cordova_session?).
14) `is_cordova_session` in particular is stored within a cookie that does not expire, and within your user session. disabling it is annoying and very non-obvious. It can get set whether or not you're using cordova.
15) There are virtually no stylesheets; almost everything is inline (but of course not actually everything), which makes for fun layout debugging.
16) Some of the markup (with inline styling, no less) is generated within a goddamn controller.
17) The markup does use css classes, but it's predominately not for actual styling: they're used to pick out elements within unit tests. An example class name: "hide-for-medium-down"; and no, I can't figure out what it means, even when looking at the tests that use it. There are no styles attached to that particular class.
18) The tests have not been updated for three years, and that last update was an rspec version bump.
19) Mixed tabs and spaces, with mixed indentation level (given spaces, it's sometimes 2, 4, 4, 5, or 6, and sometimes one of those levels consistently, plus an extra space thereafter.)
20) Intentional assignment within conditionals (`if var=possibly_nil_return_value()`)
21) hardcoded (and occasionally incorrect) values/urls.

... and last but not least:
22) Adding a new "menu sections unit" (I still haven't determined what the crap that means) requires changing two constants and writing a goddamn database migration.

I'm not even including minor annoyances like non-enclosed ternaries, poor naming conventions, commented out code, highly inefficient code, a 512-character regex (at least it's even, right?), etc.

just.

what the _fuck_

Who knew a sidebar could be so utterly convoluted?

Adding some <br> or &nbsp; for spacing... we all have done it. Admit it.

&nbsp;

Previous front end dev apparently was not aware of padding and margin.

The html is riddled with &nbsp; and <br>

Shoot me now

<li> tags = good, but this... This is far superior…

&nbsp; - Everyone abused it to create empty space 😂

Don't say you know css if you use &nbsp; to center an element.

So my old school left this like this for a year or two now. Should I tell them that it's not gonna fix by itself magically?

TIL you can crash a Tomcat request processing if the app reads request bodies using a reader() and you feed it a json body with an innocent nbsp :) the whole request processing just goes *pooooft*

reminds me of an ios bug which could brick the phone if it received an sms with weird chars.

These lynch-pin-bugs where a single byte/char in the right place at the right time can tear things down, are so subtle and fascinate me for some reason :)

Was explaining the usage of &nbsp and white space in HTML to a confused nondev colleague. He later asked how come there is white space, when this program you use to code is a black..while pointing to my dark themed text editor.

I was a child and I was playing Habbo, I found a friend who was very enthusiast of the Habbo world, exactly like me, and we spent a lot of time among the fansites. So he asked me "why don't we create our own fansite?" and I answered "yes! Of course!" I didn't know what was a programming language or what was HTML, I thought I had just to click some button and that's it. Anyway I didn't discouraged and after 2 months our website, full of tables and &nbsp;.
After the first attempts, our website remained live for other 4 years.
If I didn't play Habbo, if he didn't ask me to create a website, if I gave up I don't know where I would be now

I added once around 7 &nbsp; to make space between buttons

HTML Writers Guidelines

When designing your web site you want to make the visiting experience as enjoyable as possible and at the same time make it so that if the site needs to be changed in any way, the changes are not too difficult to make. You want the look to be as appealing as possible for all browsers and also make the site accessible to users with disabilities. In order to accomplish all this there are some general guidelines when creating your HTML code.

1. The first thing that will really make your life easier is through the use of Cascading Style Sheets (CSS) - CSS is used to maintain the look of the document such as the fonts, margins and color. HTML directly on the page is not a good choice to handle these aspects because if say, the font color you are using for certain paragraphs needs to be changed from blue to red, you would have to go in and change each color tag manually. By using CSS you can designate the color for each of those paragraphs just once in the CSS file. That way if you have to change the font color from blue to red you make one change instead of the countless number of changes you might have to make, especially if your web site contains hundreds of pages. This is a big time saver and a must for all professionally designed web sites.

2. Don't use the FONT tag directly in your HTML code - This becomes a problem when using some cheap authoring tools that try to mimic what a web page should look like by using excessive FONT tags and nbsp characters. These tools end up creating web pages that are impossible to keep maintained. There is a program you can use, if you've created one of these disaster pages, called the HTML Tidy Program which you can actually download here . This will clean up your code as well as possible.

3. You want your web pages readable to people who have disabilities - People who surf the Internet depend on speech synthesizers or Braille readers to interpret the text on the page. If your HTML markup is sloppy or isn't contained in CSS the software these people use to read pages have a difficult time in interpreting these pages. You should also include descriptions for each image on your page. Also, don't use server side image maps. If you are using tables you should include a summary of the table's structure and also associate table data with the correct headers. This gives non visual browsers a chance to follow the page as they go from one cell to another. And finally, for forms, make sure you include labels for form fields.

By following just these three guidelines you give your visitors, especially disabled visitors the best chance of having an enjoyable visit to your site while at the same time making it so that if you have to make changes to your site, those changes can be made easily and quickly.

Q: How did the developer ask their partner to leave them alone?

A: They inserted an &nbsp;

Meanwhile in OS X: Pressing alt-space gives you a nbsp, not a normal space character. Happens quite easily after a pipe on my layout. Just suck in the pain of that syntax error.