Last night, I vented out my frustration on <link> requiring href to point to a CSS stylesheet instead of src.
I will share the help I received and the history provided by wonderful folks, Vuild, Brendan Eich (creator of JavaScript), and Håkon Wium Lie (creator of CSS) on Twitter.
TL;DR
href resources are loaded based on a trigger while src resources are loaded automatically.
Not 100% accurate because CSS files get loaded automatically.
The confusion between href and src is due to a historical reason in early web standards era.
Difference between “href” & “src”
Vuild replied that src is for a request while href is for a link to a resource.
Being unable to grasp the difference, I replied that “CSS” is a request to download/parse/apply, it should be using src. As Vuild felt the same way, and he requested Brendan Eich, and Håkon Wium Lie for help.
Brendan Eich kindly replied that src is for “auto inclusion” while href‘ed resources are loaded after an action occurs.
But as for CSS, he agreed that href for CSS “seems[ed] inconsistent“.
link href
Håkon Wium Lie kindly provided the history (how) and the rationale (why) behind it.
The rationale was because the “HTML2 specification said so”.
“There we have it, HTML2 spec.” (Vuild took words out of my mouth😀).
Note that it’s the HTML2 spec not XHTML2.
img src
And then Håkon followed up with how and why img uses src.
img.src was proposed by Marc Andreessen and Sir Tim Berners-Lee (inventor of World Wide Web) favored using an anchor tag with href!
As you can see it’s more “convenient” to use img.src thus that’s what’s implemented.
There you have it. The convenience factor has won over. 😃
Additional History – HTTP Referer
After sharing the Twitter thread in useReactNYC (a React Meetup in NYC) slack workspace, Donavon (one of the useReactNYC hosts and an active React community educator who loves to {… 💖}) has shared a link on how an HTTP header referer (note it’s not spelled as “referrer”, missing one “r”) misspelling came about.
SPOILER : An old spell checker didn’t catch it.
Parting Words
Many thanks to Vuild, Brendan Eich, and Håkon Wium Lie for the help and the hi/story.
It was a great experience as they spared their time to teach and share the experience.
You can check out the original thread (but be warned, it has many branches and thus could be hard to follow 😉).
The post “href” vs. “src” in HTML appeared first on Sung's Technical Blog.
Top comments (39)
I wish.
I wish html import was still a thing as well.
Why is this not a thing yet??? 🤦♂️🤦♂️🤦♂️
There are a lot of other head elements that follow <link rel= like pingback & profile etc.
I prefer not to have "style src" as well.
Yeah, I suppose you're correct there. It does seem to be consistent with the convention of
<head>elements. I guess it's not entirely as inconsistent as I first thought it was.Yeah, it seems elegant at first glance but would be more error prone.
I'd suggest removing type='text/css' but I know there will be a specific reason to keep it.
I'd say it's probably there for the sake of completeness.
I guess originally it was a declaration for the early browsers as you could probably deliver other things. We should send @dance2die to figure it out.. 🤣
I am actually for the new
<style src>and thus I will let you two further pursue that topic 😉
Why? (serious-ish).
Also, find me a similar question on TCP/IP.
I am for
<style src>because HTML should be easy for devs to specify what we want to display (not focus on the browser only).As @somedood mentioned, it's not intuitive (initially at least).
It take us off from our train of thoughts (lowering productivity).
Markup should be simple enough that we don't have to worry about a possible "specific reason to keep it" but let us focus on getting things done.
I find
<style src>more readable as you don't have to glance over verbose info such astext/cssorrel=stylesheet(refer toimg.srcvs Tim Berners-Lee's anchor version).That's why I am for
<style src>as it makes it easy to remember more readable - thus make us focus on telling the browser what we want to showThat means learning two things at the beginning. How <style src works & how <link ref works.
Seems more complex. There is no need for more than one or two stylesheets so a whole tag seems like overkill.
Look at my head, it has loads of link ref already, CSS just fits right in as another line. Seems a reasonable way to handle it. You could strip "text/css" or "rel=stylesheet" as far as I am concerned (depending on what the alternate values are here).
Also, I don't want to have to start supporting more legacy like that for no improvement to the user. It has worked very well (robust) for decades.
Easy to remember for devs? Low priority. A lot of devs seem to want everything easy, but that doesn't make you better. Easier dev does not generally result in better product. Almost all focus should be on users & anything that benefits them (including where you spend your time) regardless of dev (new things are hard so dev should be hard).
When someone is sick, treating the cause of the problem (as opposed to treating the symptom) a better way.
I consider the good DX (developer experience) as treating the cause, while keeping the same old way (by enabling stripping
text/cssorrel=stylesheet) as treating the symptom.It has worked well for decades but we can make it better.
Web development has been around for decades and I believe it will so, we can make small improvements and in decades time, the DX will be better.
It's not just about the easy-to-remember part but also about readability.
Overtime, we probably might not even hand-code low-level HTML so it could be a moot point. We might as well focus on more important issues.
Improving DX would probably never provide any benefits to users directly (as refactoring your code doesn't) but it'd help improve our productivity, which gives us more time to focus on how we can benefit users.
Nobody is sick. CSS linking works more reliably than anything else.
The code is correct to match the other head elements (paste & go). Adding complexity doesn't help. It's not easier to read or learn really (learn one principle or two).
Next there will be 20 <style something we have to deal with. Meanwhile, everyone is still just making a html page with a couple of images & an input field.
There are many more important issues.
Great point.
<style src>isn't probably a good issue as it could add complexity as you mentioned.Thank you for providing interesting discussion topic because I really haven't thought about what we discussed much until today.
You can use tech to save thousands of lives easily, you can change lives substantially, you can make an immediate difference (not to show off, I have done all of these, thanks to tech).
Either you get hung up on the tiny things or you imagine tomorrow & make something for that, it doesn't have to be perfect. No utopian fallacy. Once you have saved 50 lives with your own code & saw it happen you realize it is important to 'get the job done well'. Your working with value code is the best version.
You don't have to be old or young or rich or poor, you can go out & do it immediately.
Spot on, Eugene 😀
Yw. You should probably try Brendan's browser Brave:
brave.com
creators.brave.com & verify your site, get paid in BAT crypto.
batgrowth.com growing nicely.
& Håkon's (imagine being called Hak while you hack CSS together) Opera
opera.com
👍
Wow. Brave is another product/project spearheaded by Brendan.
I wasn't aware until you brought it up.
Thanks~
Insane.
And willing to come along to give good advice to help people, small ego. One of the few people I have to read multiple times, do research to understand.
If I ask him for advice I try to always promote Brave too as it is good browser & seems like a nice way to pay back a little. I figure if we are promoting Brave, he can be giving out advice. Seems wise use of time to me.
Agreed on points described.
So just installed Brave & turned on the Reward settings :)
Nice, they give rewards for browsing, others can pay your site for reading & you can tip. 👍
Checkout brave.com/about/ most are on twitter or somewhere.
Thanks for the follow-up info 👊
This Brave browser looks very interesting, going to kick the tires and see how it goes. Thankyou @vuild for the pointer
You are welcome James.
There are a bunch more here, but people are very happy with Brave rn.
vuild.com/web-browsers
I've been using brave on mobile for a couple of years. It's great. Earlier this year,once they switched the Desktop version from Electron to Chromium, I made it my main browser for web dev. It's supports everything that Chrome does with some nice extras. 🔥
...with 2 extra hours you can waste. 👍
nice right write up!
I've always wondered this and never had the audacity to ask.
thanks for taking the time and care to chase it down!
Thank you for the kind words, Michael 😃
And I also gotta thank @vuild for starting up the "chase" 😉
I appreciate the sentiment but there is no need, really.
The history should be recorded, studied & revisited by tech people.
I just learned so much
Me too! I mean who hasn't "learned so much"
Thanks for the "so much" instead of "too much" 😉
Since linked stylesheets can be conditionally loaded (media queries) I think HREF might just be very approiate.
That's an interesting approach.
I can use that thought pattern to remember the syntax 😀
Cool lol
Very nice article. Thanks and congratulations
Fantastic read
Thanks again Joon :)