headers
Ian Hickson | 1 Aug 2009 01:50
Picon

Re: scripts, defer, document.write and DOMContentLoaded

On Tue, 21 Jul 2009, Maciej Stachowiak wrote:
> On Jul 20, 2009, at 7:30 PM, Boris Zbarsky wrote:
> > Ian Hickson wrote:
> > > Actually what's going on is more subtle than that. When you set 
> > > innerHTML, it's actually triggering the deferred scripts right 
> > > there, if it has them loaded (e.g. inline scripts or cached 
> > > scripts). If it doesn't have them loaded yet, it drops them on the 
> > > floor and doesn't ever run them. I've specced this, except that the 
> > > spec requires that not-yet-loaded scripts be loaded then run, rather 
> > > than dropped, before innerHTML continues, so there's no race 
> > > conditions.
> > 
> > Er... wait.  So innerHTML has to block on network access?  And 
> > possibly spin the event loop as it does so?
> > 
> > This doesn't seem desirable to me.... Why do we want this behavior?
> 
> innerHTML blocking on network access seems seriously problematic to me. 
> I don't think blocking the UI is preferable to a race condition, when we 
> are talking about a compatibility quirk for content doing something 
> dubious.

I've changed the spec to do external deferred src=""ed scripts at the end 
of document load (blowing away the document as before), and inline 
deferred scripts as soon as innerHTML is set, if it is set, or else along 
with other deferred scripts at the end of document load.

On Tue, 21 Jul 2009, Boris Zbarsky wrote:
> > 
> > I don't really understand what your proposal would actually translate
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ian Hickson | 1 Aug 2009 02:07
Picon

Re: Errormessages in forms

On Tue, 21 Jul 2009, Oldřich Vetešník wrote:
> Dne Fri, 26 Jun 2009 07:17:17 +0200 Ian Hickson <ian@...> napsal/-a:
> > On Tue, 2 Dec 2008, Oldřich Vetešník wrote:
> > > Dne Tue, 02 Dec 2008 11:31:07 +0100 Ian Hickson <ian@...> napsal/-a:
> > > >
> > > > Well, in the snippet above, the following seems adequate:
> > > >   <label> Instructions <input name=idfield>
> > > >            Type in dd-mm-yyy format</label>
> > > > ...and the custom error message should be set from script, using 
> > > > addCustomValidity(). How is that not accessible? It seems fine to 
> > > > me. The AT can read the whole label when entering the field, and 
> > > > the error message handling is done by the UA.
> > > 
> > > Alright, I agree, I don't have a problem with it. But is it possible 
> > > to create a detailed documentation for this, including "How do I 
> > > code it right?," with wrong good and examples? In my opinion, if 
> > > there was a good, clear and understandable (for human regular beings 
> > > that is) documentantion which developers could refer to, and if it 
> > > succeeded in getting known widely, it could improve the overall 
> > > knowledge and accessibility. It reminds of the longdesc attribute - 
> > > it's useful but nobody really knows how to make it right.
> > 
> > I think it would be reasonable to have examples, yes.
> > 
> > I've added one for <label> similar to the above. Do you have any other 
> > areas where you would like particular examples?
> 
> Mm, maybe adding an error message would be fine - just to nail the head 
> :) <p><label>Post code: <input name=pc> <small>Format: AB12 3CD</small> 
> <span>There seems to be an error, please type the post code in the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Pieters | 1 Aug 2009 07:43
Picon
Favicon

Re: [html5] r3515 - [e] (0) Clarify 'font' serialisation.

On Sat, 01 Aug 2009 01:00:28 +0200, <whatwg@...> wrote:

> Author: ianh
> Date: 2009-07-31 16:00:26 -0700 (Fri, 31 Jul 2009)
> New Revision: 3515
>
> Modified:
>    index
>    source
> Log:
> [e] (0) Clarify 'font' serialisation.
>
> Modified: index
> ===================================================================
> --- index	2009-07-31 22:52:55 UTC (rev 3514)
> +++ index	2009-07-31 23:00:26 UTC (rev 3515)
>  <at>  <at>  -24662,8 +24662,22  <at>  <at> 
>   <p>On getting, the <code title=dom-context-2d-font><a  
> href=#dom-context-2d-font>font</a></code>
>    attribute must return the serialized form of the current font of the
> -  context. <a href=#refsCSSOM>[CSSOM]</a></p>
> +  context (with no 'line-height' component). <a  
> href=#refsCSSOM>[CSSOM]</a></p>
> +  <div class=example>
> +
> +   <p>For example, after the following statement:</p>
> +
> +   <pre>context.font = 'italic 400 12px/2 Unknown Font,  
> sans-serif';</pre>
> +
(Continue reading)

