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.
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 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
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).
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.
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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.