Not a bad looking website. I like it better than most of that responsive CSS/JS bloated nightmares out there. I wish more websites were faster loading like this one.
The web is a lot like music and movies. There's the mainstream pop stuff and then there's the other 99.99% which is easy to forget unless you are intentional about engaging it
Wow, great stuff. Tell her she did a fantastic job!
---
By necessity, kids these days don't even need to learn what a file is. Videos are "on youtube". Documents are stored "in ms word".
The median developer even seems to have a very shallow understanding of how a computer actually works. And why would they, if they can just glue some Lambdas together to earn a buck?
---
Praise those that look a bit deeper and really want to know how a thing works, how you can create something truly original with a tool, instead of simply using it along the happy path.
Files are an abstraction that was very useful in the last several decades, but that just isn't as relevant in the current world. Those videos and documents you mentioned are likely managed via object storage in a distributed database, itself possibly using block storage directly, with no actual "file" in an old-school filesystem anywhere in sight.
I still personally cling to files personally, but I have no real reason to believe that they are a fundamental abstraction that is more true than cloud lambdas.
Sure, call them byte streams or blobs, that's fine too. I'm not disagreeing, but the point I wanted to make was that recently, people seem to have gotten the idea that their objects are semi-magical things locked into some app or some cloud service. Which is fine by the SaaS providers, or course. But it doesn't really foster understanding of the world around you.
Like kids thinking corn comes from the corn factory.
I think that part of the reason for my thinking is that I've recently been playing around with USD (Universal Scene Description). It is currently mostly based on files, but I find the underlying representation - of layers of atomic properties being composed together in a massive tree - to be very elegant, and it can be managed in a database without any files or blobs anywhere.
As another example: in the early web, behind every url was a file (with an actual file extension), but then we abstracted them into resources, and I feel that this coincided with an evolution of the field.
The concept of a file or blob will probably still be useful in some capacity for decades to come, but I wouldn't want it to hinder us from realizing better abstractions.
Also, replying to myself, have you ever had a job? At a place? Where the primary function isn't coding?
Files are everywhere. They are every-thing. Except now, thanks to the disaster that is SharePoint, nobody has a fucking idea where they are any more. Because they've been abstracted away by some genius on the Teams team.
So nobody can find what they were just working on. Or they have no idea if the thing they find is the right version. It's a total shambles.
A hierarchical file system was boring, but it worked. And it still does.
Disclosure: I'm Johnny.Decimal and my business depends on files still being a thing.
I don't think the comment was about the "file system", more like about the "humans" that dump every file they have to whichever folder they find available, and in the end of the day/week/month/year nobody knows where that file is.
And then the person leaves the company/org and this file will float in space (SharePoint) forever, never to be recalled again, never to be read again, alone, in a cold world (computer room).
>And then the person leaves the company/org and this file will float in space (SharePoint) forever, never to be recalled again, never to be read again, alone, in a cold world (computer room).
It will likely eventually be used as training data for an LLM and get an afterlife. Resistance is futile.
Abstractions will start coming and they don't stop coming.
People in the late 90s/early 2000s probably complained about people like me who learned about HTML but only had a shallow understanding of how laying out a GUI and text rendering works. Which why would we, when we could just glue some HTML together to make a Chrono Trigger fan site?
Abstractions are fine. Everything we do is a dozen layers of abstraction on top of the metal anyway.
It just happens that people who know how the bits actually move underneath the abstractions tend to be better at solving problems related to those abstractions, than those who don't.
There are problems where understanding one level below the abstractions indeed leads to better solutions. However, I would argue that for a large set of problems, this is not the case. I think being aware of the abstraction (at multiple levels) would lead you to choose the right abstraction level for solving the problem. Of course, apart from school assignments, these abstraction levels are never given with a certain problem, so the more you know, the better you'll be able to see it.
To be honest, being able to think about things in multiple levels of abstraction is an advantage no matter what level you are (writing assembly or writing react)
It's because abstractions always leak. You are never completely insulated from the levels above or below you, nor sideways from the other components you interact with.
> By necessity, kids these days don't even need to learn what a file is. Videos are "on youtube". Documents are stored "in ms word".
Coincidentally, I've been thinking about that recently. My conclusion was that this couldn't be true, as it didn't make any sense.
I mean, even when using a phone or a tablet, the pictures they take or the videos they make end up somewhere. And that somewhere must be found, to be able to upload their take to the app or the website of their choice, or to be edited in an app before uploading.
So by extension, as that medium is "somewhere" on their device, they must be able, intuitively, to deduce the concept of a file?
And the take on the median developer frightens me even more. Somehow it feels akin to giving a soldier a firearm and letting him off to go and fight. Surely that's going to end in disaster?
Praise those that look a bit deeper and really want to know how a thing works
Are people really that hermetic to understanding how the items and tool they use actually work?
> Are people really that hermetic to understanding how the items and tool they use actually work?
From what I've seen in some of our new recruits, yes. And those are technically educated people.
In general public, I've noticed that if stuff is working well, people don't tend to take a deep look into how it works.
I guess that's how different minds work right ? For example a curious mind wants to know how a thing behaves and how it works etc, whereas a visual mind would look for how it looks.
> From what I've seen in some of our new recruits, yes. And those are technically educated people.
That's really the part I can't wrap my head around.. The first thing I tend to do when I encounter something new -a new phone, a new bike, new tools, etc- is to understand how it works, to see what I can do with it, what its limits are, and most importantly, if I can bend those limits to suit my needs..
Accepting something at face value is really not an option. Partly because, more often than not, that would also mean settling for mediocrity as "quality" seems to be a secondary target nowadays. Thing will not work how you want, things will break and will need to be repaired, some artificial constraints might be need to be circumvented. And on the other hand, there is always something interesting that can be learned by being curious.
We are not all wired the same. But if the "technically educated" people are no longer "technical" than at least I shouldn't fear about future employability.
I'm 22, and most of my "not tech savvy" peers and anyone I've met under 20 have zero concept of how most tech actually works.
The pictures taken on your phone are not "stored somewhere", they are stored "in Google" or "in iCloud" or "in the photos app". Documents are similarily "in Google" or "in Word". There's no intuitive relation between photos and documents being the same thing on the filesystem, nor is there a concept of the filesystem at all. Generally, things jusr "work" (until they don't) and nobody asks any questions.
Now, I would like to clarify that this isn't a "darn kids these days" tangent, in fact, it's the opposite: darn adults these days won't teach their kids how to use the computer!
I would expect/really hope that when my generation starts having kids, computer literacy will start going up again. But for now, it's totally in the drain.
With respect to developers... Most of them know a lot less than they should. This is also an education/incentives problem.
> darn adults these days won't teach their kids how to use the computer!
I would bet most of the greyhaired people on here as well as those who were born at the time of the personal computer revolution didn't have parents who were proficient in a technology that was literally just made available to consumers yet those kids learn to use a computer on their own at a time where there was no internet available to check.
Why do kids suddenly need to be taught personally when they are the first generation to have the greatest amount of resources to learn how to use a computer available for free, in multiple teaching styles, multiple formats, at different levels of detail?
I feel this is related to the helicopter parent mentality that replaced parenting styles from earlier periods
Still an abstraction if you don't understand how each of the parts of the computer work. And that level of detail goes all the way down to the actual implementation of the logic gates. One who could also include how your monitor display work and the keyboard.
For the childrens' sake I hope so. Parental accumulated tech debt from not keeping up with developments is stressful to deal with!
Looking around though I think it's going to depend on what industry parents are in. There's still a lot of cluelessness around even among people who have grown up in an era of computers.
Me too. First framesets, handcrafted. Then Dreamweaver and Photoshop slicing (forgot what this monstrosity was called). Via PHP portals, CMSes (Drupal!).
Decades later I'm tuning YAML files that trigger ansible runs on CIs that compile docker images in which we embed hundreds of npm packages that get transpiled from typescript. Which gets released to cloud serverless edge thingies that store stuff in a database and on some block storage. All to serve a page that's similar in information and feature-density to what I handcrafted back in 1999 in notepad.exe. Yet hundreds of times the size, thousands of times more complex and much, much slower to run and load.
(I'm not exaggerating, but I did pick the worst example. Most of my work is building backend stuff in rust, simple static sites in hugo or jekyll and occasionally sime JS or TS to spice these static sites up with client-side features)
> All to serve a page that's similar in information and feature-density to what I handcrafted back in 1999 in notepad.exe. Yet hundreds of times the size, thousands of times more complex and much, much slower to run and load.
Seriously, I think about this quite often. I recently found some old code that I wrote in the early 00s and it was wonderfully simple, and aside from a few visual trends that have changed, it looks pretty damn good. Straightforward layout, good information density, and very clean. The best part is the code is vastly simpler than anything I've seen/built in the last couple of decades (especially since CSS, packers/transpilers, etc started arriving). I grant that there are some good reasons to introduce CSS and divs and all that, and that once we've done that it is inconsistent to have some things done in html and others in css, but sometimes philosophically better isn't better in practice. Sometimes.
Oh yea in hindsight it would have been better to just stay in the editor and write HTML - but I was a kid and Dreamweaver was pretty easy to use.
Although I did hit its limits pretty soon and tried to mess around with the code.
There was something special about being a kid and pushing an update to your site via SFTP on the sidebar in Dreamweaver, then calling or hitting up your friends on AIM/MSN messenger to check it out.
Love it! Well done Naya, the information on the page is excellent!
By any chance was this made on a tablet? I see it mentions “tablet… make a website”. Perhaps if children grow up having accessing to tablets over computers, making websites on them won’t seem as foreign compared to a computer.
Mine prefers tablet mostly, but every now and then she will ask to use the PC for some Roblox thing that only works on PC and I give her no end of grief for that :-)
> A dog that my aunt has uses a button to tell her if she's hungry or tired.
I‘m intrigued! We also have two dogs and the more I know them, the more I‘m fascinated by their ability to tell us exactly what they feel. I didn’t know they can learn to use buttons to do this.
Holy fuck that's incredibly interesting! The dog knows it's own name, composes multi word sentences... that's consciousness and volition on par with humans.
This looks like a solid first step. I am also teaching my 8yo a bit of coding, starting with HTML but he complains about a lot of typing, he is slow in typing so it becomes painful for him.
We have her setup with iMessage (with screen time to limit who she's talking with), so she chats with the family pretty often. I think that may have helped with typing speed.
Great work! Back in the day (when I was about 9 years old) I did something similar but for my poetry and dinosaur related interests, and that kicked off my still ongoing multi-decade journey in web development.
This is great, it looks nice, works exactly as one would expect it to (very links, no clickbait), cats (the internet was made for cats after all) and loads instantly.
Width and height must be specified without units (although looks like browsers accept it, probably by ignoring the unit). IMG tags are self-closing, so you can omit </img>
The dog picture has wrong aspect ratio. The dog is squeezed! It should be 620 × 349 or, if 500 width or 400 height is needed, there's a good mathematical task to calculate the size of the other side.
<br/>
No need for / in HTML.
unicorn.html
unicorncopy.html
Page for cats is named unicorn.html! and for computers it's unicorncopy!!!
PS I don't like that CloudFlare Pages strips .html. Too magical.
When the Trump assassination attempt happened last week and every single post on here was still about computers that's when I realized this place is different
Isn’t that kind of on purpose though? I think you will get flagged if you just post general news articles. It looks like political posts are only accepted if they have some relation to technology.
It’s not a secret HN is not a site for general news. That’s the first item in the guidelines:
> What to Submit
> (…)
> Off-Topic: Most stories about politics, or crime, or sports, or celebrities, unless they're evidence of some interesting new phenomenon. Videos of pratfalls or disasters, or cute animal pictures. If they'd cover it on TV news, it's probably off-topic.
It is because you’d hear about that anywhere and everywhere else that it doesn’t belong here. Would you complain that a forum about cooking or sharing wallpapers didn’t cover the news as well?
Though it was submitted and discussed anyway, which always happens. That can be confirmed with your own keywords.
I’m glad that my attempts at removing USA politics from my content feeds have been so successful that this is the first time I hear about the Trump assassination attempt.
Don’t 7 year olds deserve to learn how to improve too? The comment doesn’t appear to be done aggressively or in bad faith, so what’s the issue? Presumably it will be the parent who’ll read the comment, and they can pass it on or not depending on what they think the kid would prefer and/or would let them grow.
Ironically, I find the most HN comments of all to be the ones who complain about something being too HN.
Which is not to say your comment wasn’t humorous, but let’s not be too quick to cast stones.
Respectfully, if you see the comment as critique, that’s on you. It could just as easily be described as “unsolicited advice” or “unsolicited tips”.
The communicator does have responsibility on how their message comes across, thought not all of it. It’s on the receiver to also make an effort to understand what was meant and not take unnecessary offence. The comment reads pretty much neutral, apart from a post scriptum which is explicitly about the author’s preference. It’s up to you to inject the writer’s feelings as either “this code sucks, here’s how you do it” or “congratulations on making something cool, here are a few suggestions”.
My experience is that life is much better if you take the latter approach. Default to empathy.
Consider listening to “This is Water” from David From Wallace.
Let's agree to disagree. I most certainly didn't take offense. I just disagreed (and continue to disagree) with the (your) comment that I responded to. I'm sure the parent of the 7 year old in question was aware of the shortcomings of the code. The fact that a (presumed) grown-up read the post/thread and their reaction was to provide a code review is odd to me and more than a little hackernews-ish which the poster you responded to poked fun at and which you seemed to take exception to.
The dog page should be banned in the EU because it doesn’t disclose that the picture has been digitally altered, promoting impossible beauty standards for pets.
It always felt apt to offer a few words of praise for the things that are good, or to establish common ground in code review before offering constructive critique.
Wouldn’t call it a must, but makes putting one’s own ego aside when receiving critique that much easier and lets me focus on improvement, I try to do that for others as well now!
I personally prefer having the /> even though it's not necessary, so that I can tell at-a-glance whether a tag is self-closing or not. It doesn't hurt, does it?
(plus I'm just used to it because the book I learned HTML from was confident that XHTML was the future)
I've always been completely baffled by the rejection of xhtml. It gave a way to extend html with new elements and a simple, powerful client side templating language with xslt. The "reason" for which I remember it being rejected was that allegedly web devs couldn't wrap their heads around closing tags and explicit attribute values, which seems crazy to me. Then a few years later typescript took off (which is way more complicated) and react gave a pretend way to write xml except now you need a compiler/build pipeline, and everyone loved it.
xhtml still works in modern browsers btw. It's still probably the easiest way to do page templates. XSLT shows its age without the ability to modify the page after load (unless you run it via javascript), but we could've just added that and it'd be almost perfect.
I reckon it does hurt, beyond the negligible cost of the extra transferred and parsed bytes: it teaches something that’s simply incorrect, and doesn’t do what people often think it does.
① The trailing slash doesn’t make a tag self-closing. All it does is get ignored, emitting a parse error (which in common compiler terms is just a warning) if you use it on a non-void tag.
You can’t use <div/>. You can’t use <custom-tag/>. The only tags you’re allowed to use the trailing slash on are the defined void tags like <img> and <br>.
It’s not “not necessary”, it’s “completely useless, by definition”.
I’ve seen people presume they can close tags this way. JSX probably helps cause this, because you can there. But because self-closing tags aren’t a thing in HTML syntax, I think it’s harmful to use the spelling at all in HTML syntax.
② I wouldn’t mind so much if people used it consistently, and I wouldn’t mind at all if it was being used to support both HTML and XML syntax, but if you see sites that use trailing slashes on void tags in their head, practically every time there will be at least one tag that isn’t using it:
<link … />
<meta … />
<link …>
<link … />
③ I also dislike it because it’s fairly common for syntax highlighters or other casual parsers to get it wrong. Most commonly, I’ve seen tools misinterpret an unquoted last attribute, treating <a href=/example/> as <a href="/example" /> rather than <a href="/example/"> before. (Same with the likes of <img src=/example/>, but anchor hrefs are more commonly going to look like that.)
IIRC, that's not necessarily true, some parsers "upgrade" html to xhtml and then process the xhtml since its more regular. html in general is a mess due to backwards compatibility requirements so trying to follow these kind of definitions imo is kinda pointless. you can optimize for size if you want but the decrease from these kind of optimizations with modern speeds is rather minimal
> some parsers "upgrade" html to xhtml and then process the xhtml since its more regular.
I have never heard of anything even vaguely matching your description, and it would be wildly wrong. HTML parsing is exhaustively defined, and the only way of correctly parsing HTML is to use the defined HTML parser.
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.
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.
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.
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.
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.
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).
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.)
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.
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.
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.
Yeah I don't really count Flash or Silverlight as parts of the "web platform" personally, though I will re-iterate that I am still very pleased with the Ruffle project nonetheless. From a practical standpoint, Ruffle does a lot of good even if Flash always was proprietary and not really a part of what the web platform really was at its core.
I hope <frameset> continues to work into the future. I'm sure eventually it will wind up on the chopping block, and personally I think that'll suck.
> at least not anything that's been commonly supported for years or has made it into a standard.
It's more: has made it into a standard and was commonly supported.
Sadly, the browsers aren't trying hard enough not to break anything. They are trying hard not to break anything standard, but the problem with that is that the standards can change, or that some things can be claimed to never have been standards all along. A bunch of IE/Netscape things have broken already such as BLINK and MARQUEE, despite being common enough to "feel" standard even though yes they were never actually standards. Also, as we've seen with the MathML battle in recent years, even standards aren't guaranteed to be kept in browsers if not "commonly supported".
The MDN deprecation warning on FRAMESET:
> Deprecated: This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes.
The browser support table says that every browser still currently supports FRAMESET with simple COLS and ROWS, but as I recall FRAMESET used to also support more complicated layout tools. My brain recalls it as being very similar to TABLE layout at one point in time that you could also have (limited) COLSPAN and ROWSPAN options. Such things may also have been IE/Netscape era "non-standards". If I had examples, they are probably lost to time. Similarly, with nearly no way to easily search in today's indexes for things specifically from the 1990s I can't think of a good way to find old examples either. It's also possibly my memory is just failing me on this and the crazy things I recall doing with framesets were just table layouts after all and maybe iframes, but I do recall doing some crazy things in the 90s that certainly aren't "standard" today and I know wouldn't work in today's framesets.
I can't agree with this, because it creates a "barrier of entry" for people building new browsers. Old things should deprecate when new things do them better, and deprecated things should phase out.
Otherwise, we're stuck with Chrome Forever. I'd rather not.
Disagree. Deprecating things like <frameset> will not make it easier to build new browsers. Shadow DOM and WebComponents are significantly more complicated for browsers to implement than any old "deprecated" technologies. If you don't want Chrome forever, what you want is not removing old technologies, it's preventing more new technologies from becoming a part of the web platform.
We'll get better at building software. Even with huge engineering teams, we can only build the browsers that we have today due to improvements in large-scale software engineering.
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.
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.
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. ;-)
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.
This seems to fall under the unconvincing "I don't really want to learn this stuff". This seems to be the only reason people are tables for layouts today.
People doing this are probably not interested in the rhetorical efficacy of the justification. In other words it probably doesn't matter whether you find it convincing.
one is a table the other pretends to be a table. There has to be a lot wrong for the table to forget what it is. try disabling style.
css also gets complicated much faster than html. I like to offload complexity to less complicated areas.
a practical example: i look at each row and set rowspan for duplicate values. a series of rows might have week 22 as their first cell and multiple with monday as their second.
How about "one pretends to be a layout, and the other is a layout"?
I don't understand well what you are saying, but:
> a practical example: i look at each row and set rowspan for duplicate values. a series of rows might have week 22 as their first cell and multiple with monday as their second.
This seems to be a case of using a table as a table, which is fine. You should use tables when you are trying to represent tabular data.
Counterpoint: no semantics is better than wrong semantics. If a screenreader thinks your layout is a (data)table, it makes your visually impaired users sad.
If you use tables for what they were intended for or you have no problem with them, keep on truckin. But they sucked when they were the only way to do things.
I lost out on a front end job about 15 years ago because I marked up a business’s open and close hours in a table during a coding test. I was told that my skills were clearly out of date.
Table are used when tables are needed. Excel like overviews. No reason to not use tables.
For site layouts (multiple columns etc) you would better use divs in a flexbox or something.
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.
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.
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.
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?
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.
545 comments
[ 512 ms ] story [ 7970 ms ] threadJust type in some word like "cat" and click on the links. They are kinda all like that.
This tends towards cleaner sites and really it's the only stable fix for SEO spam
---
By necessity, kids these days don't even need to learn what a file is. Videos are "on youtube". Documents are stored "in ms word".
The median developer even seems to have a very shallow understanding of how a computer actually works. And why would they, if they can just glue some Lambdas together to earn a buck?
---
Praise those that look a bit deeper and really want to know how a thing works, how you can create something truly original with a tool, instead of simply using it along the happy path.
I still personally cling to files personally, but I have no real reason to believe that they are a fundamental abstraction that is more true than cloud lambdas.
Like kids thinking corn comes from the corn factory.
As another example: in the early web, behind every url was a file (with an actual file extension), but then we abstracted them into resources, and I feel that this coincided with an evolution of the field.
The concept of a file or blob will probably still be useful in some capacity for decades to come, but I wouldn't want it to hinder us from realizing better abstractions.
Files have a way to go yet.
Files are everywhere. They are every-thing. Except now, thanks to the disaster that is SharePoint, nobody has a fucking idea where they are any more. Because they've been abstracted away by some genius on the Teams team.
So nobody can find what they were just working on. Or they have no idea if the thing they find is the right version. It's a total shambles.
A hierarchical file system was boring, but it worked. And it still does.
Disclosure: I'm Johnny.Decimal and my business depends on files still being a thing.
This very site is being served from a file system.
And then the person leaves the company/org and this file will float in space (SharePoint) forever, never to be recalled again, never to be read again, alone, in a cold world (computer room).
Speaking about SNL sketch.. it reminded me James Cameron's reaction on the Papyrus sketch --> https://www.youtube.com/watch?v=wm1-k__LF40
It will likely eventually be used as training data for an LLM and get an afterlife. Resistance is futile.
Edit a video? Built in app, or your social media app is already loaded with that and you can save state instead of posting
Reverse a video? There’s an app for that which just goes back into your Photos app to let you tried that content
and so on
people dont need to have that mental model until something breaks
You want to produce a video of any quality at all? You're using files.
and you can edit in high quality on an iphone, higher than what’s necessary to view on an iphone
so, two premises that arent substantiated
They might exist. I don’t watch TT, I’m happy to be wrong.
But MKBHD, Justine, Mr. Beast, CGP Grey — you name ‘em, they use files to edit a production.
Someone that doesn’t watch tiktok thinks a millions views is a lot there
Stick with YouTube your worldview isn’t relevant this decade
People in the late 90s/early 2000s probably complained about people like me who learned about HTML but only had a shallow understanding of how laying out a GUI and text rendering works. Which why would we, when we could just glue some HTML together to make a Chrono Trigger fan site?
It just happens that people who know how the bits actually move underneath the abstractions tend to be better at solving problems related to those abstractions, than those who don't.
Coincidentally, I've been thinking about that recently. My conclusion was that this couldn't be true, as it didn't make any sense.
I mean, even when using a phone or a tablet, the pictures they take or the videos they make end up somewhere. And that somewhere must be found, to be able to upload their take to the app or the website of their choice, or to be edited in an app before uploading.
So by extension, as that medium is "somewhere" on their device, they must be able, intuitively, to deduce the concept of a file?
And the take on the median developer frightens me even more. Somehow it feels akin to giving a soldier a firearm and letting him off to go and fight. Surely that's going to end in disaster?
Are people really that hermetic to understanding how the items and tool they use actually work?From what I've seen in some of our new recruits, yes. And those are technically educated people.
In general public, I've noticed that if stuff is working well, people don't tend to take a deep look into how it works.
I guess that's how different minds work right ? For example a curious mind wants to know how a thing behaves and how it works etc, whereas a visual mind would look for how it looks.
That's really the part I can't wrap my head around.. The first thing I tend to do when I encounter something new -a new phone, a new bike, new tools, etc- is to understand how it works, to see what I can do with it, what its limits are, and most importantly, if I can bend those limits to suit my needs..
Accepting something at face value is really not an option. Partly because, more often than not, that would also mean settling for mediocrity as "quality" seems to be a secondary target nowadays. Thing will not work how you want, things will break and will need to be repaired, some artificial constraints might be need to be circumvented. And on the other hand, there is always something interesting that can be learned by being curious.
We are not all wired the same. But if the "technically educated" people are no longer "technical" than at least I shouldn't fear about future employability.
The pictures taken on your phone are not "stored somewhere", they are stored "in Google" or "in iCloud" or "in the photos app". Documents are similarily "in Google" or "in Word". There's no intuitive relation between photos and documents being the same thing on the filesystem, nor is there a concept of the filesystem at all. Generally, things jusr "work" (until they don't) and nobody asks any questions.
Now, I would like to clarify that this isn't a "darn kids these days" tangent, in fact, it's the opposite: darn adults these days won't teach their kids how to use the computer!
I would expect/really hope that when my generation starts having kids, computer literacy will start going up again. But for now, it's totally in the drain.
With respect to developers... Most of them know a lot less than they should. This is also an education/incentives problem.
I would bet most of the greyhaired people on here as well as those who were born at the time of the personal computer revolution didn't have parents who were proficient in a technology that was literally just made available to consumers yet those kids learn to use a computer on their own at a time where there was no internet available to check.
Why do kids suddenly need to be taught personally when they are the first generation to have the greatest amount of resources to learn how to use a computer available for free, in multiple teaching styles, multiple formats, at different levels of detail?
I feel this is related to the helicopter parent mentality that replaced parenting styles from earlier periods
Lower is not lowest.
Looking around though I think it's going to depend on what industry parents are in. There's still a lot of cluelessness around even among people who have grown up in an era of computers.
I did something similar with my dad when I was a kid. First basic HTML then Dreamweaver.
A couple years down the road and I’m working at a SaaS company.
Beware.
Decades later I'm tuning YAML files that trigger ansible runs on CIs that compile docker images in which we embed hundreds of npm packages that get transpiled from typescript. Which gets released to cloud serverless edge thingies that store stuff in a database and on some block storage. All to serve a page that's similar in information and feature-density to what I handcrafted back in 1999 in notepad.exe. Yet hundreds of times the size, thousands of times more complex and much, much slower to run and load.
(I'm not exaggerating, but I did pick the worst example. Most of my work is building backend stuff in rust, simple static sites in hugo or jekyll and occasionally sime JS or TS to spice these static sites up with client-side features)
Seriously, I think about this quite often. I recently found some old code that I wrote in the early 00s and it was wonderfully simple, and aside from a few visual trends that have changed, it looks pretty damn good. Straightforward layout, good information density, and very clean. The best part is the code is vastly simpler than anything I've seen/built in the last couple of decades (especially since CSS, packers/transpilers, etc started arriving). I grant that there are some good reasons to introduce CSS and divs and all that, and that once we've done that it is inconsistent to have some things done in html and others in css, but sometimes philosophically better isn't better in practice. Sometimes.
I love how this ends on an exclamation mark and not a question mark. Obvious in hindsight.
By any chance was this made on a tablet? I see it mentions “tablet… make a website”. Perhaps if children grow up having accessing to tablets over computers, making websites on them won’t seem as foreign compared to a computer.
I‘m intrigued! We also have two dogs and the more I know them, the more I‘m fascinated by their ability to tell us exactly what they feel. I didn’t know they can learn to use buttons to do this.
I am deeply impressed.
Did your daughter face this problem?
Ah the good old days :')
Many large companies have wasted lots of money on performance and UX while still being worse than this!
PS I don't like that CloudFlare Pages strips .html. Too magical.
> What to Submit
> (…)
> Off-Topic: Most stories about politics, or crime, or sports, or celebrities, unless they're evidence of some interesting new phenomenon. Videos of pratfalls or disasters, or cute animal pictures. If they'd cover it on TV news, it's probably off-topic.
https://news.ycombinator.com/newsguidelines.html
It is because you’d hear about that anywhere and everywhere else that it doesn’t belong here. Would you complain that a forum about cooking or sharing wallpapers didn’t cover the news as well?
Though it was submitted and discussed anyway, which always happens. That can be confirmed with your own keywords.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
I’m not sure of the activity level of HN at the time it occurred.
https://hn.algolia.com/?dateRange=pastWeek&page=0&prefix=fal...
Ironically, I find the most HN comments of all to be the ones who complain about something being too HN.
Which is not to say your comment wasn’t humorous, but let’s not be too quick to cast stones.
The communicator does have responsibility on how their message comes across, thought not all of it. It’s on the receiver to also make an effort to understand what was meant and not take unnecessary offence. The comment reads pretty much neutral, apart from a post scriptum which is explicitly about the author’s preference. It’s up to you to inject the writer’s feelings as either “this code sucks, here’s how you do it” or “congratulations on making something cool, here are a few suggestions”.
My experience is that life is much better if you take the latter approach. Default to empathy.
Consider listening to “This is Water” from David From Wallace.
https://www.youtube.com/watch?v=eC7xzavzEKY
Connection before Correction - code review
Oh hey, I learnt a new thing today!
It always felt apt to offer a few words of praise for the things that are good, or to establish common ground in code review before offering constructive critique.
Wouldn’t call it a must, but makes putting one’s own ego aside when receiving critique that much easier and lets me focus on improvement, I try to do that for others as well now!
We talked about that, and she thought it looked better that way.
I personally prefer having the /> even though it's not necessary, so that I can tell at-a-glance whether a tag is self-closing or not. It doesn't hurt, does it?
(plus I'm just used to it because the book I learned HTML from was confident that XHTML was the future)
xhtml still works in modern browsers btw. It's still probably the easiest way to do page templates. XSLT shows its age without the ability to modify the page after load (unless you run it via javascript), but we could've just added that and it'd be almost perfect.
① The trailing slash doesn’t make a tag self-closing. All it does is get ignored, emitting a parse error (which in common compiler terms is just a warning) if you use it on a non-void tag.
You can’t use <div/>. You can’t use <custom-tag/>. The only tags you’re allowed to use the trailing slash on are the defined void tags like <img> and <br>.
It’s not “not necessary”, it’s “completely useless, by definition”.
I’ve seen people presume they can close tags this way. JSX probably helps cause this, because you can there. But because self-closing tags aren’t a thing in HTML syntax, I think it’s harmful to use the spelling at all in HTML syntax.
② I wouldn’t mind so much if people used it consistently, and I wouldn’t mind at all if it was being used to support both HTML and XML syntax, but if you see sites that use trailing slashes on void tags in their head, practically every time there will be at least one tag that isn’t using it:
③ I also dislike it because it’s fairly common for syntax highlighters or other casual parsers to get it wrong. Most commonly, I’ve seen tools misinterpret an unquoted last attribute, treating <a href=/example/> as <a href="/example" /> rather than <a href="/example/"> before. (Same with the likes of <img src=/example/>, but anchor hrefs are more commonly going to look like that.)I have never heard of anything even vaguely matching your description, and it would be wildly wrong. HTML parsing is exhaustively defined, and the only way of correctly parsing HTML is to use the defined HTML parser.
While most of th 7 year olds contemporaries are busy consuming content instead of creating it like this?
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.
If the comments were properly nested you would just have a standard left margin and the tables would be completely unnecessary.
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.
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.
I hope <frameset> continues to work into the future. I'm sure eventually it will wind up on the chopping block, and personally I think that'll suck.
It's more: has made it into a standard and was commonly supported.
Sadly, the browsers aren't trying hard enough not to break anything. They are trying hard not to break anything standard, but the problem with that is that the standards can change, or that some things can be claimed to never have been standards all along. A bunch of IE/Netscape things have broken already such as BLINK and MARQUEE, despite being common enough to "feel" standard even though yes they were never actually standards. Also, as we've seen with the MathML battle in recent years, even standards aren't guaranteed to be kept in browsers if not "commonly supported".
The MDN deprecation warning on FRAMESET:
> Deprecated: This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes.
The browser support table says that every browser still currently supports FRAMESET with simple COLS and ROWS, but as I recall FRAMESET used to also support more complicated layout tools. My brain recalls it as being very similar to TABLE layout at one point in time that you could also have (limited) COLSPAN and ROWSPAN options. Such things may also have been IE/Netscape era "non-standards". If I had examples, they are probably lost to time. Similarly, with nearly no way to easily search in today's indexes for things specifically from the 1990s I can't think of a good way to find old examples either. It's also possibly my memory is just failing me on this and the crazy things I recall doing with framesets were just table layouts after all and maybe iframes, but I do recall doing some crazy things in the 90s that certainly aren't "standard" today and I know wouldn't work in today's framesets.
Otherwise, we're stuck with Chrome Forever. I'd rather not.
We'll get better at building software. Even with huge engineering teams, we can only build the browsers that we have today due to improvements in large-scale software engineering.
Keep your eye out for Ladybird Browser and Servo.
I still use tables (seriously).
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/
The benefit would be that the author can understand how to use it better.
css also gets complicated much faster than html. I like to offload complexity to less complicated areas.
a practical example: i look at each row and set rowspan for duplicate values. a series of rows might have week 22 as their first cell and multiple with monday as their second.
How about "one pretends to be a layout, and the other is a layout"?
I don't understand well what you are saying, but:
> a practical example: i look at each row and set rowspan for duplicate values. a series of rows might have week 22 as their first cell and multiple with monday as their second.
This seems to be a case of using a table as a table, which is fine. You should use tables when you are trying to represent tabular data.
you use grid flex or even float (if you need L or Z shaped cells)
I wonder if any notable sites still use tables even for complicated things such as, say, nested comment threads?
Good one
Although I suppose at this point Hacker News is the peak of table layout!
Look, it works and lets me move on to stuff that matters.
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.
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.
Like compare that mess to the elegant semantic structure of a state of the art webpage like google.com
> Open up wide! Here comes some 'content'! Quit complaining, you can handle it!
Hard disagree on both points.
Disclaimer: I'm not found of web techs...
Also, there's nothing XML-but-not-actually about HTML. Both HTML and XML are derived from SGML.
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.
Have you met any 7 year olds? Have you taught any beginners to do computer stuff?
Love this OP, thank you for sharing.
I've been trying to get mine to use an alias but so far is one per service and loses a bit of magic.