Permalink | Reply | 1 comment |
headers
Boris Zbarsky | 1 Aug 2009 07:56
Picon
Favicon

Re: scripts, defer, document.write and DOMContentLoaded

Ian Hickson wrote:
> I've changed the spec to do external deferred src=""ed scripts at the end 
> of document load (blowing away the document as before), and inline 
> deferred scripts as soon as innerHTML is set, if it is set, or else along 
> with other deferred scripts at the end of document load.

Another possible, less magic, option here is to simply not support defer 
on inline scripts.  Are there significant use cases for it?

-Boris
Permalink | Reply | 0 comments |
headers
Ian Hickson | 1 Aug 2009 10:40
Picon

Re: Audio synthesis

On Tue, 21 Jul 2009, Patrick Mueller wrote:
> 
> I've just started playing a bit with audio.  One thing I noticed with 
> both FF 3.5 and WebKit nightlies is that usage of the "loop" attribute 
> set to true does not provide seamless looping.  ie, there is a 
> significant pause between when the audio clip end is reached and when 
> the clip starts again.
> 
> The spec makes no statement on the seamless-ness of the looping.
> 
> From a practical standpoint though, having seamless looping is important 
> if you actually have audio that is designed to loop, and you'd like to 
> just allocate the resource for one loop.  Think of the background sound 
> for a game, for instance.  It also makes the trick of using a very short 
> sound clip specified in a data: url pretty much worthless, as you'd 
> presumably want to loop such a clip seamlessly.
> 
> It makes me wonder what the use of having the seamful looping actually 
> is, besides of course annoying people.  :-)

I agree that looping should be seamless, but really we can't even 
guarantee that the start of the clip will still be in RAM when you reach 
the end, so this is more a quality-of-implementation issue than a spec 
issue.

On Wed, 22 Jul 2009, Philip Jägenstedt wrote:
> 
> The spec simply says "If the media element has a loop attribute 
> specified, then seek to the earliest possible position of the media 
> resource and abort these steps." This would give seamless looping if an
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian Hickson | 1 Aug 2009 10:59
Picon

Re: Canvas.toDataURL() browser implementations

On Wed, 22 Jul 2009, OmegaJunior wrote:
> 
> Since the last implementation report for the Canvas element in HTML5
> was updated last February, I thought it wise to report that:
> 
> The Canvas.toDataURL() method was found implemented by the following browsers:
> Opera 10 beta 2 (including support for image/png and image/jpeg)
> Google Chrome 3.0 (support for required image/png, no support for
> optional image/jpeg)
> Mozilla Firefox 3.5 (including support for image/png and image/jpeg)
> 
> The Canvas.toDataURL() method  isn't implemented by Microsoft Internet
> Explorer 8.

Thanks. For what it's worth, you are in fact able to update the 
implementation report yourself. :-)

--

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Permalink | Reply | 0 comments |
headers
Ian Hickson | 1 Aug 2009 11:54
Picon

Re: Idea: Links w/o end anchors (is possible)

On Wed, 22 Jul 2009, ppj wrote:
> 
> The Goal: Links w/o anchors.                                                                                           
> The Strategy: Two stage process. 
> 1) get an extra 'search' attribute on to the <a> tag in HTML so that we
> have:                                                           
> e.g. <a href='...' search='...'>link text</a>

This is already possible using XPointer.

> 2) If there's take-up, then later on push for adding a date-time of 
> creation attribute to <a>. This will add link history to the internet.

This doesn't seem to be necessary to solve the problem you stated.

On Wed, 22 Jul 2009 Darxus@... wrote:
> 
> It seems odd to me that the definition of the id attribute doesn't 
> mention its use as a fragment identifier. 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#the-id-attribute

