7 ms·

<body background="animals.jpg"> <center> Exactly as I would do it if I were a 7yo. Speak what you will about the virtues of CSS and semantic markup, th

<body background="animals.jpg"> <center> Exactly as I would do it if I were a 7yo. Speak what you will about the virtues of CSS and semantic markup, these things get in the way of having fun. And can be learned later.

fintler 2y ago
I was really happy this still works. It's how I learned.
isoprophlex 2y ago
Totally agree with you. Not a front end dev myself, and I have multiple variations of "how do i center a div" in my search history, haha. With varying degrees of angry expletives added to the query.
- cronin101 2y ago
  Kids these days don’t know how easy they have it with flexbox!
  - WorldMaker 2y ago
    Who needs Flexbox's inscrutable 1-dimension language when you can use ASCII diagrams in CSS Grid for clever 2D things easily? CSS Grid Kids are truly spoiled.
    - jchw 2y ago
      Flexbox, grid. You're all forgetting the best way to build layouts: ol' reliable, <table>.
      - dpwm 2y ago
        As used on HN. It just works, even today.
        jchw 2y ago
        Although there is some degree of silliness to suggesting table layouts in 2024, it frankly really is not that bad. To me personally, the era of float: left and clearfix and 10 layers of wrapper divs was significantly more of a mess. "Oh look, I got my layout working on IE6! Oops, it's now broken in Opera..." Anyone remember using invalid CSS to write browser-dependent styles? How about using Microsoft's proprietary DirectX filters to make PNG transparency work? In the era of taking crummy PSDs full of graphics and chopping them up into images for an HTML template, these were the tools of the trade. Not that tables were perfectly standardized or anything, because I do remember Netscape and IE not totally agreeing on how to handle column widths, but they sure were, well, simpler.
        perilunar 2y ago
        Yeah, but HN uses tables in a really dumb way. Each comment is in a separate table with the width of the first column set to provide the correct amount of indenting. If the comments were properly nested you would just have a standard left margin and the tables would be completely unnecessary.
      - WorldMaker 2y ago
        It is almost a shame modern browsers no longer support all the fun layout patterns of ol' FRAMESET. There was a layout tool to cut your teeth on (possibly literally the way it was made out of browser chrome).
        jchw 2y ago
        Not that I necessarily advocate for frameset insanity, but you know what? That is a shame. My controversial (?) opinion is that browsers should literally never break anything that was once a part of the web platform unless there's simply no other choice. If the size of it is getting too big... first, stop adding more shit. (And then maybe, implement some old features in terms of some newer ones. Not really "web platform" but I am a huge proponent of what Ruffle is doing for the web.)
        vundercind 2y ago
        I’ll go a step farther: improved frames and datasource-aware tables and lists with a few very basic features found in almost any other UI kit out of the box would have given us 99% of the actually-beneficial stuff AJAX did, but better. The Web is a ton worse because we decided to build apps on it but never built the tools to do it right, even though the building blocks were right there.
        jchw 2y ago
        IMO the biggest problem with the way frames works is that it doesn't work well with navigation. I think unfortunately that this is just a design flaw with frames and it needed breaking changes to mitigate. I think I would've rather seen it go that direction, but it's hard to say. Without a crystal ball, we can't really compare the outcomes, and it's hard to imagine what would've happened in this hypothetical. I mean, I don't think in 2004 I would've been able to guess (or stomach) what the web was going to become 20 years down the road.
        AgentME 2y ago
        Framesets still work as far as I know, they're just no longer recommended for a few reasons. Browsers already try very hard to never ever break anything, at least not anything that's been commonly supported for years or has made it into a standard. The main places browsers have broken compatibility with old content are related to plugins like Flash and Silverlight, which were always controlled by a single vendor instead of being open standards.
  - freedomben 2y ago
    I know you're not entirely serious, but we really had it good and largely figured out with tables. It's probably because using tables for layouts was my native language, but I still sometimes have to mentally translate divs into a table in my mind to picture what is happening, and when default types are change (like block to inline, etc) it sometimes breaks my brain and I have to fallback to experimentation to get what I want. Slight disclaimer though: I'm a backend/infra guy so don't do frontend very often.
    - Archelaos 2y ago
      > I still sometimes have to mentally translate divs into a table in my mind to picture what is happening I still use tables (seriously).
    - recursive 2y ago
      Tables aren't even deprecated. IMO you're better off keeping the tables than transforming it into <div> soup. 20 years ago you'd hear it shouted from the rooftops: "Tables for layout are not semantic!". Guess what? <div>s are never semantic. Just use tables if it suits you.
      - pvorb 2y ago
        If you want to remove the semantics of table elements, you could set a role="presentation" attribute on all table-related tags. I'm wondering what HTML semantics enthusiasts will say about this. ;-)
        jraph 2y ago
        You almost got me. After all why not? So I had to go read stuff, and think more about it than I would have. So thanks for this. So: <table role="presentation"> is probably mostly fine, but not great, and not good practice. The ARIA spec [1] says: > 2. Notes on ARIA Use in HTML > 2.1 First Rule of ARIA Use > If you can use a native HTML element [HTML51] or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so. That's because simpler is easily more accessible. ARIA is last resort, when all else failed. ARIA is complex and not always well implemented, or implemented at all, and when it is implemented, interpretations can differ. Your content will be more accessible to more users / for more browsers if it doesn't rely on ARIA to be accessible. And more often than not, you can do more harm than good by using aria attributes, because it's easy to misuse them, which is worse than not using them at all. Now, ARIA is still very useful and should be used when it improves things over what HTML/CSS supports by itself, but table-based layouts have readily available HTML/CSS solutions. My opinion is that there's no good reason today to use tables for presentation. One of the reasons is always the same: separation of concerns. Structure your content, in the simplest possible way, and then style it. Structured content, with a structure that's as simple as possible, is more easily accessible. Add divs if really necessary for styling (which don't really change the structure, since they don't have meaning - keeping in mind that they are a compromise). It's funny how everyone seem convinced by the principle of separation of concerns, except for HTML/CSS/JS. You could use divs with display:table(-row|-cell) for the same result. Although CSS flex or CSS grid would let you achieve the same thing with a simpler structure and will allow you to have a responsive design. Fat tables with side menus are unwieldy on small screens and your <table><tr><td>-based structure will make it more difficult to offer a usable design to them. Table layout are also not great on text / terminal-based browsers. Letting the content flow from top to bottom will be way better. You have this for free if you don't use tables, because usually terminal browsers don't understand CSS. I would then reverse the question: why use tables when you can use display:table, CSS Flexbox or CSS Grid? What are the benefits? Especially when they are simpler as soon as you learned once how to do your favorite layout using these "new" things. I won't be convinced by any answer that sounds like "I don't really want to learn this stuff" because if we are trying to answer "What is the most correct way to do this", we should seek to use the better version, not the one we are familiar with. It seems to me "Why not use <table role=presentation>?" is a bit like "Why not use this carafe labeled 'this is a glass' as a glass?". Sure, why not, it will work, but if you have a glass now, even if you need to pour the water into the glass before you can drink it, isn't it better? (of course, maybe not the best analogy, I'm not good at analogies, but I hope it can help understand my perspective on <table role=presentation>). I also believe role="presentation" or role="none" is a code smell. It has legitimate uses (I guess), but the use better be clearly justified. [1] https://www.w3.org/TR/using-aria/ https://www.w3.org/TR/using-aria/
  - pseudocomposer 2y ago
    So that’s why some devs can somehow still manage to make flexbox layouts difficult :D
