Eager, a startup later acquired by Cloudflare, published web technical history and developer articles such as the history of the URL and email.
Commenters call its history of the URL and the languages that almost became CSS excellent reads; other comments cover its hiring and the Cloudflare acquisition.
No doubt, at a certain point it does come down to aesthetic preference.
Using a border-bottom to achieve the look you’re describing is totally a valid preference. One potential advantage to the border-bottom technique is
the way it can be used to make a link stand out. In fact, I use this link styling on my personal website for that reason [1].
(Note: when using a border-bottom, I’d recommend using a slightly larger line-height so that the line still seems associated with the text above it and not the text below it. This is one of the pitfalls described in the original Medium post [2].)
Unfortunately, aside from iOS 8, normal text-decoration underline links have the descender crossing problem.
I absolutely took this into consideration when designing SmartUnderline. SmartUnderline literally only applies itself to links with text-decoration underline, nothing else. It even tries to ensure other conditions which make the transformation favorable (display inline, solid background color, etc.).
Ultimately I think the before-and-after on the SmartUnderline website tells the best story [3]. No doubt one may appreciate other, very different link styles. (For example, just using a different text color to denote _link_ is a perfectly valid and commonly used technique.) But if you’re using text-decoration underline already, this just makes those links look better.
I think blogs, news articles and wikis are some of the primary examples of where these links look best. Anywhere…
Hey, I‘m Adam, and I designed this page. Thank you so much for this feedback.
When building this page, I definitely struggled with what to put where. The Steps 1, 2, 3 are hopefully clear about what action to take, but I agree that more motivation at the top would be great.
Here’s the thing we believe can be made easier:
When my co-founder and I built Pace [1], Offline [2], Shepherd [3], etc. [4], one of the problems we came across was that while we could get stars on GitHub, non-developers struggled to get the benefit from these projects. Often, the step they struggled with was adding the `<script>` or `<link>` tags to their page, and configuring any of the options these apps/widgets/plugins had.
Our About page [5] explains something to this effect, but bringing some of that motivation to this landing page seems like a good place to start. Thanks again! I hope this was helpful.
Perhaps in addition to:
“Anything you can include in a <script> tag can be installed through our UI.”
We could add:
“Example: You wrote a JavaScript library which works by having the user paste a `<script>` tag in their page. With Eager, instead you users can install your library by simply clicking a button.”
[1]: http://github.hubspot.com/pace/docs/welcome
[2]: http://github.hubspot.com/offline/docs/welcome
[3]: http://github.hubspot.com/shepherd/docs/welcome
[4]: http://github.hubspot.com
[5]: https://eager.io/about
When someone says HTML & CSS is terrible I ask them to design something better that lets you represent user interfaces that can adapt across multiple screen sizes, and allow complex layouts that Flexbox and CSS Grid makes possible. It is easy to criticize something if you don't have to worry how you would do it better.
That said, HTML & CSS is just how the world currently is. It doesn't mean that it is the best possible way to do it. CSS could've been very different if not for many fortuitous events in history: https://eager.io/blog/the-languages-which-almost-were-css/
The best possible way to represent user interfaces is to represent them visually. Having to learn code to build UI is just today's limitation. While many have tried and failed to do better, this is still an open question.
Today maybe a designer must understand HTML & CSS to fully embrace the medium. But that means they have to get out of their visual thinking mode, and look at letters on a screen and interpret them in their mind's eye. As programmers we're used to it, but it doesn't mean it is the best nor the only way to do it.
So I'm all for articles like this that questions the status quo instead of accepting defeat and asking people to just get on with the program.
Straw men are not helpful. I never suggested removing a language used by millions of people. Let me be more specific: Pruning support for old formats and protocols is a feature, not a bug.
Let's pick something else from this golden age of "browsing HTML pages via the FTP protocol" that people on this thread keep professing: XBM images, the very first image format ever supported by browsers, and used when Marc Andreessen literally invented the IMG tag [0].
XBM is a crazy simple image format [1]. Yet, because it is essentially C code that defines a buffer size and then gives you a char array, caused security bugs over and over [2] in all major browsers. Since virtually no one was using XBM images, the browsers all removed support for it [3].
The browsers removed code that was already written, and abandoned functionality that had already existed, because it reduced attack surface supporting something that virtually no website was using. Exactly like FTP support.
0 - https://eager.io/blog/to-what-extent-did-marc-andreessen-invent-the-internet/
1- https://en.wikipedia.org/wiki/X_BitMap
2- https://www.cvedetails.com/google-search-results.php?q=xbm+image&sa=Search
3- https://en.wikipedia.org/wiki/X_BitMap#Support
Well, CSS is pretty old, and as such old, backwards-compatible specs do, it's utterly bloated. I tend to use CSS Grid and Flex almost exclusively, since they are a lot more intuitive than the block and inline combo.
But then again if you look at the origin of CSS, it all makes sense. CSS was never developed to be used for app-like interfaces. At it's inception, it was intended as a style sheet for documents (specifically scientific documents). The original idea was that everybody would have their own CSS which they could then apply to HTML locally. Interestingly, 30 years later, HTML and CSS are used for almost anything but scientific documents and nobody uses a personal style sheet.
The technology is really not well suited for the cases it is most often used for today and there is a superb blog post on the topic that has featured several times on HN:
The Blog Post:
https://eager.io/blog/the-languages-which-almost-were-css/
HN 4 years ago:
https://news.ycombinator.com/item?id=11994405
HN only 4 months ago:
https://news.ycombinator.com/item?id=24118151
Looking around I see lots of people just blindly using UUIDs for everything. At a prior job, I had a boss who forced me to use UUIDs for everything, before we had even collected a single row of data.
It hurts my pragmatism to solve a distributed systems problem before we even had a distributed system! Don't be a sheep and use UUIDs, rather than a simple integer primary key or composite key that is natural to the table. People say it's just an id, who cares? But I say people making these kinds of decisions are probably making other poor choices backed by something they read and don't understand.
Here's a great article on locality and the need for uniqueness and why UUIDs should only be introduced when needed and to solve very specific distributed systems problems. The reality is almost all applications will never need to have multiple concurrent writers.
https://eager.io/blog/how-long-does-an-id-need-to-be/?hn