Re: Clarification on `async` and `defer` together

--001a11c3574c13395904e0ff0773
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 7 July 2013 17:05, Jake Archibald <[email protected]> wrote:

> From http://www.w3.org/TR/html5/scripting-1.html#script "The defer
> attribute may be specified even if the async attribute is specified, to
> cause legacy Web browsers that only support defer (and not async) to fall
> back to the defer behavior"
>
> In step 15 of http://www.w3.org/TR/html5/scripting-1.html#prepare-a-scrip=
tthe defer behaviour is only applied "If the element has a src attribute,
> and the element has a defer attribute, and the element has been flagged a=
s
> "parser-inserted", and the element does not have an async attribute", so
> the defer behaviour doesn't apply if the async attribute is present.
>
> Cheers,
> Jake
>
>
> On 7 July 2013 14:59, Stu Cox <[email protected]> wrote:
>
>> Not entirely sure if this is the right reference doc:
>> http://www.w3.org/TR/html-markup/script.html =96 but it doesn't make it
>> clear what should happen if both `async` and `defer` attributes are set =
on
>> a `<script>` element:
>>
>> <script src=3D"myscript.js" async defer>
>>
>> Browsers all seem to give `async` precedence, and I agree that this is
>> the most desirable behaviour, however logically `async` and `defer` aren=
't
>> necessarily mutually exclusive. If both were applied, it might be
>> reasonable to assume the behaviour might match that of `defer` alone.
>>
>> Could a note be added to this / any other relevant docs highlighting thi=
s
>> behaviour?
>>
>> The WHATWG spec [1] suggests this behaviour, but isn't incredibly clear
>> about it either.
>>
>>
>> [1]
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.=
html
>>
>>
>
Ok, that's clear, thanks Jake.

Maybe all that's missing is a similar comment on that working group note
then: http://www.w3.org/TR/html-markup/script.html =96 it's the first Googl=
e
search result for "w3c script async" and some other related searches.


Stu Cox

--001a11c3574c13395904e0ff0773
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
On 7 July 2013 17:05, Jake Archibald <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:[email protected]" target=3D"_blank">[email protected]</a>&gt;<=
/span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">From=A0<a href=3D"http://www.w3.org/TR/ht=
ml5/scripting-1.html#script" target=3D"_blank">http://www.w3.org/TR/html5/s=
cripting-1.html#script</a> &quot;The defer attribute may be specified even =
if the async attribute is specified, to cause legacy Web browsers that only=
 support defer (and not async) to fall back to the defer behavior&quot;<div=
>


<br></div><div>In step 15 of=A0<a href=3D"http://www.w3.org/TR/html5/script=
ing-1.html#prepare-a-script" target=3D"_blank">http://www.w3.org/TR/html5/s=
cripting-1.html#prepare-a-script</a> the defer behaviour is only applied &q=
uot;If the element has a src attribute, and the element has a defer attribu=
te, and the element has been flagged as &quot;parser-inserted&quot;, and th=
e element does not have an async attribute&quot;, so the defer behaviour do=
esn&#39;t apply if the async attribute is present.</div>


<div><br></div><div>Cheers,</div><div>Jake</div></div><div class=3D""><div =
class=3D"h5"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">=
On 7 July 2013 14:59, Stu Cox <span dir=3D"ltr">&lt;<a href=3D"mailto:stuar=
[email protected]" target=3D"_blank">[email protected]</a>&gt;</span> wrot=
e:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div>Not entirely sure if this is the rig=
ht reference doc: <a href=3D"http://www.w3.org/TR/html-markup/script.html" =
target=3D"_blank">http://www.w3.org/TR/html-markup/script.html</a> =96 but =
it doesn&#39;t make it clear what should happen if both `async` and `defer`=
 attributes are set on a `&lt;script&gt;` element:</div>




<div><br></div><div>&lt;script src=3D&quot;myscript.js&quot; async defer&gt=
;</div><div><br></div><div>Browsers all seem to give `async` precedence, an=
d I agree that this is the most desirable behaviour, however logically `asy=
nc` and `defer` aren&#39;t necessarily mutually exclusive. If both were app=
lied, it might be reasonable to assume the behaviour might match that of `d=
efer` alone.</div>




<div><br></div><div>Could a note be added to this / any other relevant docs=
 highlighting this behaviour?</div><div><br></div><div>The WHATWG spec [1] =
suggests this behaviour, but isn&#39;t incredibly clear about it either.</d=
iv>




<div><br></div><div><br></div><div>[1] <a href=3D"http://www.whatwg.org/spe=
cs/web-apps/current-work/multipage/scripting-1.html" target=3D"_blank">http=
://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html</a=
><br>




</div><div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div><div class=3D"gmail_extra" style>O=
k, that&#39;s clear, thanks Jake.</div><div class=3D"gmail_extra" style><br=
></div><div class=3D"gmail_extra" style>Maybe all that&#39;s missing is a s=
imilar comment on that working group note then: <a href=3D"http://www.w3.or=
g/TR/html-markup/script.html">http://www.w3.org/TR/html-markup/script.html<=
/a> =96 it&#39;s the first Google search result for &quot;w3c script async&=
quot; and some other related searches.</div>

<div class=3D"gmail_extra" style><br></div><div class=3D"gmail_extra" style=
><br></div><div class=3D"gmail_extra" style>Stu Cox</div><div class=3D"gmai=
l_extra" style><br></div></div>

--001a11c3574c13395904e0ff0773--