Damn, I miss those days. There were no big walled gardens, no Twitter or Facebook. If you had anything to say to anyone, you had to put together your own website. It was amazing.
I also created websites back in the day with spacer gifs and framesets, but I don't understand this qoute.
People still create their own website. There are still a lot of forums with a wide range of topics.
For example: not so long ago I was into reef tanks. There are a ton of forums and websites about that subject. Maybe even more than in the old days.
My personal take on this, I think this quote stems largely from the fact that a lot of people funnel into their social media walled garden without second thoughts, and simply publish there. Without it, you have to self publish on what we know as a website. (Just think of it, what would you do if you have something to say but there are no social media behemoths)
Further, your audience was potentially everyone with a browser. You had full reign in your creativity, your means to style your page to your like was limitless, even if that meant 20 rotating gifs that took forever to load on dial up.
All the social media bubbles score low on self expression- I personally feel this is what is missed most on those platforms. Yes, even if some were butt ugly. :)
Myspace scored big on self expression and eventually that's what's killed it.
What's missing from the so called social medias is genuineness, when you have your own website you don't usually post crap there (well some ppl do shit where they eat but that's an exception).
It's not the same. Those who create their own websites today do so by buying a domain and some equally cheap webspace.
Back then this was not an option, and we were glad to have sites like Geocities.
Many of us were kids or teens with no access to credit cards or PayPal, and the web was really new. The animated "under construction" GIFs served a purpose, and the topic we posted on felt different. As if it was for fun, saying "I'm here", instead of "Look at what a pro I am, what knowledge I have, book my time".
Far fewer than back in the late 90s and early 2000s. I think the reason for that is because people didn't actually want to make websites - they wanted to have a voice on the internet and making a website was pretty much the only way to do that. Now if you want to publish your ideas about reef tanks you could learn to write HTML and CSS and make a website, or you could write on Twitter, or you could make YouTube videos, or you could do a podcast, etc, etc.
There are fewer people making websites but there are more people publishing something on the web.
I think when the web industry's old guard lament the fact that no one really builds homepages any more it's genuine and heartfelt because they (and I include myself in this) really enjoyed looking at what people made. For me to see what interesting and exciting ideas people have that they can do with HTML and CSS is much harder now. There's Glitch and Codepen and stuff, but I feel like I'm still missing loads of the best stuff.
And it was great. It was a barrier of entry for speech. You could do it, it was free, but you had to apply some effort, you had to have something to say.
Now the Web is flooded with morons on Twitter who's opinion is just the noise you have to filter through.
Don’t over romanticize it. There were a lot of experiments, goofiness, and bad information in those days, too. It was also nearly impossible to find anything.
There was a beautiful period before Google was reverse bought by DoubleClick where you could find damn near anything. Searching was a solved problem by Inktomi and AltaVista but PageRank solved sorting search results (for a while).
Before Google AltaVista's search was pretty good at filtering out the meta tag spam that bubbled up in other search engines.
> beautiful period before Google was reverse bought by DoubleClick
That's a beautiful way to put it. I remember those days and thing is, much of Google's reputation was built during those days, a coattail they're still coasting on today.
In those days I remember you could find anything at all in just a moment. "Information snacking" was a thing, versus "being given the answer we think you want (or the one that will make us the most money)".
"Reverse bought by DoubleClick", will have to remember that..
Making your own website today is still possible, but the chances of people actually reading your content is really low unless you invest a lot of time into SEO. A large part of the browsing population never leaves their walled garden and only reads what's posted there. So unless you get crossposted into their filterbubble, your content is just invisible.
On the flip side, I was personally always venturing out into the Wild Wild Web to find new, interesting content. It had this sense of adventure that is pretty much gone nowadays
Acid1 and Acid2 are kinda legacy. Acid1 is so old that IE6 passes it. Acid2 was mentioned in an article.
Acid3 is kinda... controversial. Its tests were kinda nonsensical and hardly useful. Some of things it asked for (in particular about SVG fonts) were implemented minimally, just to pass the tests.
A lot of Acid3 tests involved checking the error code for weird edge cases specifically, stuff like testing whether `document.createElementNS(null, "d:iv")` throws `NamespaceError` (browsers these days throw `InvalidCharacterError`). This isn't really useful for web developers, because actual websites won't test for edge cases like this. It's to the point where Servo (a web engine written in Rust) outright asks the user to report a bug in Servo if unpaired surrogates in DOM are used on a page that isn't Acid3. So far all the bug reports were for Acid3.
> A lot of Acid3 tests involved checking the error code for weird edge cases specifically
If the browsers implement these specification details correctly you don’t have to have all these workarounds that make web development incredibly tedious and unpredictable. That’s the point.
Of course it’s impossible to predict outright which things are going to be used and which things aren’t. Otherwise you could just not create a specification for the useless parts.
Not really. A lot of DOM tests involve try/catch, and checking whether the exceptions are precisely right. Web applications tend to not intentionally throw exceptions.
Acid3 also tested some other things like SVG fonts. SVG fonts specification didn't make any sense, browsers were against implementing an under-defined specification not designed to interact with HTML and Acid3 test authors likely realized this, because a lot of tests were like: a web browser can do this or this or this, because we have no idea what the specification requires. You really don't want a standard like this in a web browser. Web browsers implemented bare minimum sufficient for Acid3, but literally nothing else. WOFF won over SVG fonts in the end as it was a better specification, but Acid3 insisted on SVG fonts. Case in point about issues with SVG fonts: what should `<iframe>` in an SVG font do? The specification won't tell you.
Some other tests also feel weird. For instance, test 86 is literally checking whether `new Date().setMilliseconds()` returns `NaN`. I mean, that doesn't seem very useful to me, why would anyone pass no arguments to a setter intentionally? Official ECMAScript Conformance Test Suite would be a better place for this test.
What I think is fine in Acid3 is CSS selector tests, the rest is honestly kinda pointless. I have the same issue with Acid2, the CSS tests in it were fine, but Acid2 test also decided to include an SGML comments test for who knows what reason. Web browser vendors were against this test, but had to support it anyway. SGML comment test broke real world web sites without providing any real value. Thankfully, this test is now gone from Acid2.
I hope Acid4 won't happen or if it will, it will ONLY have CSS tests and won't test anything else. Although, it likely won't (thankfully) due to The Web Standards Project's closure.
These days, both Firefox and Chrome get 97/100 out of Acid3 (Edge gets 98/100) so there is a small number of tests in that old page which do not make sense for the web of the 2020s.
The point of Acid2 was to make it visible just how awful IE6’s CSS support was.
Back in the 90s I wrote my high school's first website. We even got a scan of a picture of the school done in way too high resolution. It was a massive pain to get running, given my buddy and I were in our mid teens and the web was moving fast. Everything was a bunch of different hand crafted pages of tags, served from a machine sitting in the school. But basically we figured out how to do it by reading one or two pages about it.
I left school and eventually did a lot of financial coding, which was mainly backend stuff plus a small amount of desktop GUIs, or very very basic web pages.
Not until a few years ago did I have another look at the web, and it had of course changed enormously. It seems nowadays everything is a tool that compiles into something else. There's a zillion frameworks in js, there's webassembly, there's a bunch of things that you use to build the CSS. The page itself seems to be a load of divs, many tags from the old days are archaic now, only seen on old university sites. Sites themselves are served from a datacenter, and not from one machine. Static content doesn't even need to come from the same place. Security and privacy is a thing. There's no one place to learn the whole thing, which I suppose is expected.
You still can write static HTML/CSS and host it on your machine (if you have accessible IP) or some cheap VPN. It'll work just fine. It's possible to write a very complex websites nowadays with those technologies. But not every website have to be complex.
Not a lot of people had computers with Internet back then. So sure, you can’t captivate the same percentage of the entire World Wide Web - but why would you expect that to be a reasonable assumption?
Sure, in a world where the web was a couple million nerds you’d expect your content to be a bit more visible.
But the web is measured in billions of users now.
I would also suggest that writing content just to ensure that people read it is looking at it the wrong way. That’s a shallow popularity contest. If the production of that content doesn’t bring you satisfaction on its own then it doesn’t matter whether you have 1 view or a million, it’s not making you happy.
Humans seek social interaction, whether that's in person or online, or by doing good or bad things to get attention. I would not call that a popularity contest because it happens with everything. A popularity contest would be one extreme end of a range of behavior.
If you are producing content for yourself and it makes you happy then you don't need to put it in public view. The whole point of the internet is to interact, share your work and see others' work.
That is the point I was refuting. In the current web, communication is still the overarching motivator. Content still matters, and the usability of your site is a factor in communicability. So, if someone's site is easier to navigate and more frequently updated due to the use of updated technology, that may be a factor when people decide where to spend their time.
> There's no one place to learn the whole thing, which I suppose is expected.
Mozilla Developer Network is what I highly recommend. It covers so much of the web they even have Django web development guides / tutorials. Ages back Microsoft contributed their own docs to MDN as well (not to be confused with MSDN, which is Microsoft specific and possibly where that spec came from).
Which doesn't mean you HAVE to do it this way. The new generation of devs is, well, young, and they have yet to learn that complexity will come back after their asses with no mercy.
Us old farts, we learned that complexity is our biggest enemy.
That assumes that all of this complexity was done for complexity’s sake.
There’s a big difference between a web developer who has to serve a few thousand people 10 webpages with someone who has to serve millions of customers in hundreds of countries with dozens of languages.
I suspect that a lot of the “old farts” you reference in this way aren’t old farts at all, but are just folks who haven’t been full time web developers in years, or have never done web development for a large web-based SaaS company.
And how many developers do you think out there have to "serve millions of customers in hundreds of countries with dozens of languages"?
Most of them solve problems they don't have.
Ask anyone to build a Hello World in Javascript, and it will be a Node app with 30,000 packages, using 7 AWS services, with a full CI/CD pipeline, running on Amazon Fargate.
Because this Hello World is going to be BIG, it has to be webscale.
> Ask anyone to build a Hello World in Javascript, and it will be a Node app with 30,000 packages, using 7 AWS services, with a full CI/CD pipeline, running on Amazon Fargate.
I don't think the mentality that drives this is "is has to be web scale" or "it will be BIG". The justifications I've heard are more along the lines of "now I don't have to manage a server". Except... you either have to learn/know how to configure something else and tell it how to manage a server, or just copy/paste/trust that you're telling service X how to configure/manage the server that you eventually need.
Or... lambda - because somehow every single problem people think of can just be broken down to chaining AWS lambdas together. I've run in to that mindset a couple of times, and it's just so foreign to me. I can't say it's "wrong" as I've not done it 'for real' (beyond playing with hello world stuff), but it typically ignores a lot of stuff I've come to embrace (like testing).
> Ask anyone to build a Hello World in Javascript, and it will be a Node app with 30,000 packages, using 7 AWS services, with a full CI/CD pipeline, running on Amazon Fargate.
I think you're just exaggerating to make a point of outrage. I don't think anyone would write a Hello World that way.
Also, how many companies do you think decided to go serverless and then discovered after the fact that they can't serve a live website because of Lambda's spin-up delay, coming up with a patchwork of cache bandaid that made things just worse?
But it's new, and it's cool, and in the language of us Mandalorians - THIS IS THE WAY.
> And how many developers do you think out there have to "serve millions of customers in hundreds of countries with dozens of languages"?
I actually think the answer to that question is most. Most web developers are working for mid-size to large companies, especially when you consider the wider variety of non-SV companies like financial firms that might not be "tech companies."
I think the people that would have written simple web pages that don't require that complexity essentially don't exist in the business world, and probably not so much in the hobbyist world, either. Smaller companies would be better off using code-less website builders and such. And if all these web developers wanted to spend so time making simple blogs and web pages I wonder why they choose services like Medium to do it for them.
As far as small companies that actually write web software as their primary form of business, I would venture a guess that in terms of quantity, compared to FAANG, Chase, Bank of America, Nationwide, State Farm, Progressive, etc, there probably aren't that many.
I would argue this about your point on Lambdas:
A business outgrowing abstractions is okay. That means the business has grown to the point where it can hire enough developers to maintain a more sophisticated infrastructure. The fact that AWS has so many abstractions is a reason why so many startups have been able to exist in the first place.
I've never used Lambdas for a web application, and I do see that Amazon advertises that as a use case, but it's also the second to last one on their list. I think it's far better suited to doing things like responding to AWS CloudWatch Events or triggering other asynchronous actions.
Things aren't done for complexity's sake, but yet most of the web (and software generally) is way more complex than it needs to be. See the 30 million line problem for a good deep dive: https://www.youtube.com/watch?v=kZRE7HIO3vk
It tends to be related to physical age because the problems of complexity manifest with the passing of time. The more projects you work on from start through long term maintenance, the more you personally experience the issues inherent in complexity. Over time your appreciation for simplicity increases and you get a better sense of tradeoffs and long term costs.
A bit of explanation: In the old days of table layouts, the width attribute of a dt element would declare the maximum width of that element only. In order to provide a minimum width, you'd insert a transparent 1x1px image and give it the appropriate width. This could be used both for flexible (min, max) layouts and rigid designs, where everything would be positioned by a system of pole-like transparent images, much like in a Dali painting.
Note on both frames and tables: Right from the beginning, you could declare width and height units in HTML both in percent and in absolute units, like "px". However, Netscape browsers used internally only percents! Meaning, if you you intended to span the entire width of a document, Netscape would convert your absolute units to percent and from this back to px (using integer math for speed) and you would end up with some rounding error depending on the width of the browser window, which could add up to a deviation of 4px or so. Which was, of course, a constant pain, when you intended to line up elements, like a logo on top and a structure with a navigation and a main content area in different colors below.
>CSS today is so good that I now design websites in CSS
There are so many things missing that people are forced to use Javascript and a div-mess to implement widgets. Ex elements like dropdowns, numeric input, the small scrollbar that appears for elements, I am wondering if browser makes are just ignoring css and focusing on JS.(I admit flexbox and grid layout is cool)
Agreed. There remains many moments where I'm questioning why I have to use JavaScript. A css concept exists to accomplish what I'm doing, but it's incomplete. It is also often blind to stuff where css could be useful like basic-auth.
I know, it is not the developers at fault , we the devs pushed against this, we tried to get the native input to look as much as possible as the design but it was not accepted, we had no choice but to use JS and get teh pixel perfect design.
I’ve been in Product Management positions and always advocate for native controls over custom. Too many times I’ve seen custom stuff take way longer to build and make work responsively. Native might not be pixel-perfect to a design but that’s okay; design is how it works, not how it looks.
What I mean for dropdowns is to get css properties to style the "select" element and not have to use div inside divs. For scrollbars I do not remember now the issue we had to use JS, I think on some browser you could not get the exact colors/look the designers wanted.
Edit: as an example in other GUI frameworks you are also limited but you can extend the widget with a custom render function and you can paint the widget as you want, you get the look you want but you keep the native widget behavior like the correct events and keyboard handling where with the nested DIVs you get most of the time missing or broken functionality, even Google could not properly implement the Search and dropdown in YouTube, it gets stuck open sometimes and you have to reload the page.
What is needed is better way for the user (rather than the document author) to customize it. For example, I may want to disable smooth scrolling, or make other adjustments.
Why do you want to style dropdowns or scrollbars? Using those "designer" dropdowns is a pain on mobile, while simple dropdowns just use native controls and work flawlessly. Same about scrollbars, I hate websites that interfere with my scrolling.
> Is not me, the designers want it, we need to ask them why?
Yes: JS widgets have a usability impact and especially accessibility, which is a legal requirement in much of the world. Some libraries have good accessibility stories but given that this is an ongoing cost which will need to be supported it’s always important to link it to an actual requirement (e.g. searchable drop downs) to justify the expense.
There is ARIA, but ARIA isn't quite good enough. I also suggested a <widget> element, which allows you to define your own widgets and provide an implementation in HTML and JavaScript to be used if the browser cannot use it directly (if the widget is implemented directly (subject to user configuration), then the stuff inside the <widget> block is ignored or used in an implementation-defined way; if the widget is not implemented, then the <widget> is treated the same as a <span>, and any <script>, <noscript>, etc it contains is interpreted normally). (For selections from lists, there is already <input> anyways, and the browser can include whatever special features they want; they may be disabled in application mode if needed.)
ARIA is always improving but really the problem is that most developers either don’t use it or don’t test their usage. This is not a problem of needing new technology as much as companies skimping until they get sued.
Brings up a good point—the importance of understanding the requirements/levers of other groups in order to get things done. In this case, pointing out the law.
Back when IE was ascendant and Mozilla was fading, another group in my corp developed a web app lousy with proprietary Microsoft code (ActiveX?). All it took for the CEO to shoot it down was me mentioning that a fifth of our customers wouldn’t be able to give us money. He would’ve done the same for the Mac users at 5%, given the option between a functional and a flashy site. (Seriously, with a Clippy-like assistant!)
This is not true at all, modern component based projects like https://element.eleme.io/ work perfectly find in mobile and you only load the CSS/HTML/JS per component so it doesnt need to load tons of JS just to render simple form or UI components from Vue or React.
I literally watched the select dropdown jitter all over the place scrolling on mobile. It's bad. The native controls don't require a library and are fine. And all of the event handling and HTML5 form validation works as expected.
Same. I find it faster to make a couple of quick rough mockups on Illustrator or even paper and then do the final design in HTML.
15-20 years ago we used to make the final design of every page in Photoshop or Freehand and show that to the client. Now I just make the front page in HTML so that we can agree on the look&feel.
Another benefit of working directly on HTML is that you can start proofing some of your design decisions. Many problems are still not obvious in Illustrator/Sketch/whatever. Specially for the client. In my current project I envisioned a featured to open a form on a modal but when I started doing it looked nice but it just felt wrong. The form worked a lot better in a tooltip-like element.
The thing that baffles me is that even in the present day, (some) graphic designers are still trying to create web sites using a different medium than the end product. Sure, back in 2005 that was the norm, but it’s like nothing has changed for these folks. The platform has evolved so dramatically, but the “Photoshop workflow” stays the same.
While Grid(I love named areas!) and Flexbox have improved layout, the initial layout process is still rougher than it should be.
Pretty much every other design/layout/ui creation tool has all kind of helpers which pure CSS lacks.
I am talking about basic guidelines, rulers etc that every tool/layout under the sun (QT, WPF, WinForms, Photoshop, Illustrator even Powerpoint, you name it the basic alignment rearrangement functions are a mouseclick away.
Sure the created document might be a huge mess, but that is not the point when you are messing around.
If you start messing around with CSS you enter a world of pain unless you know the properties down cold.
Client asks how would that picture look here and that menu shrunk a bit down here?
With CSS it would take much longer to iterate than with any other tool.
With something like WPF I do not need to know XAML by heart to quickly create some reasonable working mockups for a .net application.
This explains why it is much easier to do creative mockups in another tool (I see designers who use Adobe XD quite a bit now).
When one is in the creative stage CSS is a huge hindrance.
It depends on what a "mockup" is.
In sane web development, done by a web designer with HTML and CSS (not by a graphic designer with Photoshop), a mockup is a web page with mock content and incomplete stylesheets.
I remember the days of “pixel perfect HTML” where clueless clients wanted the resulting web page to look exactly like the Photoshop mockup down to the pixel.
I spent so many work hours devoted to getting elements lined up pixel-perfect to match jpegs from graphic design, and then struggling to get them to also match up in the other browsers. During some periods you even had to fight between versions of IE. Man, those were some expensive pixels!
In my experience, designing websites in the browser limits the imagination and thus the design ends up being easy to build in HTML/CSS, but it isn't very interesting. Using design tools makes it easier to get the look you want - and from there you figure out how to put it together in the browser. It's an extra step, but my own designs are much better when created this way.
For me it still fails short of what I am capable to do with native toolkit layout managers, and grids come from WPF by the way.
HTML + CSS to me, even after all these years still feels like programmer art when starting from a piece of paper, while with native coding it just flows, maybe I am tainted by my game/demoscene grassroots.
When the browser wars ended 15 years ago, not much have happened. The innovation has instead moved to userland, which achieve things with crazy hacks and meta/trans-compilation. We have committees writing new "standards" faster then anyone can implement them. But there is no natural selection. What browser engine are you going to switch to if you are unhappy with your current one? That said, most of the hard problems have already been solved, so writing vanilla html/css has been a breeze ever since things settled. And its also very stable.
Yes, but it seems like Firefox is only keeping up, they are playing defensive, while they really ought to attack weakness in Chromium or give users a reason to switch. Right now Chrome is slightly more efficient, slightly better feature coverage, etc.'
One reason why I still use Mobile Opera is because it automatically adjust the text when I zoom in...
A bold move for Mozilla would be to cut down expenses to a 3 year buffer, cut their funding from Google and force themselves to become independent.
95% of Mozilla money comes from Google. Last time I checked Firefox still sends everything you type into the address field to Google. So if you do not trust Google, how can you trust Mozilla!?
> We have committees writing new "standards" faster then anyone can implement them.
This isn't really true; the committees writing the standards are primarily formed of implementers, and the implementers aren't paying anyone to write a standard they aren't going to implement in the near future. That said, the early idea-incubation committees too often end up with just a single implementer involved.
That's because the author intentionally added gaps via "grid-gap:10px" and changed the alignment via "align-items:baseline". You could easily undo either of these styles to achieve the desired effect.
> (Native buttons also went out of vogue, for some reason.)
Ah, I still remember native buttons being introduced. Good times, back when browsers could introduce features that seem so obvious in retrospect - such as spell check in text boxes. Feels like all the low-hanging fruit has been picked by now. (Or is it? Firefox's integrating a password manager feels pretty similar.)
Great overview, though. I feel like my history with the web has been almost the same as the author's, and this brought back a lot of good and not-so-good memories.
Browsers still lose my 15 minutes of typing when something goes bad and I'm returning back to page. I understand that it's usually caused by websites forbidding caching, so browsers have to reload page, but they still could save that data somewhere and present me an option to restore it, at least for some time. Something like auto-complete.
For this reason I attempt to develop a habit to type every comment or post in vim first. This loss of typed text happens maybe once in 2-3 months but it's extremely annoying.
Exactly! Sometimes I wonder why browsers have no hook for launching external editor for textbox input, like EDITOR env in shell? This could also solve the need for RichTextbox with JS based controls for bold/italic/bullets etc.
That would be good for replacing jQuery and so on, but I would want to be able to replace inline scripts too sometimes. (And also some sites have their own copy of jQuery; I will still want to substitute my own if their own copy is otherwise unmodified.)
One of the few add-ons I've installed that's been worth its weight in gold has been "Form History Control (II)", which passively saves every comment as I type it. It's saved me no end of grief in these scenarios.
For a moment browsers were pretty good at this because pages were still static enough that browsers could keep track of elements over page reload. But now that everything is dynamically generated by a few megabytes of opaque javascript? It's a much trickier problem. But "luckily" there's LocalStorage these days so website devs can just go and reimplement the feature…
> Browsers still lose my 15 minutes of typing when something goes bad
It’s not browsers but poorly-designed JavaScript: if you use a standard HTML form all browsers will preserve state and resubmit it for you on retries. The problem is when you have JavaScript altering the form but not reimplementing the standard state management, and since few sites do more than casual testing these days it tends to require a number of user reports before that’s prioritized since it’s so easy for lazy developers to blame the error condition rather than accept that handling it is part of the job.
It's a specific case of a larger symptom: when you implement something in JavaScript that replaces default browser functionality, you also have to re-implement all of the related error handling, edge cases, etc., and can't rely on the work that has already been put into making things work correctly in the browser. But in practice, JavaScript developers never fully re-implement the features that they replace, which means all that work on the browser has gone to waste.
Oh man, I think there's so much low hanging fruit left. Browser native components for autocomplete, infinite scroll, an actual rich text editor, scroll / zoom controls, etc. would all be very welcome.
Absolutely, in terms of things that should be added to the standards and then supported by browsers, there's plenty left to do. I was mainly referring to things browsers could add on their own accord, though, like spell check, or a password manager.
(Just though of another example: Picture in Picture video playback, like Firefox recently added and Chrome and Safari have technically already had for a while.)
I used NN3 and 4 back in the day (and still do, kinda, Firefox is still my main browser), but man, writing CSS for Netscape was a nightmare!
I still remember that weird bug that forced everyone to create a single, empty, invisible DIV at the beginning of the page if you wanted to set absolute positions for the other DIVs in the page.
In Javascript land, we all had our little script to detect the browser and do things like finding the element you wanted (IIRC, only IE had find by id).
All in all, I miss the carefulness webdevs had to have at the time (I remember uglifying my files by hand to make everything weight less than 24KB, which was the self-imposed limit we had at the dotcom I worked at) but, in general, I don't miss those days at all.
NN didn't actually do CSS, it did JSS (Javascript Style Sheets, something Netscape hoped would fly) with an added translation layer. That meant that you could only style an element through its hierarchy (since there was no equivalent of IE's document.all in Netscape's DOM). $DEITY help you if you were trying to do a hybrid tables/CSS thing, especially with nested tables.
Great article! CSS has become so easy to work with after css flexbox and various css preprocessors became available. I remember how excited we were in 1995 when we discovered we could use ta les and gif spacers to achieve almost any kind of page layout for our clients. The web is a big stack of different hacks that slowly improves over the years. CSS has become wull continue to evolve for many years.
for layout , i still think tables did it right, because web is primarily a grid like newspapers. wish we had a <grid> type of element with responsive rows and cols, if only to help with vertical alignment and those missing </div>s
Html tables are not all comparable to newspaper columns. Newspaper-style columns (where text flows from the from bottom of one column to the top of the next column) can be achieved with the "columns" property in CSS.
But newspaper-style columns are not as useful on the web, since it is really annoying if the columns are longer then the screen and you have to scroll up and down. In that respect the web is very different than newspaper layouts where the dimensions are fixed.
As for <grid>, layout should be specified in CSS rather than through the html element, which is why we have "display: table", "display: grid" etc. in CSS, which should do what you want.
Agreed. But tables in the HTML was a mess to maintain, and does not readily translate to a phone screen (which is well over half of Internet usage these days). What I did, in the early 2010s, was use “display: table” CSS for the elements in up to date browsers, then use some ugly “<!--[if lt IE 8]><TABLE><![endif]-->” for Internet Explorer 6 and 7.
I loved reading this. My first job was mainly spent fixing IE box model problems (remember when Microsoft could only ship Trident updates as part of huge Windows updates?!). I now have an allergic reaction to any cross-site compatibility problems, because -- in a rare exception to the rule -- it genuinely WAS harder in my day, and we managed it.
I remember making a page that when browsed to, would pop up an all-black full-screen "chromeless window" and start slowly typing green text Matrix-style. Very neat trick in those early-teens years...
No, I don't miss those days. Making a website look the same in Opera/Mozilla/IE was an insane challenge. The approach I've found worked best was going Opera first, then adapt to Mozilla and IE, in that order. That way the amount of work was minimal. If you did go IE first, ... well, you wouldn't succeed anytime soon.
Yes and no, but there is some confusion due to terminology.
There are HTML tables, created with the <table> tag, and then there are CSS layout tables created with the "display:table" property. Neither are inherently good or bad, it is just a question of when they are appropriate.
The problem with tables back in the day was that browsers didn't support "display:table", so the only way to get a grid-like layout was to use the <table>-tag. In cases when the content wasn't semantically a table, you had a dilemma. Either you would have to abuse the <table> tag thereby hurting accessibility, or you would have to use CSS floats and hacks to achieve the desired grid-like effect. Neither was really desirable.
Today we have "display:table", but we also have flexbox and grid which is are much more powerful, so the use of tables-for-layout are mostly irrelevant.
Internet Explorer on Windows was the singular offender. ISTR that other ones with at least 0.7% market share were implementing the display property correctly.
> In cases when the content wasn't semantically a table, you had a dilemma.
If you have text that's laid out with a fixed number of columns and a dynamic number of rows, than what you have is exactly a table.
Absolutely no reason to get your underwear in a bunch in a rage of hipster semantic pseudo-purity just because it's not literally a table of Excel figures.
I feel like I learn a lot more about CSS from articles like these as opposed to books because it puts CSS features into context with the problems they were meant to solve. The historical context helps a lot, too. The way that I've tried to learn CSS in the past was essentially a random collection of tricks.
Are there any more articles like this? I'd read them all day.
I have a slightly wild theory. I think that it has to do with my brain seeing the textbook topic as one item on a massive stack of items to study. Kind of like how much easier I find it to do a chore when it's not literally an infinifely looking sized amount of work ahead.
At St. John's College (back in the 90's anyways), we called this "teaching science and math historically" (as opposed to teaching the history of science and math -- which tends to emphasize dates and names).
By telling the story of science and math, we gained the context of who did what for what reasons. Which unlocked my understanding of science and math in a way that textbooks never did.
I've got this problem when teaching people things. When I need to explain a single feature, I feel it helps to give historical context for why things are the way they are, but it's hard to concisely give just the relevant context in that case - because there's just so much of it. Getting the whole picture in one go might be a lot better.
(Interestingly, the historical context could also pre-empt much of the criticism of "the modern web", or lamenting about not every browser building on Chromium.)
When people shit on modern web development, it's hard to explain how responsible tools like webpack and babel have been in pushing the web forward so we can actually build what we can imagine.
There is SO MUCH we simply don't think about anymore because the tools do the thinking for us, like CSS prefixing mentioned in the article. I can't remember the last time I manually prefixed a CSS property, I've used tools that have autoprefixing built in since 2015. I just don't think about it anymore. Nor the differences between ES3, ES5, ES2015, ES2017 or a host of other things.
This means my brain is free to spend that energy in other places and that's absolutely a godsend for productivity.
People shit on modern web development exactly because these kludges are necessary in the first place. Imagine if that time and effort was spent on something more productive instead.
The problem is that those tools, while solving some problems in the development stage, create a host of other problems at other points in time: first install, building, deployment, maintenance...
That is great, but how ridiculous is it that this microsite is made with 100% js dom manipulation instead of just static html? I wonder if they did that because using static html would have potentially not rendered the way they intended on all the current devices...
Those gridded links remind me of the NeoPets site which would overlay a very busy "map" image with a tiny link, which would take you to a page with tons of powerful items. You used to be able to find the link with tab - the accessibility feature that barely highlighted / cycled through links. They simply removed that accessibility feature from their page.
252 comments
[ 4.2 ms ] story [ 264 ms ] threadI also created websites back in the day with spacer gifs and framesets, but I don't understand this qoute.
People still create their own website. There are still a lot of forums with a wide range of topics.
For example: not so long ago I was into reef tanks. There are a ton of forums and websites about that subject. Maybe even more than in the old days.
Further, your audience was potentially everyone with a browser. You had full reign in your creativity, your means to style your page to your like was limitless, even if that meant 20 rotating gifs that took forever to load on dial up.
All the social media bubbles score low on self expression- I personally feel this is what is missed most on those platforms. Yes, even if some were butt ugly. :)
What's missing from the so called social medias is genuineness, when you have your own website you don't usually post crap there (well some ppl do shit where they eat but that's an exception).
It's not the same. Those who create their own websites today do so by buying a domain and some equally cheap webspace.
Back then this was not an option, and we were glad to have sites like Geocities.
Many of us were kids or teens with no access to credit cards or PayPal, and the web was really new. The animated "under construction" GIFs served a purpose, and the topic we posted on felt different. As if it was for fun, saying "I'm here", instead of "Look at what a pro I am, what knowledge I have, book my time".
Geocities was also a walled garden, but the scale was totally different. It is amazing how many people are online today.
Far fewer than back in the late 90s and early 2000s. I think the reason for that is because people didn't actually want to make websites - they wanted to have a voice on the internet and making a website was pretty much the only way to do that. Now if you want to publish your ideas about reef tanks you could learn to write HTML and CSS and make a website, or you could write on Twitter, or you could make YouTube videos, or you could do a podcast, etc, etc.
There are fewer people making websites but there are more people publishing something on the web.
I think when the web industry's old guard lament the fact that no one really builds homepages any more it's genuine and heartfelt because they (and I include myself in this) really enjoyed looking at what people made. For me to see what interesting and exciting ideas people have that they can do with HTML and CSS is much harder now. There's Glitch and Codepen and stuff, but I feel like I'm still missing loads of the best stuff.
Now the Web is flooded with morons on Twitter who's opinion is just the noise you have to filter through.
Before Google AltaVista's search was pretty good at filtering out the meta tag spam that bubbled up in other search engines.
That's a beautiful way to put it. I remember those days and thing is, much of Google's reputation was built during those days, a coattail they're still coasting on today.
In those days I remember you could find anything at all in just a moment. "Information snacking" was a thing, versus "being given the answer we think you want (or the one that will make us the most money)".
"Reverse bought by DoubleClick", will have to remember that..
ACID2 looks fine to me in Firefox 72, but then, it doesn't show a score, so...
For Acid3 there's http://wpt.live/acid/acid3/test.html which reflects what browsers are actually targetting (and is what runs in everyone's CI system): see https://github.com/web-platform-tests/wpt/commits/master/aci... for the history.
Acid3 is kinda... controversial. Its tests were kinda nonsensical and hardly useful. Some of things it asked for (in particular about SVG fonts) were implemented minimally, just to pass the tests.
A lot of Acid3 tests involved checking the error code for weird edge cases specifically, stuff like testing whether `document.createElementNS(null, "d:iv")` throws `NamespaceError` (browsers these days throw `InvalidCharacterError`). This isn't really useful for web developers, because actual websites won't test for edge cases like this. It's to the point where Servo (a web engine written in Rust) outright asks the user to report a bug in Servo if unpaired surrogates in DOM are used on a page that isn't Acid3. So far all the bug reports were for Acid3.
If the browsers implement these specification details correctly you don’t have to have all these workarounds that make web development incredibly tedious and unpredictable. That’s the point.
Of course it’s impossible to predict outright which things are going to be used and which things aren’t. Otherwise you could just not create a specification for the useless parts.
Acid3 also tested some other things like SVG fonts. SVG fonts specification didn't make any sense, browsers were against implementing an under-defined specification not designed to interact with HTML and Acid3 test authors likely realized this, because a lot of tests were like: a web browser can do this or this or this, because we have no idea what the specification requires. You really don't want a standard like this in a web browser. Web browsers implemented bare minimum sufficient for Acid3, but literally nothing else. WOFF won over SVG fonts in the end as it was a better specification, but Acid3 insisted on SVG fonts. Case in point about issues with SVG fonts: what should `<iframe>` in an SVG font do? The specification won't tell you.
Some other tests also feel weird. For instance, test 86 is literally checking whether `new Date().setMilliseconds()` returns `NaN`. I mean, that doesn't seem very useful to me, why would anyone pass no arguments to a setter intentionally? Official ECMAScript Conformance Test Suite would be a better place for this test.
What I think is fine in Acid3 is CSS selector tests, the rest is honestly kinda pointless. I have the same issue with Acid2, the CSS tests in it were fine, but Acid2 test also decided to include an SGML comments test for who knows what reason. Web browser vendors were against this test, but had to support it anyway. SGML comment test broke real world web sites without providing any real value. Thankfully, this test is now gone from Acid2.
I hope Acid4 won't happen or if it will, it will ONLY have CSS tests and won't test anything else. Although, it likely won't (thankfully) due to The Web Standards Project's closure.
The point of Acid2 was to make it visible just how awful IE6’s CSS support was.
Back in the 90s I wrote my high school's first website. We even got a scan of a picture of the school done in way too high resolution. It was a massive pain to get running, given my buddy and I were in our mid teens and the web was moving fast. Everything was a bunch of different hand crafted pages of tags, served from a machine sitting in the school. But basically we figured out how to do it by reading one or two pages about it.
I left school and eventually did a lot of financial coding, which was mainly backend stuff plus a small amount of desktop GUIs, or very very basic web pages.
Not until a few years ago did I have another look at the web, and it had of course changed enormously. It seems nowadays everything is a tool that compiles into something else. There's a zillion frameworks in js, there's webassembly, there's a bunch of things that you use to build the CSS. The page itself seems to be a load of divs, many tags from the old days are archaic now, only seen on old university sites. Sites themselves are served from a datacenter, and not from one machine. Static content doesn't even need to come from the same place. Security and privacy is a thing. There's no one place to learn the whole thing, which I suppose is expected.
When the web was new you could get a lot of hits with static content. It is not so easy to do that now.
Not a lot of people had computers with Internet back then. So sure, you can’t captivate the same percentage of the entire World Wide Web - but why would you expect that to be a reasonable assumption?
Sure, in a world where the web was a couple million nerds you’d expect your content to be a bit more visible.
But the web is measured in billions of users now.
I would also suggest that writing content just to ensure that people read it is looking at it the wrong way. That’s a shallow popularity contest. If the production of that content doesn’t bring you satisfaction on its own then it doesn’t matter whether you have 1 view or a million, it’s not making you happy.
If you are producing content for yourself and it makes you happy then you don't need to put it in public view. The whole point of the internet is to interact, share your work and see others' work.
Mozilla Developer Network is what I highly recommend. It covers so much of the web they even have Django web development guides / tutorials. Ages back Microsoft contributed their own docs to MDN as well (not to be confused with MSDN, which is Microsoft specific and possibly where that spec came from).
Us old farts, we learned that complexity is our biggest enemy.
There’s a big difference between a web developer who has to serve a few thousand people 10 webpages with someone who has to serve millions of customers in hundreds of countries with dozens of languages.
I suspect that a lot of the “old farts” you reference in this way aren’t old farts at all, but are just folks who haven’t been full time web developers in years, or have never done web development for a large web-based SaaS company.
I don’t think it’s about physical age at all.
Most of them solve problems they don't have.
Ask anyone to build a Hello World in Javascript, and it will be a Node app with 30,000 packages, using 7 AWS services, with a full CI/CD pipeline, running on Amazon Fargate.
Because this Hello World is going to be BIG, it has to be webscale.
I don't think the mentality that drives this is "is has to be web scale" or "it will be BIG". The justifications I've heard are more along the lines of "now I don't have to manage a server". Except... you either have to learn/know how to configure something else and tell it how to manage a server, or just copy/paste/trust that you're telling service X how to configure/manage the server that you eventually need.
Or... lambda - because somehow every single problem people think of can just be broken down to chaining AWS lambdas together. I've run in to that mindset a couple of times, and it's just so foreign to me. I can't say it's "wrong" as I've not done it 'for real' (beyond playing with hello world stuff), but it typically ignores a lot of stuff I've come to embrace (like testing).
I think you're just exaggerating to make a point of outrage. I don't think anyone would write a Hello World that way.
There is nothing to be outraged about.
Also, how many companies do you think decided to go serverless and then discovered after the fact that they can't serve a live website because of Lambda's spin-up delay, coming up with a patchwork of cache bandaid that made things just worse?
But it's new, and it's cool, and in the language of us Mandalorians - THIS IS THE WAY.
I will also elaborate further:
> And how many developers do you think out there have to "serve millions of customers in hundreds of countries with dozens of languages"?
I actually think the answer to that question is most. Most web developers are working for mid-size to large companies, especially when you consider the wider variety of non-SV companies like financial firms that might not be "tech companies."
I think the people that would have written simple web pages that don't require that complexity essentially don't exist in the business world, and probably not so much in the hobbyist world, either. Smaller companies would be better off using code-less website builders and such. And if all these web developers wanted to spend so time making simple blogs and web pages I wonder why they choose services like Medium to do it for them.
As far as small companies that actually write web software as their primary form of business, I would venture a guess that in terms of quantity, compared to FAANG, Chase, Bank of America, Nationwide, State Farm, Progressive, etc, there probably aren't that many.
I would argue this about your point on Lambdas:
A business outgrowing abstractions is okay. That means the business has grown to the point where it can hire enough developers to maintain a more sophisticated infrastructure. The fact that AWS has so many abstractions is a reason why so many startups have been able to exist in the first place.
I've never used Lambdas for a web application, and I do see that Amazon advertises that as a use case, but it's also the second to last one on their list. I think it's far better suited to doing things like responding to AWS CloudWatch Events or triggering other asynchronous actions.
Or they just don't know any better.
https://www.youtube.com/watch?v=o9pEzgHorH0
It tends to be related to physical age because the problems of complexity manifest with the passing of time. The more projects you work on from start through long term maintenance, the more you personally experience the issues inherent in complexity. Over time your appreciation for simplicity increases and you get a better sense of tradeoffs and long term costs.
Note on both frames and tables: Right from the beginning, you could declare width and height units in HTML both in percent and in absolute units, like "px". However, Netscape browsers used internally only percents! Meaning, if you you intended to span the entire width of a document, Netscape would convert your absolute units to percent and from this back to px (using integer math for speed) and you would end up with some rounding error depending on the width of the browser window, which could add up to a deviation of 4px or so. Which was, of course, a constant pain, when you intended to line up elements, like a logo on top and a structure with a navigation and a main content area in different colors below.
I was doing Web development in 1999 for a year or too
I never got that deep.
But I recall clearly adopting a left/right column for static content and center column for the CGI output custom stuff.
Choose that format because IIRC it was easy to implement in straight HTML
I looked at CSS then, but it did not make sense business wise when we could make vanilla HTML work.
It was a different world
If you use grids and flex you can rearrange content very quick if the customer wants to move it.
My workflow is now much faster. Great for the client, great for me.
The only design tool I use in the beginning is a pen and peace of paper to get some ideas of where I want to go. But after that it's all HTML + CSS.
There are so many things missing that people are forced to use Javascript and a div-mess to implement widgets. Ex elements like dropdowns, numeric input, the small scrollbar that appears for elements, I am wondering if browser makes are just ignoring css and focusing on JS.(I admit flexbox and grid layout is cool)
I think people should just accept the browser default.
And dropdowns can easily be created CSS only.
To me the use of JS to get the design right always smells like bad practice.
There was another choice: sacrifice the pixel perfect design and accept the native inputs.
Edit: as an example in other GUI frameworks you are also limited but you can extend the widget with a custom render function and you can paint the widget as you want, you get the look you want but you keep the native widget behavior like the correct events and keyboard handling where with the nested DIVs you get most of the time missing or broken functionality, even Google could not properly implement the Search and dropdown in YouTube, it gets stuck open sometimes and you have to reload the page.
Yes: JS widgets have a usability impact and especially accessibility, which is a legal requirement in much of the world. Some libraries have good accessibility stories but given that this is an ongoing cost which will need to be supported it’s always important to link it to an actual requirement (e.g. searchable drop downs) to justify the expense.
Back when IE was ascendant and Mozilla was fading, another group in my corp developed a web app lousy with proprietary Microsoft code (ActiveX?). All it took for the CEO to shoot it down was me mentioning that a fifth of our customers wouldn’t be able to give us money. He would’ve done the same for the Mac users at 5%, given the option between a functional and a flashy site. (Seriously, with a Clippy-like assistant!)
I've heard that so many times and eagerly await the day they want a mobile version for same number of times.
15-20 years ago we used to make the final design of every page in Photoshop or Freehand and show that to the client. Now I just make the front page in HTML so that we can agree on the look&feel.
Another benefit of working directly on HTML is that you can start proofing some of your design decisions. Many problems are still not obvious in Illustrator/Sketch/whatever. Specially for the client. In my current project I envisioned a featured to open a form on a modal but when I started doing it looked nice but it just felt wrong. The form worked a lot better in a tooltip-like element.
While Grid(I love named areas!) and Flexbox have improved layout, the initial layout process is still rougher than it should be.
Pretty much every other design/layout/ui creation tool has all kind of helpers which pure CSS lacks.
I am talking about basic guidelines, rulers etc that every tool/layout under the sun (QT, WPF, WinForms, Photoshop, Illustrator even Powerpoint, you name it the basic alignment rearrangement functions are a mouseclick away.
Sure the created document might be a huge mess, but that is not the point when you are messing around.
If you start messing around with CSS you enter a world of pain unless you know the properties down cold.
Client asks how would that picture look here and that menu shrunk a bit down here?
With CSS it would take much longer to iterate than with any other tool.
With something like WPF I do not need to know XAML by heart to quickly create some reasonable working mockups for a .net application.
This explains why it is much easier to do creative mockups in another tool (I see designers who use Adobe XD quite a bit now).
When one is in the creative stage CSS is a huge hindrance.
HTML + CSS to me, even after all these years still feels like programmer art when starting from a piece of paper, while with native coding it just flows, maybe I am tainted by my game/demoscene grassroots.
Trust.
Mozilla cf Google.
This isn't really true; the committees writing the standards are primarily formed of implementers, and the implementers aren't paying anyone to write a standard they aren't going to implement in the near future. That said, the early idea-incubation committees too often end up with just a single implementer involved.
That is certainly not the case. Look at https://eev.ee/media/2020-02-css/thumbnail-grids.html#grid
Large gaps of empty space. A manual layout would pack the thumbnails much more densely.
Ah, I still remember native buttons being introduced. Good times, back when browsers could introduce features that seem so obvious in retrospect - such as spell check in text boxes. Feels like all the low-hanging fruit has been picked by now. (Or is it? Firefox's integrating a password manager feels pretty similar.)
Great overview, though. I feel like my history with the web has been almost the same as the author's, and this brought back a lot of good and not-so-good memories.
https://caniuse.com/#search=houdini
- External editor for textbox input
- Save form data to a local disk file
- Recall form data from a disk file (on the same or a different webpage than it was saved from)
- Replace scripts in the document
- Document/application mode switch
- Disable rich text editing
- Specify a remote filename when uploading files using forms
You might be interested in https://decentraleyes.org/
I consider this the biggest loss in that transition.
It’s not browsers but poorly-designed JavaScript: if you use a standard HTML form all browsers will preserve state and resubmit it for you on retries. The problem is when you have JavaScript altering the form but not reimplementing the standard state management, and since few sites do more than casual testing these days it tends to require a number of user reports before that’s prioritized since it’s so easy for lazy developers to blame the error condition rather than accept that handling it is part of the job.
(Just though of another example: Picture in Picture video playback, like Firefox recently added and Chrome and Safari have technically already had for a while.)
They’re back now for mobile with react and ionic. In a weird what comes around way.
I still remember that weird bug that forced everyone to create a single, empty, invisible DIV at the beginning of the page if you wanted to set absolute positions for the other DIVs in the page.
In Javascript land, we all had our little script to detect the browser and do things like finding the element you wanted (IIRC, only IE had find by id).
All in all, I miss the carefulness webdevs had to have at the time (I remember uglifying my files by hand to make everything weight less than 24KB, which was the self-imposed limit we had at the dotcom I worked at) but, in general, I don't miss those days at all.
I heard about Flash games archival efforts a while ago, so I wonder what became of that (and if they included weird websites in their efforts too).
I remember a magazine I had that was full of crazy flash sites. I recently fondly remembered Fly Guy (still works in Firefox!)
https://web.archive.org/web/20050317021634/http://www.trevor...
But newspaper-style columns are not as useful on the web, since it is really annoying if the columns are longer then the screen and you have to scroll up and down. In that respect the web is very different than newspaper layouts where the dimensions are fixed.
As for <grid>, layout should be specified in CSS rather than through the html element, which is why we have "display: table", "display: grid" etc. in CSS, which should do what you want.
They had the ability to parallel install all along, eliminating the need for updates as part of huge Windows updates: https://news.ycombinator.com/item?id=20495979
A misleading phrase that means something completely different to a newer generation...
Well, no. Nothing wrong at all with tables.
There are HTML tables, created with the <table> tag, and then there are CSS layout tables created with the "display:table" property. Neither are inherently good or bad, it is just a question of when they are appropriate.
The problem with tables back in the day was that browsers didn't support "display:table", so the only way to get a grid-like layout was to use the <table>-tag. In cases when the content wasn't semantically a table, you had a dilemma. Either you would have to abuse the <table> tag thereby hurting accessibility, or you would have to use CSS floats and hacks to achieve the desired grid-like effect. Neither was really desirable.
Today we have "display:table", but we also have flexbox and grid which is are much more powerful, so the use of tables-for-layout are mostly irrelevant.
Internet Explorer on Windows was the singular offender. ISTR that other ones with at least 0.7% market share were implementing the display property correctly.
A desirable solution was to just paper over the bugs and other shortcomings with Javascript: https://github.com/seancoyne/ie7-js
That way one could simply write standard compliant code and not waste any time with hacks and float work-arounds.
If you have text that's laid out with a fixed number of columns and a dynamic number of rows, than what you have is exactly a table.
Absolutely no reason to get your underwear in a bunch in a rage of hipster semantic pseudo-purity just because it's not literally a table of Excel figures.
Are there any more articles like this? I'd read them all day.
By telling the story of science and math, we gained the context of who did what for what reasons. Which unlocked my understanding of science and math in a way that textbooks never did.
(Interestingly, the historical context could also pre-empt much of the criticism of "the modern web", or lamenting about not every browser building on Chromium.)
https://medium.com/the-node-js-collection/modern-javascript-...
Helped me understand the how and why of webpack.
There is SO MUCH we simply don't think about anymore because the tools do the thinking for us, like CSS prefixing mentioned in the article. I can't remember the last time I manually prefixed a CSS property, I've used tools that have autoprefixing built in since 2015. I just don't think about it anymore. Nor the differences between ES3, ES5, ES2015, ES2017 or a host of other things.
This means my brain is free to spend that energy in other places and that's absolutely a godsend for productivity.
https://www.wiumlie.no/2006/phd/
https://www.marvel.com/captainmarvel/