“href” vs. “src” in HTML

Publish Date: Jul 18 '19

312 40

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.

Comments 40 total

Eugene KarataevJul 18, 2019
- Adam Crockett 🌀Jul 18, 2019
  
  I wish.
  
  I wish html import was still a thing as well.
- Sung M. KimJul 18, 2019
  
  Spot on, Eugene 😀
- Basti OrtizJul 18, 2019
  
  Why is this not a thing yet??? 🤦‍♂️🤦‍♂️🤦‍♂️
  - VuildJul 20, 2019
    
    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.
    - Basti OrtizJul 20, 2019
      
      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.
      - VuildJul 20, 2019
        
        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.
        
        Basti OrtizJul 20, 2019
        
        I'd say it's probably there for the sake of completeness.
        
        VuildJul 20, 2019
        
        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.. 🤣
        
        Sung M. KimJul 20, 2019
        
        I am actually for the new <style src>
        and thus I will let you two further pursue that topic 😉
        
        VuildJul 20, 2019
        
        Why? (serious-ish).
        
        Also, find me a similar question on TCP/IP.
        
        Sung M. KimJul 20, 2019
        
        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).
        
        I'd suggest removing type='text/css' but I know there will be a specific reason to keep it.
        
        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 as text/css or rel=stylesheet (refer to img.src vs 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 show
        
        VuildJul 20, 2019
        
        That 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).
        
        Sung M. KimJul 20, 2019
        
        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/css or rel=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.
        
        VuildJul 20, 2019
        
        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.
        
        Sung M. KimJul 20, 2019
        
        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.
        
        VuildJul 20, 2019
        
        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.
VuildJul 18, 2019

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

👍
- Sung M. KimJul 18, 2019
  
  Wow. Brave is another product/project spearheaded by Brendan.
  I wasn't aware until you brought it up.
  
  Thanks~
  - VuildJul 18, 2019
    
    Creator of JS
    
    Mozilla/Firefox
    
    Brave/BAT
    
    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.
    - Sung M. KimJul 18, 2019
      
      Agreed on points described.
      
      So just installed Brave & turned on the Reward settings :)
      - VuildJul 18, 2019
        
        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.
        
        Sung M. KimJul 18, 2019
        
        Thanks for the follow-up info 👊
        
        James McPhersonJul 21, 2019
        
        This Brave browser looks very interesting, going to kick the tires and see how it goes. Thankyou @vuild for the pointer
        
        VuildJul 21, 2019
        
        You are welcome James.
        
        There are a bunch more here, but people are very happy with Brave rn.
        
        vuild.com/web-browsers
        
        Nick TaylorJul 21, 2019
        
        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. 🔥
        
        VuildJul 21, 2019
        
        ...with 2 extra hours you can waste. 👍
kleene1Jul 18, 2019

Cool lol
chantasticJul 18, 2019

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!
- Sung M. KimJul 18, 2019
  
  Thank you for the kind words, Michael 😃
  
  And I also gotta thank @vuild for starting up the "chase" 😉
  - VuildJul 18, 2019
    
    I appreciate the sentiment but there is no need, really.
    
    The history should be recorded, studied & revisited by tech people.
Ben HalpernJul 19, 2019

I just learned so much
- Caleb AdepitanJul 19, 2019
  
  Me too! I mean who hasn't "learned so much"
  - Sung M. KimJul 19, 2019
    
    Thanks for the "so much" instead of "too much" 😉
Paulo Roberto EliasJul 19, 2019

Very nice article. Thanks and congratulations
phillipseamoreJul 19, 2019

Since linked stylesheets can be conditionally loaded (media queries) I think HREF might just be very approiate.
- Sung M. KimJul 19, 2019
  
  That's an interesting approach.
  I can use that thought pattern to remember the syntax 😀
joonDec 1, 2019

Fantastic read
- Sung M. KimDec 1, 2019
  
  Thanks again Joon :)

Add comment

Sung M. Kim @dance2die