- From: Jake Archibald <jaffathecake@gmail.com>
- Date: Sun, 7 Jul 2013 17:05:39 +0100
- To: Stu Cox <stuart.cox@gmail.com>
- Cc: www-html@w3.org
- Message-ID: <CAJ5xic9paR9Bx5YE3TLvo7z7=2HzxzSpDOmTDopkfzz6z_s6Rw@mail.gmail.com>
>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-scriptthe 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 as "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 <stuart.cox@gmail.com> wrote: > Not entirely sure if this is the right reference doc: > http://www.w3.org/TR/html-markup/script.html – but it doesn't make it > clear what should happen if both `async` and `defer` attributes are set on > a `<script>` element: > > <script src="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 this > 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 > >
Received on Sunday, 7 July 2013 16:06:07 UTC