Old CSS, New CSS
eev.ee
eev.ee
Small nitpick, XHTML does live on in one important place: epub, which is the most commonly used file type for ebooks.
I do a lot of epub work at Standard Ebooks, and at first I hated XHTML for the exact reason the article describes: A single tiny error makes the entire document invalid and it can be hard to spot it and recover. Also, namespaces were (and still are) a massive pain for little to no gain.
But over time I've come to really appreciate XHTML, again for that exact same reason. It forces you to write correct XML, and there is no possible ambiguity or multiple ways of representing a tag like there is in HTML5. `<br/>` will always be `<br/>`, not maybe `<br>` or `<br/>` or even `<br></br>`. An XHTML document from someone else will be both human-readable (after pretty-printing) and easily machine parseable. You also get xpath, which is a way of selecting elements akin to CSS but even more powerful.
Ultimately XHMTL is better suited to epub's use case, which is static documents that are written once and not dynamically generated by templating languages or libraries. Too bad there was some talk of epub switching to HTML5, though it's unlikely future revisions of epub will ever see wide adoption.
one question though, how is xpath more powerful than css for selecting elements?
X-anything nowaways is pretty unfashionable, but in principle XPath would still be useful today; bit of a shame it's falling by the wayside without decent replacement. I actively try to avoid it nowadays even though I'm comfortable with it; usually the upsides XPath has aren't worth (to me) the lack of familiarity for other devs, and the potential lack of support in various platforms compared to css.
But on the sidetrack the parent comment mentions: In any case, I can unequivocally, whole-heartedly, so-verbosely-you-hopefully-understand-my-conviction on the matter support the notion that the html5 syntax was a disaster of the highest order. XHtml is a much, much better idea, and unfortunately it died. Anybody who's ever seriously tried to compose html safely and understands all the weird gotchas that can occur (oh that wrapper p tag got auto closed because the tooltip span contained an icon and those were implemented as divs? yay!), not to mention a syntax with so many exceptions essentially 0% of web devs actually know them all is just asking for XSS issues. You think your client-side SPA can do server-side prerendering reliable? Ah, but only if it sticks to valid html: including nesting rules, because although it will work without error clientside - the dom-tree is really just a tree without as many weird exceptions - lots of DOM trees simply have no html serialization. Doesn't exist.
To be perfectly clear: I don't think XHtml was particalarly brilliant; HTML5 is simply particularly atrocious.
If I could switch to a more comprehensible data-encoding format I would, in a hearbeat - especially since nobody writes raw html anyhow nowaways, it's all frameworks and libraries. And then you pray they correctly implement the html5 spec, because if they don't... it's not something you want to reimplement yourself.
I've encountered some uses of XPath to validate the semantics of XML data models (this kind of thing still has mindshare in some places - network devices for instance https://tools.ietf.org/html/rfc7950#section-7.21.5 ) and I've come to the conclusion that wanting XPath is usually a danger sign. It's helpful for manipulating content you can't control, but that leads to people designing interfaces and models that are too difficult to work with downstream. In document display settings that manifests as a content vs. presentation mentality where you have to write byzantine queries to wrestle data into reasonable output. In configuration use cases I've seen it lead to interfaces that claim way more general edit operations than the implementation can actually pull off, as people struggle to specify XPath-based constraints to make it tractable. It's much better if at all possible to have some kind of scripted layer to do transformations than to try to manipulate a general presentable-cum-semantic data tree.
On the XHTML vs HTML5 side, React at least does a good job warning you if you're trying to render something that violates DOM nesting (out of necessity as much as anything, since it will need to operate on the generated tree).
Why? Because of switching to HTML5 (if that indeed happens) or any future revision at all won't see wide adoption? If the latter then what's the reason according to you? Amazon's dominance?
That's backwards. Relying on software to assign random meaning to broken input is never a good solution to anything, neither for static documents nor for dynamically generated documents. It's just that HTML allows you to get away with it, kindof (i.e., no scary error messages, just subtle breakage everywhere), which is why people built templating systems that didn't bother with correctness either. If the web had been XHTML from the beginning, templating systems would have been built in a way that makes it hard to generate broken documents in the first place, because the error messages would have created the incentive to do so, thus avoiding a lot of the subtle breakage as well.
The web is (was?) essentially a libertarian wild dream of unregulated evolution for a long time.
The question is not if we took a suboptimal path in this evolution, but if there was a better way to define the process.
This is not to argue anything, if the web had started with XHTML maybe it would be better or maybe it would be worse.
The problem is introducing stricter rules which breaks existing content.
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.
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.
I also remember that centering any block element within another block element with CSS was somewhat absurd. The trick was to do something like
.centered { margin-left: auto; margin-right: auto; }
And of course, there was no way to vertically center an element within another without hacks and HTML detritus that served no semantic purpose. It was almost worse than the table-based layouts.
That's the only other painful thing I vividly remember behind what Eevee posted.
Flexbox and Grid have made things a lot better, but I still run into weird inconsistencies and exceptions frequently. (The latest involved trying to set `max-height` on a `resize: vertical` element, and I couldn't get it to work without hacks or JavaScript. Chrome implements resizing by overriding the width or height on an element's style attribute.)
Wonderful post! Would love to see more.
But that said Flex still very much classic CSS: the awkward naming schemes, the excessive options for each parameter, the mixing of different options available, etc... it's still very much CSS in all it's quirky dirtiness.
CSS Grids kind of shocked me that they weren't entirely convoluted.
Maybe it's the design-by-committee stuff but even as CSS has gotten better: it still took way too long and it's still very weird. Maybe like JS this will slowly no longer become true, but I'm kind of happy I grew up without Flex/modern CSS because I'm unafraid of that quirkiness.
LOL, I particularly love the breakdown of Space Jam. Oddly enough, I very briefly considered breaking out an old-school imagemap, like, a month ago. I was trying to get one of those lightbox-style image galleries to work, including a clickable area on the side of each image to get to the next one, and I couldn't figure out how to do all the weird border-padding-whatever-else unholy CSS witchcraft to get the clickable areas aligned correctly with the images. Imagemaps may actually work better than the hacked-together solution I eventually came up with...
Definitely for forms, but for static content? Our design sensibilities weren't there--we were too busy adding animated gifs and blink--but the tech was. Look at a post on Medium. A lot of that style could have been done in 1998.
i.e. In notepad using <table> to control the layout.
I never learnt CSS at some-point I should learn it but I work with html so infrequently I never bothered. My "notepad html" is more than enough for anything I've had to do in last two decades.
edit. One thing I do miss is being able to hit view source in browser and understand everything, nowadays all javascript.
I'm glad you all like it, though.
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.
- 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.
Unfortunately following an incident with a broken Lisp machine, a liquid lunch, and an unlicensed particle accelerator, I became trapped in a parallel universe where the HTML ERB anointed CSS by mistake during a drunken night out in Oslo.
The fundamental concept of CSS (best revealed by H.W.Lie's thesis IMO[1]) was to create a rich and versatile and non-Turing-complete set of structural selectors in lieu of DSSSL's recursive logic, and to allow styles to overlay one another; two design choices that only by the application of gallons of irony can explain why most web pages are composed of a bunch of nested DIV elements with hashed IDs and overloaded semantic class attributes, and everyone compiles their assets into a static file.
I switched to Tailwind CSS months ago. Adam Wathan is the hero we deserve.
Probably best to read https://adamwathan.me/css-utility-classes-and-separation-of-... which does a much better job of explaining the motivations, and the conceptual journey of its creator, than I ever could.
Many folks (not all, but many, I'd even venture to say ... most) have a four step reaction to Tailwind:
1. That is the stupidest webdev idea I ever heard, and I've heard a lot. // 2. Fine, I'm trying it because everyone else keeps prompting me to and/or its creator seems competent. // 3. This is weird but actually quite helpful and totally not what I expected. // 4. You have ruined me for any other CSS framework and I never want to use anything else.
All CSS is crap. Tailwind is (in my experience and opinion) the least crap and most productive approach yet.
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.
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..
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.
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.
Back in 04 I wrote some forum software with XmlHttpRequest back before gmail was released. The everybody thought I was a fucking wizard. Then gmail came out and it was like oh you did that gmail thing. Good times.
But yeah, the long slow death of IE 6, crazy stuff. God, it feels like it's been a decade since I've had to seriously think about cross browser bugs, versus that eating up half my development time. Evert time I curse mobile Safari these days I remind myself of IE 6 and calm down pretty quick ;)
And alternate articles
When the front-end work began to fork off into it's own real separate independent discipline, likely when we really achieved separation of the UI from the backend, things started to change and I ended up having to make a choice. With front-end build tools, CSS processing libraries, larger frameworks like React/Angular, I ended up on the back-end side of the equation - data platforms, databases, web services, application logic, integrations, infrastructure, etc.
Seeing this reminded me of how much fun front-end development was, even with having to deal with the annoying quirks of HTML, CSS, JS and all the browsers.
Did anybody else, like me, suddenly have a real hankering to sit down and break out all the new HTML/CSS/JS toys and start playing? :)
Happened to me last year, with the steadily-increasing annoyance at how complicated it's gotten at work - just to see how easy/difficult it would be to put together that blog I'd been thinking about for years, without using a single frontend framework.
(That blog isn't live, it got put aside for other projects in case anyone was wondering. But yeah, particularly with grid-template-area, it's not difficult at all anymore to do whatever layout you want. Even got some limited component-y goodness with inclusion templates and direct-descendant selectors.)
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
This is an amazing reference. K. A. Applegate's post-series Animorphs site, hirac delest, is still online - and was originally written around this era (series ended in 2001, so its last update, if not creation, is a bit later). It has some newer stuff like CSS, but definitely check out the source here as well: http://www.hiracdelest.com/database/index_database.htm
Just with a quick scan on the main page, it has a mix of upper and lowercase tags, a "best views in" resolution, various font tags, and body tag similar to the SpaceJam one:
<body text="#CCCCCC" link="#33CCFF" vlink="#33CCFF" onload="MM_preloadImages('../images/menu-v2/over_thumb/about.jpg')">
That's Dreamweaver I think, steaming pile of crap its pages were.
Edit: actually, it was a very good IDE for writing html at the time I used it; it's wysiwyg led people to make pages that were a terrible mess under the covers though.
Yep, just trigger some trauma for me there. Had long since buried that.
>That's Dreamweaver I think, steaming pile of crap its pages were.
... seriously, this post brought up things I had long intentionally forgotten. I was one of those poor fools that fella for the WYSIWYGness of DreamWeaver
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.
In Bootstrap case, it included a grid, and other UI components (like a dropdown menu, and a modal dialog), but most importantly, it took care that the page worked the same in all major browsers of the time.
It helped me to prototype various projects over the years.
Just plain haunted.
http://positioniseverything.net/explorer.html saved me hours of debug multiple times when IE6 was the main browser around.
I don't think this is right. Firefox got a major foothold because it blocked ads.
This was right as those ads that would open 4 new windows when you closed a previous window started showing up on the web and IE6 could not handle them. It would literally kill your browsing experience and sometimes blue screen your computer. Firefox was the first mainstream browser to block pop ups out of the box and it worked.
It was annoying, but that is what I was used to. Then Firefox came and allowed to have all your browsing in the same window, without polluting the taskbar.
In my case, I clearly remember that tabs were the reason to switch into Firefox.
But boy, IE6 was painful! And i needed tabs to open pages and do something else while I wait for pages to load. That made me switch to Firefox after Opera. It wasn’t that long ago, I think 2007 sorts?
In my job now, I still try to make sure people can access my pages with as little resources as needed.
This is how I remember it: Firefox didn't block popups on its own, but they were constrained to another tab instead of a new window, which alone was a huge bonus.
One could argue that the old-school equivalent of NPM dependency hell was all the little snippets one had to copy and paste to get somewhat portable, somewhat usable sites. Except those dependencies were managed in an entirely ad hoc fashion, without any versioning or attribution.
And as the last section demonstrates, you can now write front end code that is so simple and yet flexible, maintainable and (mostly) portable.
I'll admit, I'm a pretty adamant CSS in JS supporter, but I still do use CSS at the end of the day. This post demonstrates that I still have a lot to learn about proper CSS, but more importantly, there's a gigantic amount that I no longer have to learn. Which is a testament to the progress made.
1. Apple do not have anything like the monopoly stronghold on the phone & tablet market that MS had on desktop and laptop PCs.
2. They are not (that I know of) directly using the market power that they do have to try completely block competitors. While there is no doubt some coercion going on (if you give iDevices pride of place in your store we may give you preference over others when supplies are low) there isn't the outright "stock Android and we won't give you any iDevices to sell" equivalent to MS's behaviour with regard to DRDOS/BeOS/OS2/... in the 90s.
3. They are not being deceptive about their position, like MS quietly but very deliberately scuppering DRDOS during Win3.1 development (https://en.wikipedia.org/wiki/AARD_code). Apple-land is officially a walled garden where MS were at least pretending to operate openly in a shared market.
More subjectively, whether these objective differences are enough to justify the relevant authorities not going after Apple is a matter of opinion and/or complex legal wrangling concerning the interpretation of monopoly/anti-competition/other legislation and its wording.
A misleading phrase that means something completely different to a newer generation...
Ah, I remember so many evolutions of my own websites using 336699 and 6699ff as the main colors. I still default to them even now when I just need _something_ that isn't default colors.
And wow, I forgot all about image maps! I used to stare in awe of the super artistic websites that used image maps heavily, as if I was witnessing the blackest of black magic.
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...
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
Careful cascading styles and clean and readable markup have gone straight out the window.
Since HTML5’s introduction of a bunch of new elements, I like to think markup has the potential to be a lot more readable and semantic now than it ever did when I first starting making websites in the 90s, even/especially given such a broad new range of element types.
Hello Chrome. This is why I use Firefox.
> The W3C’s solution was XML, because their solution to fucking everything in the early 2000s was XML.
Ha! Man, got that right for sure. XML/JSX is one reason I just chose to avoid React Native in favor of Flutter, I’ve this avoided XML and would like to keep that streak going.
* A two-column layout http://dionidium.com/design/leftbar/leftbar.html
* A valid XHTML 1.1 version of that layout http://dionidium.com/design/leftbar/xhtml11/
* Two-column layout with equal heights http://dionidium.com/design/column/
* My old "default styles" stylesheet http://dionidium.com/design/default.css
This was a fun read!
Speaking of shady SEO leeches, "Block pop-up windows" was a dominant preference. In my browser TenFourFox (Firefox), this "off by default" preference has moved to about:preferences > Content > Block pop-up windows. But, it doesn't matter because JavaScript has brought back the annoying popup. At least, popups are constrained within the browser window. uBlock Origin and uMatrix help to the point where some/many "modern" web pages render as a blank page.
At my first web development job in the early 2000's I did some work with SGML. I forget now what I was specifying, but I remember finding it really interesting to be able to understand DTD's. It was like seeing the DNA of HTML. I also remember the miracles to productivity that were Firebug and jQuery!
Nice write up. I also learned a couple of things I didn't know about grids too!
Get off my lawn. :)
? What is "<script/>"?
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.
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.
seems like an internet wild west
We've been laying out pages for hundreds of years. I suspect that this would be a much shorter article if Microsoft/Netscape/Opera/et.al had consulted with experts in that business first, rather than re-invent the entire process from first principles.
Won't drop any shade on TBL for this mess though. V1.0 seemed more focused on information access than design.
Actually I think the designers of CSS consulted traditional print too much, by adding confusing and useless stuff like "pt" measurements.
The Bringhurst book was published 1992. Web tech learned zero from that book.
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.
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.
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.