- vundercind 2y ago
  If nobody’s gonna see it to complain that I’m “doing it wrong” I’ll still just throw a center tag in from time to time. Look, it works and lets me move on to stuff that matters.
squidbeak 2y ago
On the contrary, CSS is where the fun starts.
- nevertoolate 2y ago
  Funny how?
  - squidbeak 2y ago
    Fun as in being a creative pleasure to use.
  - gjvc 2y ago
    funny != fun
- digging 2y ago
  I remember getting confused/disgusted looks at my first front-end job when I said I loved CSS and would be happy to work on styling... Later I learned that having 3 or more different ways to get an identical result is... time-consuming, at best. When they all might work slightly differently depending on several layers of context (or just not work), you realize CSS is ripe for massive pain points to spring up, and they can happen unexpectedly. I understood why everyone else hated CSS - under time pressure, it's just not worth dealing with 99.9% of the complexities for immeasurably small + abstract returns. Eventually, I determined that I both love and despise CSS in different aspects. It's complex enough to hold both attitudes. And I'm very, very satisfied that Tailwind came along and (nearly) perfected what Bootstrap et al were figuring out before it.
  - ern 2y ago
    I decided to throw in the towel on frontend dev when I was forced to translate wireframes from a UX designer into pixel-perfect CSS (on a safety and time-critical project where the site was going to be used by back-office staff only, you've got to love how consultancies find ways to make $$$). We had used Bootstrap and similar frameworks for years prior, but all the battling with different CSS layout techniques to render the UI on this project made me realize I was wasting my time, and the fact that the designer couldn't give developers working CSS made me wonder if the entire promise of separating design from functionality was a mirage.
im3w1l 2y ago
The issue with this is that it lacks the semantic - styling separation of proper modern HTML with CSS. Like compare that mess to the elegant semantic structure of a state of the art webpage like google.com <div class="gb_Ld"><div class="gb_Xc"><div class="gb_k gb_Fd gb_z" data-ogsr-fb="true" data-ogsr-alt="" id="gbwa"><div class="gb_f">
- kennyadam 2y ago
  Beautiful in it's simplicity. I also admire how much JavaScript modern websites can stuff down my throat without the mereist whiff of necessity.
- recursive 2y ago
  I imagine those class names are the vocalizations of some hapless user agent. > Open up wide! Here comes some 'content'! Quit complaining, you can handle it!
29athrowaway 2y ago
Back in the day it would have been animals.bmp, drawn on Paint
mmcgaha 2y ago
I wish it played a midi when I opened the page.
skgough 2y ago
I agree with you, but for shits and giggles, to modify this to be evangelist compliant, you could write this instead: <body style="background: url('animals.jpg')"> <div style="text-align: center"> Which isn't much more complicated, and makes it clearer what's going on. I wonder if there is a transpiler like Elm that could take a single file written in a simplified language and gave you an HTML5 compliant webpage? You could argue that all the XML-but-not-actually-XML crap in HTML (angle brackets, closing tags, escaping special characters with HTML entities...) is also an impediment to beginners.
- temac 2y ago
  What is the value of writing all of that, compared to the simpler approach? What will you want next in your quest of purity? Forbidding inline styles in the name of security, maybe? Disclaimer: I'm not found of web techs...
- Carrok 2y ago
  > Which isn't much more complicated, and makes it clearer what's going on. Hard disagree on both points.
- tannhaeuser 2y ago
  Are you serious? Embedding a language (CSS) into the string literals of another one (HTML) is of course much more complicated, and needlessly so. Also, there's nothing XML-but-not-actually about HTML. Both HTML and XML are derived from SGML.
  - skgough 2y ago
    The kid doesn't have to know that's it's CSS, and `style="background: url('animals.jpg')"` is more clear than just `background` because it explicitly states that this a networked resource that is being retrieved with the url() function. If you tried to set the `background` attribute to "blue" it wouldn't do anything, because you have to use the `bgcolor` attribute to color the background of the page. But the `background` property in CSS is a shorthand, so you can set it to a named X11 color, or a gradient, or an image file, and these all work. The `<center>` element spans the width of it's container, is only as tall as it's content, and only centers the content contained inside it horizontally, but this isn't immediately obvious just from looking at the element's name. Using `text-align: center` instead is a much more obvious way to describe what the `<center>` element is actually doing. Yes, this is more complicated, but it is more obvious, which, I think, is more useful when someone is learning a complex topic.
hanniabu 2y ago
TIL there's a center tag and background can be an inline property
- philo23 2y ago
  Wait until you find out how we used to change the colour of links!
XCSme 2y ago
I don't understand why they deprecated <center>, <b>, <i>, <u>, I still use them...

fintler 2y ago

I was really happy this still works. It's how I learned.

isoprophlex 2y ago

Totally agree with you. Not a front end dev myself, and I have multiple variations of "how do i center a div" in my search history, haha. With varying degrees of angry expletives added to the query.

cronin101 2y ago
Kids these days don’t know how easy they have it with flexbox!
- WorldMaker 2y ago
  Who needs Flexbox's inscrutable 1-dimension language when you can use ASCII diagrams in CSS Grid for clever 2D things easily? CSS Grid Kids are truly spoiled.
  - jchw 2y ago
    Flexbox, grid. You're all forgetting the best way to build layouts: ol' reliable, <table>.
    - dpwm 2y ago
      As used on HN. It just works, even today.
      - jchw 2y ago
        Although there is some degree of silliness to suggesting table layouts in 2024, it frankly really is not that bad. To me personally, the era of float: left and clearfix and 10 layers of wrapper divs was significantly more of a mess. "Oh look, I got my layout working on IE6! Oops, it's now broken in Opera..." Anyone remember using invalid CSS to write browser-dependent styles? How about using Microsoft's proprietary DirectX filters to make PNG transparency work? In the era of taking crummy PSDs full of graphics and chopping them up into images for an HTML template, these were the tools of the trade. Not that tables were perfectly standardized or anything, because I do remember Netscape and IE not totally agreeing on how to handle column widths, but they sure were, well, simpler.
      - perilunar 2y ago
        Yeah, but HN uses tables in a really dumb way. Each comment is in a separate table with the width of the first column set to provide the correct amount of indenting. If the comments were properly nested you would just have a standard left margin and the tables would be completely unnecessary.
    - WorldMaker 2y ago
      It is almost a shame modern browsers no longer support all the fun layout patterns of ol' FRAMESET. There was a layout tool to cut your teeth on (possibly literally the way it was made out of browser chrome).
      - jchw 2y ago
        Not that I necessarily advocate for frameset insanity, but you know what? That is a shame. My controversial (?) opinion is that browsers should literally never break anything that was once a part of the web platform unless there's simply no other choice. If the size of it is getting too big... first, stop adding more shit. (And then maybe, implement some old features in terms of some newer ones. Not really "web platform" but I am a huge proponent of what Ruffle is doing for the web.)
        vundercind 2y ago
        I’ll go a step farther: improved frames and datasource-aware tables and lists with a few very basic features found in almost any other UI kit out of the box would have given us 99% of the actually-beneficial stuff AJAX did, but better. The Web is a ton worse because we decided to build apps on it but never built the tools to do it right, even though the building blocks were right there.
        jchw 2y ago
        IMO the biggest problem with the way frames works is that it doesn't work well with navigation. I think unfortunately that this is just a design flaw with frames and it needed breaking changes to mitigate. I think I would've rather seen it go that direction, but it's hard to say. Without a crystal ball, we can't really compare the outcomes, and it's hard to imagine what would've happened in this hypothetical. I mean, I don't think in 2004 I would've been able to guess (or stomach) what the web was going to become 20 years down the road.
        AgentME 2y ago
        Framesets still work as far as I know, they're just no longer recommended for a few reasons. Browsers already try very hard to never ever break anything, at least not anything that's been commonly supported for years or has made it into a standard. The main places browsers have broken compatibility with old content are related to plugins like Flash and Silverlight, which were always controlled by a single vendor instead of being open standards.
- freedomben 2y ago
  I know you're not entirely serious, but we really had it good and largely figured out with tables. It's probably because using tables for layouts was my native language, but I still sometimes have to mentally translate divs into a table in my mind to picture what is happening, and when default types are change (like block to inline, etc) it sometimes breaks my brain and I have to fallback to experimentation to get what I want. Slight disclaimer though: I'm a backend/infra guy so don't do frontend very often.
  - Archelaos 2y ago
    > I still sometimes have to mentally translate divs into a table in my mind to picture what is happening I still use tables (seriously).
  - recursive 2y ago
    Tables aren't even deprecated. IMO you're better off keeping the tables than transforming it into <div> soup. 20 years ago you'd hear it shouted from the rooftops: "Tables for layout are not semantic!". Guess what? <div>s are never semantic. Just use tables if it suits you.
    - pvorb 2y ago
      If you want to remove the semantics of table elements, you could set a role="presentation" attribute on all table-related tags. I'm wondering what HTML semantics enthusiasts will say about this. ;-)
      - jraph 2y ago
        You almost got me. After all why not? So I had to go read stuff, and think more about it than I would have. So thanks for this. So: <table role="presentation"> is probably mostly fine, but not great, and not good practice. The ARIA spec [1] says: > 2. Notes on ARIA Use in HTML > 2.1 First Rule of ARIA Use > If you can use a native HTML element [HTML51] or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so. That's because simpler is easily more accessible. ARIA is last resort, when all else failed. ARIA is complex and not always well implemented, or implemented at all, and when it is implemented, interpretations can differ. Your content will be more accessible to more users / for more browsers if it doesn't rely on ARIA to be accessible. And more often than not, you can do more harm than good by using aria attributes, because it's easy to misuse them, which is worse than not using them at all. Now, ARIA is still very useful and should be used when it improves things over what HTML/CSS supports by itself, but table-based layouts have readily available HTML/CSS solutions. My opinion is that there's no good reason today to use tables for presentation. One of the reasons is always the same: separation of concerns. Structure your content, in the simplest possible way, and then style it. Structured content, with a structure that's as simple as possible, is more easily accessible. Add divs if really necessary for styling (which don't really change the structure, since they don't have meaning - keeping in mind that they are a compromise). It's funny how everyone seem convinced by the principle of separation of concerns, except for HTML/CSS/JS. You could use divs with display:table(-row|-cell) for the same result. Although CSS flex or CSS grid would let you achieve the same thing with a simpler structure and will allow you to have a responsive design. Fat tables with side menus are unwieldy on small screens and your <table><tr><td>-based structure will make it more difficult to offer a usable design to them. Table layout are also not great on text / terminal-based browsers. Letting the content flow from top to bottom will be way better. You have this for free if you don't use tables, because usually terminal browsers don't understand CSS. I would then reverse the question: why use tables when you can use display:table, CSS Flexbox or CSS Grid? What are the benefits? Especially when they are simpler as soon as you learned once how to do your favorite layout using these "new" things. I won't be convinced by any answer that sounds like "I don't really want to learn this stuff" because if we are trying to answer "What is the most correct way to do this", we should seek to use the better version, not the one we are familiar with. It seems to me "Why not use <table role=presentation>?" is a bit like "Why not use this carafe labeled 'this is a glass' as a glass?". Sure, why not, it will work, but if you have a glass now, even if you need to pour the water into the glass before you can drink it, isn't it better? (of course, maybe not the best analogy, I'm not good at analogies, but I hope it can help understand my perspective on <table role=presentation>). I also believe role="presentation" or role="none" is a code smell. It has legitimate uses (I guess), but the use better be clearly justified. [1] https://www.w3.org/TR/using-aria/ https://www.w3.org/TR/using-aria/
- pseudocomposer 2y ago
  So that’s why some devs can somehow still manage to make flexbox layouts difficult :D
vundercind 2y ago
If nobody’s gonna see it to complain that I’m “doing it wrong” I’ll still just throw a center tag in from time to time. Look, it works and lets me move on to stuff that matters.

squidbeak 2y ago

On the contrary, CSS is where the fun starts.

nevertoolate 2y ago
Funny how?
- squidbeak 2y ago
  Fun as in being a creative pleasure to use.
- gjvc 2y ago
  funny != fun
digging 2y ago
I remember getting confused/disgusted looks at my first front-end job when I said I loved CSS and would be happy to work on styling... Later I learned that having 3 or more different ways to get an identical result is... time-consuming, at best. When they all might work slightly differently depending on several layers of context (or just not work), you realize CSS is ripe for massive pain points to spring up, and they can happen unexpectedly. I understood why everyone else hated CSS - under time pressure, it's just not worth dealing with 99.9% of the complexities for immeasurably small + abstract returns. Eventually, I determined that I both love and despise CSS in different aspects. It's complex enough to hold both attitudes. And I'm very, very satisfied that Tailwind came along and (nearly) perfected what Bootstrap et al were figuring out before it.
- ern 2y ago
  I decided to throw in the towel on frontend dev when I was forced to translate wireframes from a UX designer into pixel-perfect CSS (on a safety and time-critical project where the site was going to be used by back-office staff only, you've got to love how consultancies find ways to make $$$). We had used Bootstrap and similar frameworks for years prior, but all the battling with different CSS layout techniques to render the UI on this project made me realize I was wasting my time, and the fact that the designer couldn't give developers working CSS made me wonder if the entire promise of separating design from functionality was a mirage.

im3w1l 2y ago

The issue with this is that it lacks the semantic - styling separation of proper modern HTML with CSS. Like compare that mess to the elegant semantic structure of a state of the art webpage like google.com <div class="gb_Ld"><div class="gb_Xc"><div class="gb_k gb_Fd gb_z" data-ogsr-fb="true" data-ogsr-alt="" id="gbwa"><div class="gb_f">

kennyadam 2y ago
Beautiful in it's simplicity. I also admire how much JavaScript modern websites can stuff down my throat without the mereist whiff of necessity.
recursive 2y ago
I imagine those class names are the vocalizations of some hapless user agent. > Open up wide! Here comes some 'content'! Quit complaining, you can handle it!

29athrowaway 2y ago

Back in the day it would have been animals.bmp, drawn on Paint

mmcgaha 2y ago

I wish it played a midi when I opened the page.

skgough 2y ago

I agree with you, but for shits and giggles, to modify this to be evangelist compliant, you could write this instead: <body style="background: url('animals.jpg')"> <div style="text-align: center"> Which isn't much more complicated, and makes it clearer what's going on. I wonder if there is a transpiler like Elm that could take a single file written in a simplified language and gave you an HTML5 compliant webpage? You could argue that all the XML-but-not-actually-XML crap in HTML (angle brackets, closing tags, escaping special characters with HTML entities...) is also an impediment to beginners.

temac 2y ago
What is the value of writing all of that, compared to the simpler approach? What will you want next in your quest of purity? Forbidding inline styles in the name of security, maybe? Disclaimer: I'm not found of web techs...
Carrok 2y ago
> Which isn't much more complicated, and makes it clearer what's going on. Hard disagree on both points.
tannhaeuser 2y ago
Are you serious? Embedding a language (CSS) into the string literals of another one (HTML) is of course much more complicated, and needlessly so. Also, there's nothing XML-but-not-actually about HTML. Both HTML and XML are derived from SGML.
- skgough 2y ago
  The kid doesn't have to know that's it's CSS, and `style="background: url('animals.jpg')"` is more clear than just `background` because it explicitly states that this a networked resource that is being retrieved with the url() function. If you tried to set the `background` attribute to "blue" it wouldn't do anything, because you have to use the `bgcolor` attribute to color the background of the page. But the `background` property in CSS is a shorthand, so you can set it to a named X11 color, or a gradient, or an image file, and these all work. The `<center>` element spans the width of it's container, is only as tall as it's content, and only centers the content contained inside it horizontally, but this isn't immediately obvious just from looking at the element's name. Using `text-align: center` instead is a much more obvious way to describe what the `<center>` element is actually doing. Yes, this is more complicated, but it is more obvious, which, I think, is more useful when someone is learning a complex topic.

hanniabu 2y ago

TIL there's a center tag and background can be an inline property

philo23 2y ago
Wait until you find out how we used to change the colour of links!

XCSme 2y ago

I don't understand why they deprecated <center>, <b>, <i>, <u>, I still use them...