I've added a paragraph mentioning the uses of the id="" attribute.

On Wed, 22 Jul 2009, ppj wrote:
> 
> Folks have suggested XPointer vs. attribute hack on the <a> element. But 
> I would prefer the element to have something superficial ordinary people 
> can understand, even if behind the scenes the browser turns that into 
> XPointer.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian Hickson | 1 Aug 2009 12:18
Picon

Re: "Encoding declaration state" I hate the wording.

On Wed, 22 Jul 2009 Darxus@... wrote:
>
> This took me a while to figure out.  Please change:
> 
> 
>   4.2.5 The meta element
>   
>   Metadata content.
>   
>   Contexts in which this element may be used:
> 
>   If the charset attribute is present, or if the element is in the Encoding
>   declaration state: in a head element.
> 
>   If the http-equiv attribute is present, and the element is not in the
>   Encoding declaration state: in a head element.
> 
>   If the http-equiv attribute is present, and the element is not in the
>   Encoding declaration state: in a noscript element that is a child of a head
>   element.
> 
> 
> To:
> 
>   4.2.5 The meta element
>   
>   Metadata content.
>   
>   Contexts in which this element may be used:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian Hickson | 1 Aug 2009 22:59
Picon

Re: Web Workers and postMessage(): Questions

On Wed, 22 Jul 2009, Daniel Gredler wrote:
> 
> First, why does the structured clone algorithm used by postMessage() [1] 
> throw an exception if it encounters cycles? It seems to me that the 
> memory-based logic which is used to catch cycles could easily be 
> modified to resolve them instead. The only possible reason I can think 
> of is to match JSON semantics, and the only reason I can think of to 
> want to match JSON semantics is to make implementers lives easier 
> (witness Firefox 3.5, which just JSONifies objects passed to 
> postMessage()). However, this is a huge limitation, and I'm not sure 
> that the correct trade-off is to make implementers lives easier at the 
> expense of making web designers lives harder.

Your guess is correct. I imagine we'll lift the restriction eventually; if 
you want to make that happen quicker, then I encourage you to speak 
directly to the browser vendors implementing this, and convince them it'd 
be worth it. :-)

> Second, why not walk the prototype chain? Similar rules regarding host 
> objects and regular objects could apply to prototypes. You would want to 
> make sure that multiple references to the same prototype instance result 
> in references to a single prototype clone in the cloned object graph. 
> Again, though, it doesn't sound too hard (though I might just be 
> optimistic). Why not make web designers' lives easier?

We're definitely never going to copy function code over, so it's not clear 
that the prototype chain would be that useful. Could you elaborate on your 
use case?

> Overall, it just appears that the current web worker spec ignores the
(Continue reading)

Permalink | Reply | 7 comments |
headers
Ian Hickson | 1 Aug 2009 23:14
Picon

Re: AppCache and javascript url question?

On Wed, 22 Jul 2009, Michael Nordman wrote:
> On Sun, Jul 19, 2009 at 3:10 AM, Ian Hickson <ian@...> wrote:
> > > > >
> > > > > What appcache (if any) should the resulting iframes be 
> > > > > associated with? I think per the spec, the answer is none. Is 
> > > > > that the correct answer?
> > > > >
> > > > > <iframe name="frame1" src="javascript:parent.frameContents1()">
> > > >
> > > > If there's no manifest="", there's no application cache selected, 
> > > > as far as I can tell.
> > >
> > > In this case, the src is a script embedded in a page that is 
> > > appcached, so in a transitory sense the doc resource was loaded from 
> > > an appcache, but that cache does not get selected.
> >
> > The doc resource was not loaded from the cache, it was loaded from 
> > evaluating JavaScript.
> 
> The key phrase was "in a transitory sense". The script that was 
> evaluated was loaded from an appcache.

Not necessarily. For example, the iframe could navigate itself to a 
javascript: URL without the parent knowing about it, or some other frame 
could do it. We do have the _origin_ of the javascript: URL, but that 
doesn't include the path, so it doesn't really help us determine which 
appcache to use.

> > > Feels like maybe image.png should load from myManifestFile in the 
> > > sample?
(Continue reading)

Permalink | Reply | 0 comments |

Gmane