EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: We can't change this now because deployed content depends on this being as it is.

Do you mean that there is deployed content that depends on style not having a 'src' attribute? This addition provides the consistency which the bug author intends and is a new attribute so shouldn't affect currently deployed content.

(In reply to comment #2)
> Do you mean that there is deployed content that depends on style not having a
> 'src' attribute? This addition provides the consistency which the bug author
> intends and is a new attribute so shouldn't affect currently deployed content.

There is a lot more to it than that. Where would such content fit in the cascade? 
And how would src-attribute provided content relate to styles provided within the HTML between the tags? Legacy browsers would ignore the src attribute an use thos rules, but that's very inconsistent compared to the script element that ignores the element content if a src attribute is provided.

And then there is the issue of polyfills. To write the in a way that ensures a propwer cascading order is nigh impossible.

This is actually a quite large addition to browser parsing algotithms for no benefit except purity of style, which is not really that valuable.

We can link to external stylesheets already. Use case solved and it is not THAT hard to learn how to do it. Trust me, I teach this to newbies for a living.

(In reply to comment #3)
> There is a lot more to it than that. Where would such content fit in the
> cascade? 
> And how would src-attribute provided content relate to styles provided within
> the HTML between the tags? Legacy browsers would ignore the src attribute an
> use thos rules, but that's very inconsistent compared to the script element
> that ignores the element content if a src attribute is provided.
> 
> And then there is the issue of polyfills. To write the in a way that ensures a
> propwer cascading order is nigh impossible.
> 
> This is actually a quite large addition to browser parsing algotithms for no
> benefit except purity of style, which is not really that valuable.
> 
> We can link to external stylesheets already. Use case solved and it is not THAT
> hard to learn how to do it. Trust me, I teach this to newbies for a living.

Thanks for the clarity, i thought there might be some complexity in implementing this and with the addition of legacy browsers ignoring src references makes it practically impossible.

In a pie-in-the-sky world, i would love to see for style & scripts to use the src attribute to reference an external document but the contents of the tags to be use for over-riding the imported context, ie:

<style src="external-stylesheet.css">
    h1 { color: red; } <!-- over-ridden attribute -->
</style>


OR 

<script src="external-script.js">
    config.initParamA = "1000";
    config.initParamB = "yellow";
</script>

So that you can almost have template imports and their configuration in the same place....ahh the pie in the sky!