• Banyaluka (unregistered)

    I'm still scratching my head...

  • Dennis (unregistered)

    Nothing terrible about CSS. Plenty of terrible about how people use it.

  • Noname (unregistered)

    It's just a dirty trick to make columns of equal height (see for instance https://css-tricks.com/forums/topic/equal-height-columns-in-css/)

    The 9999px padding is a bit unusual, but -9999px margins are pretty common, used for image replacement, or to hide content from screen (but leave it available for screen readers).

  • foxyshadis (unregistered) in reply to Dennis

    If you haven't needed horrible CSS, you haven't made complex layouts that actually worked cross-browser. And I'm not even talking about IE6, which is a layer of hell that's probably against Geneva conventions. (I started with IE3, which was just randomly buggy enough that you never knew if you actually screwed up or it was the browser. At least IE6 consistently fucked up.)

  • Quite (unregistered)

    We have just come out from underneath a bug in IE whereby, unless you pass the IP4 address of the target URL to our web application, it shunts you into "quirks" mode. We'd been wondering why the hell our neat layouts in GC and FF etc. look completely unhinged in IE ...

  • cjb (unregistered) in reply to Quite

    Sounds more like some has turned on Enterprise Mode and has a bad Sites.xml.

    https://technet.microsoft.com/en-us/itpro/internet-explorer/ie11-deploy-guide/what-is-enterprise-mode

  • JustSomeDudette (unregistered) in reply to Quite

    Wow, that must have been a task figuring that out.

  • Eric (unregistered) in reply to Dennis

    I think we call that "Stockholm Syndrome."

  • donotthink (unregistered)

    It's probably a botched image replacement technique. The below should now be your goto for such glorious things:

    .hide-text { text-indent: 100%; white-space: nowrap; overflow: hidden; }

    First described at http://www.zeldman.com/2012/03/01/replacing-the-9999px-hack-new-image-replacement/

  • (nodebb) in reply to foxyshadis

    Pfft. IE3 used HTTP/0.9 on its HTTP action/URL line, which meant that it was impossible to get anything from www.microsoft.com with it in 2000.

    Seriously, its requests started GET http://www.microsoft.com/ HTTP/0.9 ...

  • Vish (unregistered)

    Frist is hidden due to CSS error

  • Zenith (unregistered)

    The real WTF with CSS and DIVs is that nobody ever tackled the root causes of why people use tables for layout. Relative width and height have zero context. Are they relative to child, the parent, or the screen? This lack of reference is why it's such a fight to get equal column heights or remove ye olde letterboxing effect from the sides of the screen or any number of other layout issues that inevitably follow when some hipster proselytizes for the Church of DIV.

  • Yazeran (unregistered) in reply to JustSomeDudette

    If you want to talk about ierd IE behaviour, then consider this:

    normal web form:

    ..... stuff
    .. stuff <form>... <input id='jquery_autocomplete'>... </form>
    stuff <script> jquery code for autocomplete field </script>

    If you do that in IE, all looks normal until someone enters something in the auto complete field. When that happens the field vanishes but the auto complete suggestions can still be selected (and submitted), but the content of the field can no longer be changed as it is gone form view! The only way to get the field back was to reload the page.

    In chrome and FF all worked as it should.

    Can anyone spot what was causing the error (besides using IE i mean)? Evil grin

    Yazeran

    Plan: To go to Mars one day with a hammer.

  • Yazeran (unregistered) in reply to Yazeran

    OK, it ate some of the stuff (sigh):

    start_table

    stuff

    start_table stuff form input field with autocomplete end_form

    end_table

    stuff

    script jquery code end_script

  • DP (unregistered)

    This was a technique from the early 2000s to provide what CSS appeared not to be able to deliver in the early days of table-less layout, columns of equal height. I discovered the technique and it leaked out our company on to Position is Everything thanks to an intern. It is not useless, but I will leave you scratching your heads as to how it did anything useful, my job still seems to be about counter-intuitive solutions to problems :)

  • PB (unregistered)

    At first, I thought you were kidding (I use RSS). All I can say is: THAT'S ONE HELL OF A NEAT HACK!

  • J Kirschner (unregistered)

    TRWTF:

    I was having trouble clicking "Archive" to access older posts on the front page.

    Why?

    The use of style="padding: 1rem 1rem 9999px; margin-bottom: -9999px;" in this post s blocking most of the "Archive" link (except for the edges).

  • Alex (unregistered) in reply to Dennis

    I think it's both. Most developers are bad at writing CSS and CSS is horrible. Before web components, it wasn't possible to encapsulate your CSS. If you wrote a selector .my-widget .amount and someone else just wrote .amount for a different part of the application, they clobbered you and you had to stop using the amount class on your element. The most robust way to solve this problem for large applications is to use long ugly class names like my-widget__amount for all CSS, but this is also horrible.

    If you're the only person writing the CSS for a project, then it's your fault if selector collision and bad cascading cause problems for you, but if you're on a large project, it's only a matter of time before a careless developer clobbers your widget. Who writes a language where everything is coupled with everything by default?

  • Paul Neumann (unregistered) in reply to Alex

    @J Kirschner:

    I was having trouble clicking "Archive" to access older posts on the front page.

    Could not replicate.

    @Alex:

    Before web components, it wasn't possible to encapsulate your CSS. If you wrote a selector .my-widget .amount and someone else just wrote .amount for a different part of the application, they clobbered you and you had to stop using the amount class on your element. The most robust way to solve this problem for large applications is to use long ugly class names like my-widget__amount for all CSS, but this is also horrible.

    No. What exactly do you think the 'C' in 'CSS' means? CSS has always supported contextual selectors. (source)[https://www.w3.org/TR/CSS1/#contextual-selectors]

  • Paul Neumann (unregistered) in reply to Paul Neumann

    @Paul Neumann > @J Kirschner:

    Could not replicate.

    Replicated -- "front page" was the key! (Never thought I would say those words in that order. At least it wasn't Front Page Express!)

  • isthisunique (unregistered)

    That's the kind of hack you would need in two cases:

    1. Browser compatibility. Nearly always MSIE6. Things like this would be to have a container stretch to the largest column and all sorts. For metrics each browser might use something slightly different, like with or without the border. This method might kind of displace something like overflow or another metric onto something else or get it to calculate differently. It's been so long ago though I forget. Might also be to get metrics to apply to a parent and so on or not apply.
    2. Where you would normally use tables for layout but can't because of the principle of it even if CSS doesn't actually support what you want to do and it needs to instead be done with ridiculous CSS and/or JS hacks.
  • Ulysses (unregistered)

    After the meme the other day, I half-expected a risque pic to go with this article. :-(

  • Iluvatar (unregistered)

    I use an RSS reader and it basically broke the whole article. This style got applied to the div that wraps the content from the site style="padding:9999px;margin-bottom:-9999px;" and so the whole article was hidden and 9999 pixes tall.

  • löchlein deluxe (unregistered) in reply to Yazeran

    input is self-closing and IE went quirks looking for a /input that never came?

    (Why could I guess that after fifteen seconds?)

  • Yazeran (unregistered) in reply to löchlein deluxe

    Nope, more sinister than that by far (although all my formatting etc went to hell in the forum so not obvious)

    The cause was a missing end table tag, that is for an element completely unrelated to the form element (or more specifically 2 or 3 parent levels up in the DOM)!

    I had started a main table. Inside that (along with other stuff) i had an inner table with the form elements for proper alignment etc.

    I had not ended the outer table by mistake and although it is a bad habit it is not illegal as the HTML spec allows for unterminated tags as long as they are unambiguous (that has been pointed out to be a WTF in the HTML spec by numerous people though)

    FF and Chrome behaved as they should, but IE had that strange quirk. Funny thing, the layout looked as it should, so i did not suspect an error in the table layout.... took me hours to hunt down. I first nailed it when I noticed that my page footer was misaligned (due to the missing end table tag)

    Yazeran

  • Chris (unregistered) in reply to Zenith

    The only reason people use tables for layout is they don't understand or care about the technologies they're using - display: table-cell has been a thing for years if you want to replicate table behaviour. HTML is a semantic markup language.

  • Herr Otto Flick (unregistered) in reply to Steve_The_Cynic
    Seriously, its requests started GET http://www.microsoft.com/ HTTP/0.9 ...

    No, it didn't, because HTTP 0.9 didn't make requests like that. The host only was added to requests at HTTP/1.1, and it is plainly idiotic to include the protocol to use inside the handshake of the protocol.

    It would have been "GET / HTTP/0.9"

  • (nodebb)

    I actually had a legitimate use of large padding and negative margins.

    Someone had written a card games extension for Firefox using its UI markup dialect. One of the things you were allowed to do was to drag the cards around the window, of course.

    However this created two issues. The obvious one was that dragging the card so that it overlapped the right edge of the window caused the container element to expand and then all the relative sizing followed suit.

    The less obvious one was that dragging a card (or more likely, a stack of cards) so that it overlapped the bottom of the window was terribly slow for no apparent reason.

    I discovered that adding large amounts of padding and negative margins fooled the layout into keeping the container element the same size so that neither of these effects triggered.

Leave a comment on “Well Padded”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article