and sometimes does not, based on context, there are different contextual constraints on authoring VTT. But it's still just one format. > Thus, I suggest that a cue coming from a WebVTT file on a kind=chapter > track will be interpreted as a ChapterCue, on a kind=captions track as a > VTTCaptionsCue, and on a kind=metadata track as a MetadataCue. IMHO this doesn't make any sense. You don't create different objects for different elements in HTML based on whether the document was opened in an <iframe> or a top-level browsing context or whatever. The API doesn't, shouldn't, change based on context. It looks like I already said that, though: > > It would be like having a different DOM for an HTML file in an > > <iframe> and in a top-level browsing context. > > Contrast that to applying a different parsing and rendering algorithm > of the <iframe> depending on the parent element that it is put into, > which is what we are currently doing with WebVTTCue. No, we're parsing VTT the same in all cases. It's the conformance rules that change, and the rendering rules. Just like with HTML, where the rendering can changed e.g. based on the CSS of the page, or where the element is (e.g. an <h1> in a <body> vs one in three nested <section>s). > An alternative would be to create explicit <captiontrack>, > <descriptiontrack> etc elements, which was something that was under > discussion initially. IMHO the current state is fine as it is. > > You don't necessarily know, when parsing the WebVTT file or HTML file, > > what it's going to be used for. In the case of WebVTT, it could even > > change from one to another. > > I'd disallow changing the kind on a track. Content attributes can't be made read-only. Also, that seems artificial. Why would we do that? > >> Also, we separate out the WebVTT serialisation format syntax > >> specification from the cue syntax specification [2] and introduce > >> separate parsers [3] for the different cue syntax formats. The > >> rendering section [4] has already started distinguishing between cue > >> rendering for chapters and for captions/subtitles. This will easily > >> fit with the now separated cue syntax formats. > > > > This sounds like a lot of complication for no particularly good > > reason, but again, you're the editor. :-) > > This is work that has to be done even if we decide to only have a single > object represent all cues of a WebVTT file. No, you don't need separate parsers. There's just one parser, and the rendering rules are contextual, not based on anything about the cues. > The point of this email is to introduce a hierarchy of objects that > represent cues (or at least an agreement on when such new objects should > be created). We have a hiearchy. TextTrackCue is an abstract object that is defined in the HTML spec. VTTCue is the object used by VTT cues. I don't see any need for any others in HTML or VTT. > >> Doing this will make WebVTT and the TextTrack API extensible for new > >> cue formats, such as cues in SSML format, or ThumbnailCues, or > >> MidrollAdCues or whatnot else we may see necessary in the future. > > > > It's already plenty extensible enough. > > Right, you brought in the extensibility a few weeks ago by introducing > TextTrackCue as an abstract object and pushing all its extended > attributes into WebVTTCue, which is great. I'm just trying to come up > with the best scheme to make use of this extensibility, and I think > creating new objects makes more sense to be based on cue content than on > text track file mime type. I would recommend against using the extensibility. :-) On Mon, 17 Jun 2013, Brendan Long wrote: > > I don't think it's necessary to use the same language for authoring as > display though. Since we already have rules for rendering HTML, and > WebVTT seems to be a subset of HTML (with some special CSS rules, and > some shorthand tags), I think the easiest way to handle it would be to > translate WebVTT cues into HTML+CSS, then rely on the existing rendering > engine. VTT's rendering rules differ from basic CSS in some pretty important ways. In the ways that it is similar, it already reuses CSS infrastructure. There's not really any relationship with HTML, though. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From rniwa at apple.com Tue Sep 3 14:49:29 2013 From: rniwa at apple.com (Ryosuke Niwa) Date: Tue, 03 Sep 2013 14:49:29 -0700 Subject: [whatwg] Script preloading In-Reply-To: <alpine.DEB.2.00.1308212259080.27209@ps20323.dreamhostps.com> References: <Pine.LNX.4.64.1307091607110.24681@ps20323.dreamhostps.com> <CA+c2ei-ywCwWHNC6SfWA8CxB4XTbh=hMA3j8K0=tspwtQB3SiA@mail.gmail.com> <DDDE638B-B515-43DE-A0EB-AB20CC73FE1D@gmail.com> <CA+c2ei8pT5s+2z-xPqz5x8sn2gGZD=uGB7FH9JcddE5xOpvVag@mail.gmail.com> <E742ACB2-B2AC-4D77-B7AA-43B3625FBBE9@gmail.com> <CA+c2ei-+xCmm6gW45-s72XUjond5VF4TkwTdcY5jZ6dkZUsUuA@mail.gmail.com> <alpine.DEB.2.00.1308212259080.27209@ps20323.dreamhostps.com> Message-ID: <AD835154-3364-4FDC-B983-4167CA6271CA@apple.com> Original proposal: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-August/040664.html http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-August/040666.html In order to address use cases incDependencies and decDependencies satisfied, I'm going to add the following proposals: I make one more change that in order for a dependency specified in "needs" to be satisfied, "src" content attribute of the dependent script needs to match the value when the script finished running. e.g. myscript.src = null leaves any dependency on myscript unsatisfied. Also make "needs" IDL property take in any HTML element; e.g. adding an image element to "needs" makes the script wait until the corresponding image resource is loaded. On Aug 27, 2013, at 2:55 PM, Ian Hickson <ian at hixie.ch> wrote: > > First, let's get down to use cases. Kyle did a great job of describing > some key use cases: > > On Wed, 10 Jul 2013, Kyle Simpson wrote: >> >> [Use-case Q:] I am dynamically loading one of those social widgets that, >> upon load, automatically scans a page and renders social buttons. I need >> to be able to preload that script so it's ready to execute, but decide >> when I want it to run against the page. I don't want to wait for true >> on-demand loading, like when my user clicks a button, because of the >> loading delay that will be visible to the user, so I want to pre-load >> that script and have it waiting, ready at a moment's notice to say "it's >> ok to execute, do it now! now! now!". <script id="social" src="social-button.js" prefetch></script> <button onmouseover="document.scripts.social.execute()"> ... </button> >> [Use-case S:] One CMS plugin wants to load "A.js" and "B.js", where B >> relies on A. Both need to load in parallel (for performance), but A must >> execute before B executes. I don't control A and B, so changing them is >> not an option. This CMS plugin [wants] to wait for some >> user-interaction, such as a button click, before executing the code. We >> don't want there to be any big network-loading delay visible to the user >> between their click of the button and the running of that plugin's code. // CMS plugin 1 var A = E('script', { src: 'A.js', prefetch: true }); var B = E('script', { src: 'B.js', needs: 'A.js', prefetch: true }); document.body.append(A, B); function sawUserInteraction() { B.execute(); }; >> Another CMS plugin on this same page wants to load "A.js", "C.js", and >> "D.js". This plugin doesn't know or care that the other plugin also >> requests "A.js". It doesn't know if there is a script element in the >> page requesting it or not, and it doesn't want to looking for it. It >> just wants to ask for A as a pre-requisite to C and D. But C and D have >> no dependency on each other, only a shared dependency on A. C and D >> should be free to run ASAP (in whichever order), assuming that A has >> already run [once] some user-interaction that initiates the load of A, >> C, and D. This user interaction may be before the other plugin requested >> A, or after it requested A. // CMS plugin 2 var A = E('script', { src: 'A.js', prefetch: true }); var C = E('script', { src: 'C.js', needs: 'A.js', prefetch: true }); var D = E('script', { src: 'D.js', needs: 'A.js', prefetch: true }); document.body.append(A, C, D); function sawUserInteraction() { C.execute(); D.execute(); }; >> "A.js" can be requested relatively (via a <base> tag or just relative to >> document root) or absolutely, or it might be requested with the >> leading-// protocol-relative from, taking on whatever http or https >> protocol the page has, whereas other references to it may specify the >> prototcol. >> >> These plugins can't guarantee what ID's or classes they use are reliably >> unique without undue processing burden. > > [I've trimmed the text Kyle wrote here, but also implicit in his > description, as I understood it, was that A.js should only run once even > if both plugins tried to load it.] > >> [Use-case T:] I have two different calendar widgets. I want to pop one >> of them up when a user clicks a button. The user may never click the >> button, in which case I don't want the calendar widget to have ever >> executed to render. [...] <script id=calA src="a.js" prefetch></script> <script id=calB src="b.js" prefetch></script> <script> function showCalendar(which) { if (which == 'a') document.scripts.calA.execute(); else document.scripts.calB.execute(); } </script> Neither Ian's nor my proposal fallbacks gracefully here :( >> [Use-case U:] I have a set of script "A.js", "B.js", and "C.js". B >> relies on A, and C relies on B. So they need to execute strictly in that >> order. [Now], imagine they progressively render different parts of a >> widget. [...] I only want to execute A, B and C once all 3 are preloaded >> and ready to go. It's [...] about minimizing delays between them, for >> performance PERCEPTION. >> >> [For example, one of them might start playing a video, and another might >> introduce the <canvas> slides for that video. You want all of the >> relevant scripts to be run at once, so there's no point where the page >> has a <video> element but doesn't have the <canvas>.] <script src="A.js" prefetch></script> <script src="B.js" prefetch needs="A.js"></script> <script id=c src="C.js" prefetch needs="B.js"></script> <script> // when we need it... document.scripts.c.execute(); </script> > On Thu, 11 Jul 2013, Kyle Simpson wrote: >> >> [Use-case V:] you have a string of scripts ("A.js", "B.js", and "C.js") >> loading which constitute a dependency chain. A must run before B, which >> must run before C. However, if you detect an error in loading, you stop >> the rest of the executions (and preferably loading too!), since clearly >> dependencies will fail for further scripts, and the errors will just >> unnecessarily clutter the developer console log making it harder to >> debug. <script src="A.js" prefetch></script> <script src="B.js" prefetch needs="A.js"></script> <script id=c src="C.js" prefetch needs="B.js"></script> <script> onerror = function (message, source, lineno, colno, error) { // report error } // when we need it... document.scripts.c.execute(); </script> >> [Use-case W:] some developers have even requested to be able to stop the >> chain and prevent further executions if the script loads, but there's >> some compile-time syntax error or run-time error that happens during the >> execution. For them, it's not enough for B to simply finish loading >> successfully, but that it must fully execute without error. <script id=a src="A.js" whenneeded></script> <script src="B.js" whenneeded needs="A.js"></script> <script id=c src="C.js" whenneeded needs="B.js"></script> <script> function onAfailedToInitialize() { document.scripts.a.src = null; } // when we need it... document.scripts.c.execute(); </script> > On Sun, 14 Jul 2013, Kornel Lesi?ski wrote (trimmed): >> >> [Use-case X:] not all dependencies are JS files, e.g. authors use >> plugins to load template files, JSON, images, etc. <script src="deps.js" async></script> <script src="build.js" needs="deps.js"></script> // in deps.js: var me = document.currentScript; var image = new Image(); image.src = 'image.png'; currentScript.needs.add(image); >> [Use-case Y:] not all dependencies are usefully satisfied immediately >> after their JS file is loaded, e.g. some libraries may need asynchronous >> initialization. I don't intend to address use case but we could make it so that script element without src is an indefinite dependency as in: <script src="slowLoad.js" async></script> <script src="next.js" needs="slowLoad.js"></script> // in slowLoad.js: var me = document.currentScript; var dummyScript = document.createElement('script'); me.needs.add(dummyScript); me.incDependencies(); setTimeout(init, 1000); function init() { // ok, we're ready me.needs.remove(dummyScript); } >> [Use-case Z:] Another common kind of dependency scripts have is presence >> of certain element in the DOM, e.g. `dropdown-menu.js` may require `<nav >> id="menu">` to be in the document _and_ have its content fully parsed >> before the script can run. I guess we can somehow make needs.add take an id as well as a script name and a node? Or add a method like requireElementWithId as in: <script src="navi.js" async></script> // in nav.js: document.currentScript.requireElementWithId('menu'); - R. Niwa From silviapfeiffer1 at gmail.com Tue Sep 3 15:01:16 2013 From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer) Date: Wed, 4 Sep 2013 08:01:16 +1000 Subject: [whatwg] Reconsidering how we deal with text track cues In-Reply-To: <alpine.DEB.2.00.1309032112000.7443@ps20323.dreamhostps.com> References: <CAHp8n2mbuxm=2aOSMS2S_oa042gMkSCOMTrn5odA9+Tbpo902w@mail.gmail.com> <Pine.LNX.4.64.1306121700000.17279@ps20323.dreamhostps.com> <CAHp8n2m1AcFS3WmwwniYyz=yZZucKrhzPoTu=eCOPd57jav+Og@mail.gmail.com> <51BFCCA6.4080208@brendanlong.com> <CAHp8n2nBcRZV5mW3+wA2f=pBifF1rCd-T5+_BQLQ9mv4rhGkxQ@mail.gmail.com> <alpine.DEB.2.00.1309032112000.7443@ps20323.dreamhostps.com> Message-ID: <CAHp8n2kO7F_rDXQRrREFcB=L4_+TuvanNDkLC7W51JJasHYKmw@mail.gmail.com> On Wed, Sep 4, 2013 at 7:38 AM, Ian Hickson <ian at hixie.ch> wrote: > On Mon, 17 Jun 2013, Silvia Pfeiffer wrote: >> On Thu, Jun 13, 2013 at 3:08 AM, Ian Hickson <ian at hixie.ch> wrote: >> > On Wed, 12 Jun 2013, Silvia Pfeiffer wrote: >> >> >> >> As we continue to evolve the functionality of text tracks, we will >> >> introduce more complex other structured content into cues and we will >> >> want browsers to parse and interpret them. >> > >> > I think it's a mistake to try to solve problems before they exist. We >> > don't know exactly what we'll be adding in the future, so we don't >> > know what we'll need yet. >> >> I'm preparing to start specifying how to render chapters. There's >> already been mention of need for a thumbnail image in chapters. >> >> I'll also have to specify how to "render" descriptions. Since the target >> audience are blind and vision-impaired users, there will be a rendering >> algorithm that includes speech synthesis. >> >> This is a problem I have to deal with now. > > I don't think the problems you describe here require any changes to the > API or to the format, but maybe I'm missing something. (Images for > chapters would, I guess, if you're not using the images from the video > file, but why wouldn't you use those actual images?) It's possible that the chapter track author wants to use other images. The images in DVD chapters aren't always from the video either. Also, if you have a audio-only src in the <video> element, but you want to provide images for chapter navigation, then you'd provide them in the WebVTT file, probably as dataURLs. I've seen that done before. >> >> For example, I expect that once we have support for speech synthesis >> >> in browsers [1], cues of kind descriptions will be voiced by speech >> >> synthesis, and eventually we want to influence that speech synthesis >> >> with markup (possibly a subpart of SSML [2] or some other simpler >> >> markup that influences prosody). >> > >> > I think it's highly unlikely that we'll actually ever want that, but >> > if we ever do, then we should fix the problem then. >> >> Rendering description cues with speech synthesis is 100% something that >> is coming. Richer markup of description cues is then just the logical >> next step - it won't be required now, but is certainly on the roadmap. >> How likely it will be to be SSML is unclear - I'd much prefer a simpler >> markup for WebVTT, too. > > I'm not even remotely convinced that speech synthesis in description cues > needs any markup, let alone markup more elaborate than VTT already has. That would be good. I've been told though that synthesised speech does not convey enough prosodic and emotional content and that markup would help with that (see http://en.wikipedia.org/wiki/Speech_synthesis#Prosodics_and_emotional_content). Not a top priority though. >> >> What we have done with WebVTT is actually two-fold: >> >> 1. we have created a file format that serializes arbitrary content >> >> that is time-synchronized with a media element. >> >> 2. and we have created a simple caption/subtitle cue format. >> >> >> >> That both are called "WebVTT" is the cause of a lot of confusion and not >> >> a good design approach. >> > >> > I think it's a mistake to view these as distinct. It's just one format. >> > But as you're that spec's editor, that's your choice. :-) >> >> We've actually done more - we also have a chapter and a metadata cue format: >> http://dev.w3.org/html5/webvtt/#dfn-webvtt-cue >> >> "WebVTT chapter title text is syntactically a subset of WebVTT cue >> text, and WebVTT cue text is syntactically a subset of WebVTT metadata >> text. Conformance checkers, when validating WebVTT files, may offer to >> restrict all cues to only having WebVTT chapter title text or WebVTT >> cue text as their cue payload; WebVTT metadata text cues are only >> useful for scripted applications (using the metadata text track >> kind)." >> >> They are already hierarchically defined upon each other (already when >> you were the editor). >> >> They just aren't represented in objects in this way. > > I don't think the way you're viewing it is the right way to view it. IMHO > there's just one format, it just can be used in various ways, just like > HTML can be used for applications and documents and games, etc. Just like > how HTML sometimes requires a <title> and sometimes does not, based on > context, there are different contextual constraints on authoring VTT. But > it's still just one format. I've followed that view (you might have seen such a message on the W3C list). I'm expecting it will lead to interesting consequences, such as hyperlinks and dataURLs becoming part of WebVTT cue markup. But it is likely the easier route. Cheers, Silvia. From ian at hixie.ch Tue Sep 3 16:13:59 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 3 Sep 2013 23:13:59 +0000 (UTC) Subject: [whatwg] Challenging canvas.supportsContext In-Reply-To: <CAJTmd9q-eH8fnZSP5mr3kX-quyQcNXnyXTh5o_hX+MdfuXfrGQ@mail.gmail.com> References: <CAJTmd9rkwsjC+WDfLr7um0=h8Pvtg9JOJCRHzH4PhdbXjgpaaA@mail.gmail.com> <CAJTmd9q-eH8fnZSP5mr3kX-quyQcNXnyXTh5o_hX+MdfuXfrGQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309032240300.7443@ps20323.dreamhostps.com> The long and short of this is that I renamed "supportsContext()" to "probablySupportsContext()". It's already implemented in WebKit (and dino says he's going to rename it in the implementation also). Fundamentally, it addresses a need that none of the other proposals addressed: how to know whether or not you can expect to be able to do 3D. It's not 100% reliable, but then neither would actually attempting to create a context, because creating a context is so expensive on some platforms that some UAs are going to move to doing it lazily and so you're back to exactly the same level of reliability as this API. Plus, it'd be a lot more awkward as an API. On Wed, 19 Jun 2013, Benoit Jacob wrote: > > I'd like to question the usefulness of canvas.supportsContext. I tried to > think of an actual application use case for it, and couldn't find one. The use case is libraries like Modernizr that want to do feature detection up-front, but don't want a high performance hit on startup. > However, that only shifts the question to: what is the reason for them > to expose such APIs? In the end, I claim that the only thing that we > should recognize as a reason to add a feature to the HTML spec, is > *application* use cases. Oh well the use case for knowing whether or not 3D is supported on a particular device is straight-forward: you want to know which set of assets and logic to download and run. > So let's look at the naive application usage pattern for supportsContext: > > if (canvas.supportsContext("webgl")) { > context = canvas.getContext("webgl"); > } > > The problem is that the same can be achieved with just the getContext > call, and checking whether it succeeded. Suppose you have an app that has a 3D feature, but it's not immediately used upon startup. For example, a preview window that is displayed on request. You want to preload all the code to run the preview window, but you need to load different code based on whether the device can do 3D or not. So the use case is more: if (canvas.supportsContext("webgl")) load3DCode(); else load2DCode(); // 3D code: function run() { context = canvas.getContext("webgl"); // ... } You don't want to pay the cost of creating a throw-away 3D context on startup just to know which scripts to load. It defeats the whole point of not loading all the code up-front. > Outside of exceptional cases (out of memory...), the slow path in > getContext is the *success* case, and again, in that case a real > application would want to actually *use* that context. Not necessarily, as noted above. The <canvas> you're going to draw to might not even exist at the point you need to know if it's 3D or not. > Keep in mind that supportsContext can't guarantee that if it returns true, > then a subsequent getContext will succeed. Sure. getContext() can't guarantee that if it returns a context, the context will work forever, either. > The spec doesn't require it to, either. So if the existence of > supportsContext misleads application developers into no longer checking > for getContext failures, then we'll just have rendered canvas-using > applications a little bit more fragile. That's a risk, yes. > Another problem with supportsContext is that it's untestable, at least > when it returns true; it is spec-compliant to just implement it as > returning whether the JS interface for the required canvas context > exists, which is quite useless. That would indeed be useless. > Given such deep problems, I think that the usefulness bar for accepting > supportsContext into the spec should be quite high. The problem is that there's no alternative solution. On Wed, 19 Jun 2013, Tab Atkins Jr. wrote: > > This is missing the point. You don't want to wait until it's actually > time to create the context. Unless you torture your code flow, by the > time you're creating a context you should already know that the context > is supported. The knowledge of which context to use is most useful well > before that, when you're first entering the app. > > Plus, it doesn't matter how late you do the detection - if you do a > straight *detection* at all rather than an initialization (that is, if > you throw away the context you've just created for testing), you'll > still incur the start-up costs of spinning up a context. Doing that > early or late doesn't matter too much - it's bad either way. Indeed. > Like @supports, the supportsContext() method can be easy and reliable > with a very simple definition for "supports" - it returns true if > calling getContext() with the same arguments would return a context > rather than erroring, and false otherwise. No capacity for lying there > without breaking sites. At least, no capacity beyond the same one that getContext() has in the first place, namely that it might return a useful object that later stops working. On Wed, 19 Jun 2013, Kenneth Russell wrote: >> > Additionally, though, application developers wanted to be able to ask > questions like "is software rendering supported for WebGL": > > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-September/037232.html > > I think this second use case is valid. One could imagine a graphing or > charting library which would use low-power, software-rendered WebGL if > available, but otherwise would fall back to using > CanvasRenderingContext2D. Indeed. This is supported per the spec, assuming getContext() supports the relevant arguments. On Wed, 19 Jun 2013, Boris Zbarsky wrote: > > I see. For this use case, the current definition of supportsContext is > of limited utility, unless you make some assumptions about behavior that > the spec does not require.... I think what the spec requires is as close as one can get to those assumptions without requiring something that can't be implemented, no? On Wed, 19 Jun 2013, James Robinson wrote: > > What would a page using Modernizr (or other library) to feature detect > WebGL do if the supportsContext('webgl') call succeeds but the later > getContext('webgl') call fails? Presumably the same as if the first getContext('webgl') call succeeds today, but the next getContext('webgl') call fails. On Wed, 19 Jun 2013, Kenneth Russell wrote: > > supportsContext() can give a much more accurate answer than > !!window.WebGLRenderingContext. I can only speak for Chromium, but in > that browser, it can take into account factors such as whether the GPU > sub-process was able to start, whether WebGL is blacklisted on the > current card, whether WebGL is disabled on the current domain due to > previous GPU resets, and whether WebGL initialization succeeded on any > other page. All of these checks can be done without the heavyweight > operation of actually creating an OpenGL context. Yeah, it seems to me that the cases where probablySupportsContext() would return the wrong result are not that common. On Wed, 19 Jun 2013, Kenneth Russell wrote: > > Any application which has a complex set of fallback paths. For example, > > - Preference 1: supportsContext('webgl', { softwareRendered: true }) > - Preference 2: supportsContext('2d', { gpuAccelerated: true }) > - Preference 3: supportsContext('webgl', { softwareRendered: false }) > - Fallback: 2D canvas > > I agree that ideally, if supportsContext returns true then -- without > any other state changes that might affect supportsContext's result -- > getContext should return a valid rendering context. It's simply > impossible to guarantee this correspondence 100% of the time, but if > supportsContext's spec were tightened somehow, and conformance tests > were added which asserted consistent results between supportsContext and > getContext, would that address your concern? If there's a way to tighten up the requirements in the spec, please do let me know. I'm not sure what more to say there right now. On Wed, 19 Jun 2013, Tab Atkins Jr. wrote: > > It seems like this falls into the canPlayType() bucket, where you can > definitely give negatives, but your positives are at best hopeful. Maybe > we should just have it do the same thing, and return "maybe" or > "probably" rather than a boolean true? I renamed the method to try to make this clearer. On Wed, 19 Jun 2013, James Robinson wrote: > > var ctx = canvas.getContext('webgl', { 'allowSoftware': false}); > if (ctx) { > doPreference1(ctx); > return; > } > ctx = canvas.getContext('2d', {'allowSoftware': false}); > if (ctx) { > doPreference2(ctx); > // etc > > how could I simplify this code using supportsContext() ? "doPreference1()" and friends here are most likely to be "fetch the code, create the <canvas>es, create the contexts", etc. Getting the context from the feature test all the way to where it is first used seems like a lot of complexity. > It seems overwhelmingly likely that one of the state changes that might > affect the result will be attempting to instantiate a real context. Can you elaborate on this? > I don't see how supportsContext() could be as accurate as getContext() > without doing all of the work getContext() does. If it's not 100% > accurate, when is it useful? getContext() isn't 100% accurate either, and it's more expensive. On Wed, 19 Jun 2013, Benoit Jacob wrote: > > In Mozilla code, we fail WebGL context creation if any GL error occurs > during initialization, where we have to make a number of specific OpenGL > calls (e.g. querying many constants, enabling point sprites...). So it > is perfectly possible for WebGL specifically to fail on a given device > where OpenGL compositing works, without being specifically blacklisted, > and currently we can rely on these automatic checks rather than having > to curate a blacklist for these problems, which is very nice. You could bring these tests forward in the implementation, so that probablySupportsContext() itself doesn't have to do them, right? > Another way in which WebGL specifically can fail, is that some driver > bugs cause errors that we may want to ignore in our compositor code but > not in WebGL. To give an example, on many Vivante GPU drivers, which are > very common in Chinese mobile devices, the first eglMakeCurrent call on > a newly created context can return false without any actual EGL error > [1]. A browser may want to ignore this error in its compositor to be > able to run nonetheless on such devices, but without WebGL support. Wouldn't you know this before the call to getContext(), though? On Thu, 20 Jun 2013, Boris Zbarsky wrote: > On 6/19/13 6:04 PM, Kenneth Russell wrote: > > supportsContext() can give a much more accurate answer than > > !!window.WebGLRenderingContext. I can only speak for Chromium, but in > > that browser, it can take into account factors such as whether the GPU > > sub-process was able to start, whether WebGL is blacklisted on the > > current card, whether WebGL is disabled on the current domain due to > > previous GPU resets, and whether WebGL initialization succeeded on any > > other page. > > window.WebGLRenderingContext can take things like that into account too, > in Gecko. For what it's worth. Wouldn't checking for window.WebGLRenderingContext be just as unreliable then? I don't understand why it's ok to be able to test that, but why probablySupportsContext() wouldn't be ok. On Wed, 19 Jun 2013, Paul Irish wrote: > > On the Modernizr side, an old version did indeed create a context for > feature detection. For the past two years we have advocated the soft > `"WebGLRenderingContext" in window` test instead. There, of course, is > some gap between the results of that detect and how successful a > getContext call will be, but I don't have data those false positive > rates. Right, this would let you close that gap a bit. On Thu, 20 Jun 2013, Boris Zbarsky wrote: > > So that's an interesting question. Should UAs simply not have > window.WebGLRenderingContext in situations in which supportsContext > would return false? probablySupportsContext() takes arguments that affect the answer. (Also, the answer can vary over time.) On Wed, 19 Jun 2013, Boris Zbarsky wrote: > > > > Plus, it doesn't matter how late you do the detection - if you do a > > straight *detection* at all rather than an initialization (that is, if > > you throw away the context you've just created for testing) > > OK, but why are we making that assumption? I guess if people insist on > doing that, then we do in fact need something that will basically try to > guess whether getContext might succeed. Paul reported that this is common practice, for what it's worth. > > Like @supports, the supportsContext() method can be easy and reliable > > with a very simple definition for "supports" - it returns true if > > calling getContext() with the same arguments would return a context > > rather than erroring, and false otherwise. > > Just so we're clear, this is _not_ what supportsContext is specified to > do. As specced, it will return false if you know for a fact that > getContext would return null. It will return true if you think that > getContext might not return null. This means that a true return doesn't > really mean squat about what getContext will do. > > And the reason for that is that you can't tell whether getContext will > return null until you try to do it, given how getContext is specced. I'm happy to try to tighten this up if you have any suggestions. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From rniwa at apple.com Tue Sep 3 16:36:44 2013 From: rniwa at apple.com (Ryosuke Niwa) Date: Tue, 03 Sep 2013 16:36:44 -0700 Subject: [whatwg] Script preloading In-Reply-To: <AD835154-3364-4FDC-B983-4167CA6271CA@apple.com> References: <Pine.LNX.4.64.1307091607110.24681@ps20323.dreamhostps.com> <CA+c2ei-ywCwWHNC6SfWA8CxB4XTbh=hMA3j8K0=tspwtQB3SiA@mail.gmail.com> <DDDE638B-B515-43DE-A0EB-AB20CC73FE1D@gmail.com> <CA+c2ei8pT5s+2z-xPqz5x8sn2gGZD=uGB7FH9JcddE5xOpvVag@mail.gmail.com> <E742ACB2-B2AC-4D77-B7AA-43B3625FBBE9@gmail.com> <CA+c2ei-+xCmm6gW45-s72XUjond5VF4TkwTdcY5jZ6dkZUsUuA@mail.gmail.com> <alpine.DEB.2.00.1308212259080.27209@ps20323.dreamhostps.com> <AD835154-3364-4FDC-B983-4167CA6271CA@apple.com> Message-ID: <FAD2DACB-53C3-44D2-B0A9-BF3B6EB4A6AC@apple.com> Per IRC discussion, I misunderstood the timing at which these at which dependencies are executed. Now I agree it's desirable to have two values for when needed as proposed by Ian in the original e-mail. For other people following this thread's sake, a.js will execute immediately as soon as it's loaded in this example: <script src="a.js" whenneeded></script> <script id=b src="b.js" needs="a.js" whendeeded></script> // later document.scripts.b.execute(); whereas a.js doesn't get executed until b.js is loaded in this example: <script src="a.js" whenneeded=jit></script> <script id=b src="b.js" needs="a.js" whendeeded></script> // later document.scripts.b.execute(); - R. Niwa On Sep 3, 2013, at 2:49 PM, Ryosuke Niwa <rniwa at apple.com> wrote: > Original proposal: > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-August/040664.html > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-August/040666.html > > In order to address use cases incDependencies and decDependencies satisfied, I'm going to add the following proposals: > > I make one more change that in order for a dependency specified in "needs" to be satisfied, > "src" content attribute of the dependent script needs to match the value when the script finished running. > e.g. myscript.src = null leaves any dependency on myscript unsatisfied. > > Also make "needs" IDL property take in any HTML element; e.g. adding an image element to "needs" makes the script wait until the corresponding image resource is loaded. > > On Aug 27, 2013, at 2:55 PM, Ian Hickson <ian at hixie.ch> wrote: > >> >> First, let's get down to use cases. Kyle did a great job of describing >> some key use cases: >> >> On Wed, 10 Jul 2013, Kyle Simpson wrote: >>> >>> [Use-case Q:] I am dynamically loading one of those social widgets that, >>> upon load, automatically scans a page and renders social buttons. I need >>> to be able to preload that script so it's ready to execute, but decide >>> when I want it to run against the page. I don't want to wait for true >>> on-demand loading, like when my user clicks a button, because of the >>> loading delay that will be visible to the user, so I want to pre-load >>> that script and have it waiting, ready at a moment's notice to say "it's >>> ok to execute, do it now! now! now!". > > <script id="social" src="social-button.js" prefetch></script> > <button onmouseover="document.scripts.social.execute()"> ... </button> > >>> [Use-case S:] One CMS plugin wants to load "A.js" and "B.js", where B >>> relies on A. Both need to load in parallel (for performance), but A must >>> execute before B executes. I don't control A and B, so changing them is >>> not an option. This CMS plugin [wants] to wait for some >>> user-interaction, such as a button click, before executing the code. We >>> don't want there to be any big network-loading delay visible to the user >>> between their click of the button and the running of that plugin's code. > > // CMS plugin 1 > var A = E('script', { src: 'A.js', prefetch: true }); > var B = E('script', { src: 'B.js', needs: 'A.js', prefetch: true }); > document.body.append(A, B); > function sawUserInteraction() { > B.execute(); > }; > > >>> Another CMS plugin on this same page wants to load "A.js", "C.js", and >>> "D.js". This plugin doesn't know or care that the other plugin also >>> requests "A.js". It doesn't know if there is a script element in the >>> page requesting it or not, and it doesn't want to looking for it. It >>> just wants to ask for A as a pre-requisite to C and D. But C and D have >>> no dependency on each other, only a shared dependency on A. C and D >>> should be free to run ASAP (in whichever order), assuming that A has >>> already run [once] some user-interaction that initiates the load of A, >>> C, and D. This user interaction may be before the other plugin requested >>> A, or after it requested A. > > // CMS plugin 2 > var A = E('script', { src: 'A.js', prefetch: true }); > var C = E('script', { src: 'C.js', needs: 'A.js', prefetch: true }); > var D = E('script', { src: 'D.js', needs: 'A.js', prefetch: true }); > document.body.append(A, C, D); > function sawUserInteraction() { > C.execute(); > D.execute(); > }; > >>> "A.js" can be requested relatively (via a <base> tag or just relative to >>> document root) or absolutely, or it might be requested with the >>> leading-// protocol-relative from, taking on whatever http or https >>> protocol the page has, whereas other references to it may specify the >>> prototcol. >>> >>> These plugins can't guarantee what ID's or classes they use are reliably >>> unique without undue processing burden. >> >> [I've trimmed the text Kyle wrote here, but also implicit in his >> description, as I understood it, was that A.js should only run once even >> if both plugins tried to load it.] >> >>> [Use-case T:] I have two different calendar widgets. I want to pop one >>> of them up when a user clicks a button. The user may never click the >>> button, in which case I don't want the calendar widget to have ever >>> executed to render. [...] > > <script id=calA src="a.js" prefetch></script> > <script id=calB src="b.js" prefetch></script> > <script> > function showCalendar(which) { > if (which == 'a') > document.scripts.calA.execute(); > else > document.scripts.calB.execute(); > } > </script> > > Neither Ian's nor my proposal fallbacks gracefully here :( > >>> [Use-case U:] I have a set of script "A.js", "B.js", and "C.js". B >>> relies on A, and C relies on B. So they need to execute strictly in that >>> order. [Now], imagine they progressively render different parts of a >>> widget. [...] I only want to execute A, B and C once all 3 are preloaded >>> and ready to go. It's [...] about minimizing delays between them, for >>> performance PERCEPTION. >>> >>> [For example, one of them might start playing a video, and another might >>> introduce the <canvas> slides for that video. You want all of the >>> relevant scripts to be run at once, so there's no point where the page >>> has a <video> element but doesn't have the <canvas>.] > > <script src="A.js" prefetch></script> > <script src="B.js" prefetch needs="A.js"></script> > <script id=c src="C.js" prefetch needs="B.js"></script> > <script> > // when we need it... > document.scripts.c.execute(); > </script> > >> On Thu, 11 Jul 2013, Kyle Simpson wrote: >>> >>> [Use-case V:] you have a string of scripts ("A.js", "B.js", and "C.js") >>> loading which constitute a dependency chain. A must run before B, which >>> must run before C. However, if you detect an error in loading, you stop >>> the rest of the executions (and preferably loading too!), since clearly >>> dependencies will fail for further scripts, and the errors will just >>> unnecessarily clutter the developer console log making it harder to >>> debug. > > <script src="A.js" prefetch></script> > <script src="B.js" prefetch needs="A.js"></script> > <script id=c src="C.js" prefetch needs="B.js"></script> > <script> > onerror = function (message, source, lineno, colno, error) { > // report error > } > // when we need it... > document.scripts.c.execute(); > </script> > >>> [Use-case W:] some developers have even requested to be able to stop the >>> chain and prevent further executions if the script loads, but there's >>> some compile-time syntax error or run-time error that happens during the >>> execution. For them, it's not enough for B to simply finish loading >>> successfully, but that it must fully execute without error. > > <script id=a src="A.js" whenneeded></script> > <script src="B.js" whenneeded needs="A.js"></script> > <script id=c src="C.js" whenneeded needs="B.js"></script> > <script> > function onAfailedToInitialize() { > document.scripts.a.src = null; > } > // when we need it... > document.scripts.c.execute(); > </script> > >> On Sun, 14 Jul 2013, Kornel Lesi?ski wrote (trimmed): >>> >>> [Use-case X:] not all dependencies are JS files, e.g. authors use >>> plugins to load template files, JSON, images, etc. > > <script src="deps.js" async></script> > <script src="build.js" needs="deps.js"></script> > > // in deps.js: > var me = document.currentScript; > var image = new Image(); > image.src = 'image.png'; > currentScript.needs.add(image); > >>> [Use-case Y:] not all dependencies are usefully satisfied immediately >>> after their JS file is loaded, e.g. some libraries may need asynchronous >>> initialization. > > I don't intend to address use case but we could make it so that script element without src is an indefinite dependency as in: > > <script src="slowLoad.js" async></script> > <script src="next.js" needs="slowLoad.js"></script> > > // in slowLoad.js: > > var me = document.currentScript; > var dummyScript = document.createElement('script'); > me.needs.add(dummyScript); > me.incDependencies(); > setTimeout(init, 1000); > function init() { > // ok, we're ready > me.needs.remove(dummyScript); > } > >>> [Use-case Z:] Another common kind of dependency scripts have is presence >>> of certain element in the DOM, e.g. `dropdown-menu.js` may require `<nav >>> id="menu">` to be in the document _and_ have its content fully parsed >>> before the script can run. > > I guess we can somehow make needs.add take an id as well as a script name and a node? > Or add a method like requireElementWithId as in: > > <script src="navi.js" async></script> > // in nav.js: > document.currentScript.requireElementWithId('menu'); > > - R. Niwa > From willchan at chromium.org Tue Sep 3 17:01:11 2013 From: willchan at chromium.org (=?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?=) Date: Wed, 4 Sep 2013 08:01:11 +0800 Subject: [whatwg] Script preloading In-Reply-To: <Pine.LNX.4.64.1307091607110.24681@ps20323.dreamhostps.com> References: <Pine.LNX.4.64.1307091607110.24681@ps20323.dreamhostps.com> Message-ID: <CAA4WUYgXuL0Qcw0+3K53mm64i=o_qfVCMtvXMEyao5O83z7vsw@mail.gmail.com> Hello folks. Sorry for the late response to several comments in this mega-thread, I've mostly been traveling/vacationing for the past 2 months. A teammate asked me to look at this in case I had comments. I don't know web dev issues very well, so I'm going to restrain myself from offering many opinions about the new proposals other than wow, all this dependency stuff looks complicated, but maybe it's worth it? I'll keep to some observations from a networking performance perspective, in case it's relevant to the discussion: * Any advantages the preloader currently gives is probably only going to be magnified with HTTP/2. Browsers today will in key situations hold back lower priority resource loads, even after the resource has been discovered by the parser/preloader, in order to reduce network contention and prioritize resources. But with HTTP/2, the browser almost never has to do this since it can express the request priority in the HTTP/2 protocol itself, and let the server order responses appropriately. * <link rel=subresource> is great for resource discovery. Given the above observation, note that it has some deficiencies. Most obviously, it does not indicate the resource type. Browsers today can heuristically assign a priority based on the resource type (script/image/stylesheet/etc). Arguably, browsers could just use the filename extension as a hint to the resource type, and that'd get us most of the way there. In any case, Chromium, when it encounters <link rel=subresource> is going to assign the resource load the lowest priority level, and only when the parser encounters the actual resource via a <script> tag or something, will another resource load be issued with the "appropriate" priority. Almost all modern browsers will hold back low priority resource loads before first paint in order to get critical scripts and stylesheets in <head> ASAP without contention. Anything marked with <link rel=subresource> will be considered low priority and in all likelihood not requested early. Note that HTTP/2 currently does not support re-prioritization (and that feature is being debated), so that means that when the resource load for <link rel=subresource> gets issued over an HTTP/2 connection, it will have the lowest priority, which is probably undesirable. FWIW, I think <link rel=subresource> was a good initial start, but suffers from key weaknesses and should be thrown out and replaced. * Given current browser heuristics for resource prioritization based on resource type, all <script> resources will have the same priority. Within HTTP/1.X, that means you'll get some amount of parallelization based on the connection per host limit and what origins the script resources are hosted, and then get FIFO. New additions like lazyload attributes (and perhaps leveraging the defer attribute) may affect this. With HTTP/2, there is a very high (effectively infinite) parallelization limit. With prioritization, there's no contention across priority levels. But since script resources today generally all have the same priority, they will all contend and most naive servers are going to round robin the response bytes, which is the worst thing you could do with script resources, since current JS VMs do not incrementally process script resources, but process them as a whole. So round-robining all the response bytes will just push out start time of JS processing for all scripts, which is rather terrible. * Obviously, given what I've said above, some level of hinting of prioritization/dependency amongst scripts/resources within the web platform would be useful to the networking layer since the networking layer can much more effectively prioritize resources and thus mitigate network contention. If finer grained priority/dependency information isn't provided in the web platform, my browser's networking stack is likely going to have to, even with HTTP/2, do HTTP/1.X style contention mitigation by restricting parallelization within a priority level. Which is a shame since web developers probably think that with HTTP/2, they can have as many fine grained resources as they want. Cheers. On Wed, Jul 10, 2013 at 3:39 AM, Ian Hickson <ian at hixie.ch> wrote: > > A topic that regularly comes up is script loading. > > I sent an e-mail responding to related feedback last year, though it > didn't get any replies to the script loading parts of it: > > > http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0221.html > > It seems that people want something that: > > - Lets them download scripts but not execute them until needed. > - Lets them have multiple interdependent scripts and have the browser > manage their ordering. > - Do all this without having to modify existing scripts. > > I must admit to not really understanding these requirements (script > execution can be made more or less free if they are designed to just > expose some functions, for example, and it's trivial to set up a script > dependency mechanism for scripts to run each other in order, and there's > no reason browsers can't parse scripts off the main thread, etc). But > since everyone else seems to think these are issues, let's ignore that. > > The proposals I've seen so far for extending the spec's script preloading > mechanisms fall into two categories: > > - provide some more control over the mechanisms already there, e.g. > firing events at various times, adding attributes to make the script > loading algorithm work differently, or adding methods to trigger > particular parts of the algorithm under author control. > > - provide a layer above the current algorithm that provides strong > semantics, but that doesn't have much impact on the loading algorithm > itself. > > I'm very hesitant to do the first of these, because the algorithm is _so_ > complicated that adding anything else to it is just going to result in > bugs in browsers. There comes a point where an algorithm just becomes so > hard to accurately test that it's a lost cause. > > The second seems more feasible, though. > > Would something like this, based on proposals from a variety of people in > the past, work for your needs? > > 1. Add a "dependencies" attribute to <script> that can point to other > scripts to indicate that execution of this script should be delayed > until all other scripts that are (a) earlier in the tree order and (b) > identified by this attribute have executed. > > <script id="jquery" src="jquery.js" async></script> > <script id="shims" src="shims.js" async></script> > <script dependencies="shims jquery" src="myscript.js" async></script> > > This would download jquery.js, shims.js, and myscript.js ASAP, without > blocking anything else, and would then run jquery.js and shims.js ASAP, > in any order, and then once both have executed, it would execute > myscript.js. > > 2. Add an "whenneeded" boolean content attribute, a "markNeeded()" method, > and an internal "is-needed flag" (initially false) to the <script> > element. When a script is about to execute, if its whenneeded="" > attribute is set, but its "is-needed" flag is not, then delay > execution. Calling markNeeded() on a script that has a whenneeded > boolean but that has not executed yet first causes the markNeeded() > method on all the script's dependencies to be called, and then causes > this script to become ready to execute. > > <script id="jquery" src="jquery.js" async whenneeded></script> > <script id="shims" src="shims.js" async whenneeded></script> > <script id="myscript" dependencies="shims jquery" src="myscript.js" > async whenneeded></script> > > This would download jquery.js, shims.js, and myscript.js ASAP, and then > wait for further instructions. > > document.getElementById('myscript').markNeeded(); > > This would then cause the scripts to execute, first jquery.js and > shims.js (in any order), and then myscript.js. If any hadn't finished > downloading yet, it would first wait for that to finish. > > (We could make markNeeded() return a promise, too.) > > Is there a need for delaying the download of a script as well? (If so, we > could change whenneeded="" to have values, like whenneeded="execute" vs > whenneeded="download" or something.) > > Is there something this doesn't handle which it would need to handle? > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > From bzbarsky at MIT.EDU Tue Sep 3 17:47:04 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Tue, 03 Sep 2013 20:47:04 -0400 Subject: [whatwg] Challenging canvas.supportsContext In-Reply-To: <alpine.DEB.2.00.1309032240300.7443@ps20323.dreamhostps.com> References: <CAJTmd9rkwsjC+WDfLr7um0=h8Pvtg9JOJCRHzH4PhdbXjgpaaA@mail.gmail.com> <CAJTmd9q-eH8fnZSP5mr3kX-quyQcNXnyXTh5o_hX+MdfuXfrGQ@mail.gmail.com> <alpine.DEB.2.00.1309032240300.7443@ps20323.dreamhostps.com> Message-ID: <52268308.1090802@mit.edu> On 9/3/13 7:13 PM, Ian Hickson wrote: > Wouldn't checking for window.WebGLRenderingContext be just as unreliable > then? I don't understand why it's ok to be able to test that, but why > probablySupportsContext() wouldn't be ok. I'm a lot more OK with the "probablySupportsContext" naming than "supportsContext" here. -Boris From rniwa at apple.com Tue Sep 3 20:00:45 2013 From: rniwa at apple.com (Ryosuke Niwa) Date: Tue, 03 Sep 2013 20:00:45 -0700 Subject: [whatwg] Prioritizing subresources (Was Script preloading) In-Reply-To: <CAA4WUYgXuL0Qcw0+3K53mm64i=o_qfVCMtvXMEyao5O83z7vsw@mail.gmail.com> References: <Pine.LNX.4.64.1307091607110.24681@ps20323.dreamhostps.com> <CAA4WUYgXuL0Qcw0+3K53mm64i=o_qfVCMtvXMEyao5O83z7vsw@mail.gmail.com> Message-ID: <86A0181F-5695-4801-9254-D2B0E0CA5928@apple.com> On Sep 3, 2013, at 5:01 PM, William Chan (???) <willchan at chromium.org> wrote: > Hello folks. Sorry for the late response to several comments in this > mega-thread, I've mostly been traveling/vacationing for the past 2 months. > A teammate asked me to look at this in case I had comments. I don't know > web dev issues very well, so I'm going to restrain myself from offering > many opinions about the new proposals other than wow, all this dependency > stuff looks complicated, but maybe it's worth it? I'll keep to some > observations from a networking performance perspective, in case it's > relevant to the discussion: > > * Any advantages the preloader currently gives is probably only going to be > magnified with HTTP/2. Browsers today will in key situations hold back > lower priority resource loads, even after the resource has been discovered > by the parser/preloader, in order to reduce network contention and > prioritize resources. But with HTTP/2, the browser almost never has to do > this since it can express the request priority in the HTTP/2 protocol > itself, and let the server order responses appropriately. > * <link rel=subresource> is great for resource discovery. Given the above > observation, note that it has some deficiencies. Most obviously, it does > not indicate the resource type. Browsers today can heuristically assign a > priority based on the resource type (script/image/stylesheet/etc). > Arguably, browsers could just use the filename extension as a hint to the > resource type, and that'd get us most of the way there. In any case, > Chromium, when it encounters <link rel=subresource> is going to assign the > resource load the lowest priority level, and only when the parser > encounters the actual resource via a <script> tag or something, will > another resource load be issued with the "appropriate" priority. Almost all > modern browsers will hold back low priority resource loads before first > paint in order to get critical scripts and stylesheets in <head> ASAP > without contention. Anything marked with <link rel=subresource> will be > considered low priority and in all likelihood not requested early. Note > that HTTP/2 currently does not support re-prioritization (and that feature > is being debated), so that means that when the resource load for <link > rel=subresource> gets issued over an HTTP/2 connection, it will have the > lowest priority, which is probably undesirable. FWIW, I think <link > rel=subresource> was a good initial start, but suffers from key weaknesses > and should be thrown out and replaced. > * Given current browser heuristics for resource prioritization based on > resource type, all <script> resources will have the same priority. Within > HTTP/1.X, that means you'll get some amount of parallelization based on the > connection per host limit and what origins the script resources are hosted, > and then get FIFO. New additions like lazyload attributes (and perhaps > leveraging the defer attribute) may affect this. With HTTP/2, there is a > very high (effectively infinite) parallelization limit. With > prioritization, there's no contention across priority levels. But since > script resources today generally all have the same priority, they will all > contend and most naive servers are going to round robin the response bytes, > which is the worst thing you could do with script resources, since current > JS VMs do not incrementally process script resources, but process them as a > whole. So round-robining all the response bytes will just push out start > time of JS processing for all scripts, which is rather terrible. > * Obviously, given what I've said above, some level of hinting of > prioritization/dependency amongst scripts/resources within the web platform > would be useful to the networking layer since the networking layer can much > more effectively prioritize resources and thus mitigate network contention. > If finer grained priority/dependency information isn't provided in the web > platform, my browser's networking stack is likely going to have to, even > with HTTP/2, do HTTP/1.X style contention mitigation by restricting > parallelization within a priority level. Which is a shame since web > developers probably think that with HTTP/2, they can have as many fine > grained resources as they want. Why don't we simply add "priority" content attribute to link element then? <link rel=subresource href="high-priority-resource.js" priority="high"> <link rel=subresource href="low-priority-resource.js" priority="low"> But can we modify these priorities dynamically? I have one specific use case that requires this. Use case D: A web page wants to load and execute a script widget.js if the script is already cached in the browser. However, it wants to load other essential assets such as images first if it's not already in the cache except as long as the user had not started interacting with the parts of the page that require widget.js. i.e. it (loads and) executes the script immediately when and only when the script had already been cached or the user had started interacting with the parts of the page that requires the script. Otherwise, the script is loaded with a low priority. - R. Niwa From jkorpela at cs.tut.fi Tue Sep 3 22:30:03 2013 From: jkorpela at cs.tut.fi (Jukka K. Korpela) Date: Wed, 04 Sep 2013 08:30:03 +0300 Subject: [whatwg] @generator-unable-to-provide-required-alt, figure with figcaption In-Reply-To: <alpine.DEB.2.00.1309032059410.7443@ps20323.dreamhostps.com> References: <CA+ri+VmGmZh2goTez1YpOce9C=WpoEdwH3ToV+X0owpnUeOVYQ@mail.gmail.com> <6D789473-22C6-48B1-BD55-1D375834178A@prlbr.com> <Pine.LNX.4.64.1306172040500.11139@ps20323.dreamhostps.com> <026D354F-5220-4F2B-823F-125249027E52@prlbr.com> <Pine.LNX.4.64.1306191743130.11139@ps20323.dreamhostps.com> <0525D1DC-57F5-4F4C-838E-D7D280E9D984@prlbr.com> <alpine.DEB.2.00.1309032059410.7443@ps20323.dreamhostps.com> Message-ID: <5226C55B.5080603@cs.tut.fi> 2013-09-04 0:09, Ian Hickson wrote: >> To a user, even ?(an image)? is better than lack of alt attribute > > I disagree. The lack of an alt attribute can be used by user agents to > substitute the string "(an image)", in which case it is the same, or it > can be used to do far more, e.g. image recognition, OCR, etc. This isn't > academic, these technologies exist today. There is nothing that makes that makes that impossible, or more difficult, if the element has an alt attribute. If you mean that programs would actually do such things if and only if the alt attribute is absent, then this is very speculative. Let?s worry about that when browsers are actually capable and willing to do such things at all. There is an essential difference between lack of an alt attribute and a more or less generic value used for it, as in alt="(an image)" or in alt="(image: horse5)" (automatically generated e.g. from an image URL that ends with horse5.png) or in alt="(photo of Hixie)". Lack of the alt attribute says absolutely nothing about the image; it might represent a word as an image, or be pure decoration, or be so complicated that writing a textual alternative would be major challenge in content production. Someone who hears, says ?image ? horse five? at least gets some idea of what the image is about, and even ?an image? as opposite to whatever a speech browsers says about <img ... alt=""> is an improvement: the user can know that the author tried to find a textual replacement for the image but couldn't. > To the non-validator user agent, that attribute means nothing. It's a > non-conforming attribute with no semantics to any software outside content > generators and conformance checkers. It is presented as a non-conforming attribute that can be used to get a clean validation report, i.e. to make a validator report a document as valid, as conforming. This is grossly illogical and misleading. Anyone who uses a validator has the right to know whether the document is valid or not, to the extent that this can be programmatically determined. And it is, if the attribute is not valid. Here's a proposal: The character U+FFFC OBJECT REPLACEMENT CHARACTER, which is ?used as placeholder in text for an otherwise unspecified object? [the quote is from the code chart entry in the Unicode Standard] be used as the value of an alt attribute to indicate that it was not possible to write an adequate alternate text for the image. This typically means that the image comes from a source external to the system that generates the HTML document and the system cannot analyze it or otherwise find a suitable text replacement. You could even add a statement like this: User agents that present the value of an alt attribute to the user may express the value of U+FFFC using a generic expression like ?some image?. They may also apply technologies that process the image trying to recognize its content and then express the result suitably, e.g. ?an unrecognizable image? or ?an image of a horse? or (in the case of having recognized that the content is scannable as text) ?Hello?. ? It?s of course possible that people would then use alt="&#fffc;" to silence validators even when they could easily write real text there. But they can anyway use alt="" for such purposes if they want to. Yucca From willchan at chromium.org Tue Sep 3 23:06:56 2013 From: willchan at chromium.org (=?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?=) Date: Wed, 4 Sep 2013 14:06:56 +0800 Subject: [whatwg] Prioritizing subresources (Was Script preloading) In-Reply-To: <86A0181F-5695-4801-9254-D2B0E0CA5928@apple.com> References: <Pine.LNX.4.64.1307091607110.24681@ps20323.dreamhostps.com> <CAA4WUYgXuL0Qcw0+3K53mm64i=o_qfVCMtvXMEyao5O83z7vsw@mail.gmail.com> <86A0181F-5695-4801-9254-D2B0E0CA5928@apple.com> Message-ID: <CAA4WUYj-v4TKyFFUoq7mpmrccKoM6Ar2cq1+1vGdDAeu8tYzVw@mail.gmail.com> On Sep 3, 2013 8:00 PM, "Ryosuke Niwa" <rniwa at apple.com> wrote: > > On Sep 3, 2013, at 5:01 PM, William Chan (???) <willchan at chromium.org> wrote: > > > Hello folks. Sorry for the late response to several comments in this > > mega-thread, I've mostly been traveling/vacationing for the past 2 months. > > A teammate asked me to look at this in case I had comments. I don't know > > web dev issues very well, so I'm going to restrain myself from offering > > many opinions about the new proposals other than wow, all this dependency > > stuff looks complicated, but maybe it's worth it? I'll keep to some > > observations from a networking performance perspective, in case it's > > relevant to the discussion: > > > > * Any advantages the preloader currently gives is probably only going to be > > magnified with HTTP/2. Browsers today will in key situations hold back > > lower priority resource loads, even after the resource has been discovered > > by the parser/preloader, in order to reduce network contention and > > prioritize resources. But with HTTP/2, the browser almost never has to do > > this since it can express the request priority in the HTTP/2 protocol > > itself, and let the server order responses appropriately. > > * <link rel=subresource> is great for resource discovery. Given the above > > observation, note that it has some deficiencies. Most obviously, it does > > not indicate the resource type. Browsers today can heuristically assign a > > priority based on the resource type (script/image/stylesheet/etc). > > Arguably, browsers could just use the filename extension as a hint to the > > resource type, and that'd get us most of the way there. In any case, > > Chromium, when it encounters <link rel=subresource> is going to assign the > > resource load the lowest priority level, and only when the parser > > encounters the actual resource via a <script> tag or something, will > > another resource load be issued with the "appropriate" priority. Almost all > > modern browsers will hold back low priority resource loads before first > > paint in order to get critical scripts and stylesheets in <head> ASAP > > without contention. Anything marked with <link rel=subresource> will be > > considered low priority and in all likelihood not requested early. Note > > that HTTP/2 currently does not support re-prioritization (and that feature > > is being debated), so that means that when the resource load for <link > > rel=subresource> gets issued over an HTTP/2 connection, it will have the > > lowest priority, which is probably undesirable. FWIW, I think <link > > rel=subresource> was a good initial start, but suffers from key weaknesses > > and should be thrown out and replaced. > > * Given current browser heuristics for resource prioritization based on > > resource type, all <script> resources will have the same priority. Within > > HTTP/1.X, that means you'll get some amount of parallelization based on the > > connection per host limit and what origins the script resources are hosted, > > and then get FIFO. New additions like lazyload attributes (and perhaps > > leveraging the defer attribute) may affect this. With HTTP/2, there is a > > very high (effectively infinite) parallelization limit. With > > prioritization, there's no contention across priority levels. But since > > script resources today generally all have the same priority, they will all > > contend and most naive servers are going to round robin the response bytes, > > which is the worst thing you could do with script resources, since current > > JS VMs do not incrementally process script resources, but process them as a > > whole. So round-robining all the response bytes will just push out start > > time of JS processing for all scripts, which is rather terrible. > > * Obviously, given what I've said above, some level of hinting of > > prioritization/dependency amongst scripts/resources within the web platform > > would be useful to the networking layer since the networking layer can much > > more effectively prioritize resources and thus mitigate network contention. > > If finer grained priority/dependency information isn't provided in the web > > platform, my browser's networking stack is likely going to have to, even > > with HTTP/2, do HTTP/1.X style contention mitigation by restricting > > parallelization within a priority level. Which is a shame since web > > developers probably think that with HTTP/2, they can have as many fine > > grained resources as they want. > > Why don't we simply add "priority" content attribute to link element then? > > <link rel=subresource href="high-priority-resource.js" priority="high"> > <link rel=subresource href="low-priority-resource.js" priority="low"> Sorry Ryosuke, I had too much scotch and can't think through your other use case. This specific proposal is a no go from my perspective though because many pages have components from different authors. I trust a single author to use the appropriate relative priority for all the resources he/she controls. Your proposal seems to imply absolute priorities, which I think is a mistake. I don't want a third party ads widget to have high priority even if they request it. I don't mind giving third parties the ability to "nice" the priority of their resource loads. This is why demoting priority based on defer/a sync/lazyload seems reasonable to me. PS: relative values work fine within defined contexts. I think iframes and web components may be appropriate contextual boundaries. > > > But can we modify these priorities dynamically? I have one specific use case that requires this. > > Use case D: > A web page wants to load and execute a script widget.js if the script is already cached in the browser. However, it wants to load other essential assets such as images first if it's not already in the cache except as long as the user had not started interacting with the parts of the page that require widget.js. > > i.e. it (loads and) executes the script immediately when and only when the script had already been cached or the user had started interacting with the parts of the page that requires the script. Otherwise, the script is loaded with a low priority. > > - R. Niwa > From annevk at annevk.nl Wed Sep 4 04:36:15 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Wed, 4 Sep 2013 12:36:15 +0100 Subject: [whatwg] Encoding: lone surrogates and utf-8, utf-16be, and utf-16le encoders Message-ID: <CADnb78h1uDpShv=JFEbX9hh=A47vr6_5=qeTbyWuKOstmG9RJA@mail.gmail.com> The way the utf-8, utf-16be, and utf-16le encoders are written is that they accept code points (not code units). If the code points are in the surrogate range, they raise an error. That seems problematic. Encoders for utf-8 and utf-16be, and utf-16le are assumed to be safe, because you typically forget about lone surrogates. The API deals with this by having the [EnsureUTF16] flag which converts lone surrogates into U+FFFD. So by the time code points hit the encoder they're no longer in the lone surrogate range. Gecko however has not implemented this for utf-16be and utf-16be, but has for utf-8. (Or maybe the utf-8 encoder is better.) For now I'll assume this is a bug in Gecko. I can see several options for potentially improving this setup, but I need some feedback before going there: 1. Require Unicode scalar value input for encoders, and guarantee it as decoder output. 2. Change the utf-8, utf-16be, and utf-16le encoders to emit the byte sequence for U+FFFD rather than raise an error for input in the lone surrogate range. This would simplify the API and other callers to the utf-8, utf-16be, and utf-16le encoders as they no longer need to worry about them terminating with failure. 3. Move towards defining the entire platform in terms of 16-bit code units and forget about the nicer theoretical model of Unicode scalar values. -- http://annevankesteren.nl/ From jackalmage at gmail.com Wed Sep 4 11:38:44 2013 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Wed, 4 Sep 2013 11:38:44 -0700 Subject: [whatwg] Encoding: lone surrogates and utf-8, utf-16be, and utf-16le encoders In-Reply-To: <CADnb78h1uDpShv=JFEbX9hh=A47vr6_5=qeTbyWuKOstmG9RJA@mail.gmail.com> References: <CADnb78h1uDpShv=JFEbX9hh=A47vr6_5=qeTbyWuKOstmG9RJA@mail.gmail.com> Message-ID: <CAAWBYDBHrPqOCCde4ALGbW+Hf27-JN8pQ9rR1YiY4A5mx8yVGQ@mail.gmail.com> On Wed, Sep 4, 2013 at 4:36 AM, Anne van Kesteren <annevk at annevk.nl> wrote: > The way the utf-8, utf-16be, and utf-16le encoders are written is that > they accept code points (not code units). If the code points are in > the surrogate range, they raise an error. > > That seems problematic. Encoders for utf-8 and utf-16be, and utf-16le > are assumed to be safe, because you typically forget about lone > surrogates. > > The API deals with this by having the [EnsureUTF16] flag which > converts lone surrogates into U+FFFD. So by the time code points hit > the encoder they're no longer in the lone surrogate range. > > Gecko however has not implemented this for utf-16be and utf-16be, but > has for utf-8. (Or maybe the utf-8 encoder is better.) For now I'll > assume this is a bug in Gecko. > > > I can see several options for potentially improving this setup, but I > need some feedback before going there: > > 1. Require Unicode scalar value input for encoders, and guarantee it > as decoder output. > 2. Change the utf-8, utf-16be, and utf-16le encoders to emit the byte > sequence for U+FFFD rather than raise an error for input in the lone > surrogate range. This would simplify the API and other callers to the > utf-8, utf-16be, and utf-16le encoders as they no longer need to worry > about them terminating with failure. > 3. Move towards defining the entire platform in terms of 16-bit code > units and forget about the nicer theoretical model of Unicode scalar > values. I prefer option 2 - CSS is now defined to do the same thing when parsed (nulls, lone surrogates, and out-of-range codepoints are all converted to u+fffd). ~TJ From rniwa at apple.com Wed Sep 4 11:55:16 2013 From: rniwa at apple.com (Ryosuke Niwa) Date: Wed, 04 Sep 2013 11:55:16 -0700 Subject: [whatwg] Prioritizing subresources (Was Script preloading) In-Reply-To: <CAA4WUYj-v4TKyFFUoq7mpmrccKoM6Ar2cq1+1vGdDAeu8tYzVw@mail.gmail.com> References: <Pine.LNX.4.64.1307091607110.24681@ps20323.dreamhostps.com> <CAA4WUYgXuL0Qcw0+3K53mm64i=o_qfVCMtvXMEyao5O83z7vsw@mail.gmail.com> <86A0181F-5695-4801-9254-D2B0E0CA5928@apple.com> <CAA4WUYj-v4TKyFFUoq7mpmrccKoM6Ar2cq1+1vGdDAeu8tYzVw@mail.gmail.com> Message-ID: <12313853-5734-43E9-8C6C-B84E98BA7917@apple.com> On Sep 3, 2013, at 11:06 PM, William Chan (???) <willchan at chromium.org> wrote: > On Sep 3, 2013 8:00 PM, "Ryosuke Niwa" <rniwa at apple.com> wrote: > > > > On Sep 3, 2013, at 5:01 PM, William Chan (???) <willchan at chromium.org> wrote: > > > > > Hello folks. Sorry for the late response to several comments in this > > > mega-thread, I've mostly been traveling/vacationing for the past 2 months. > > > A teammate asked me to look at this in case I had comments. I don't know > > > web dev issues very well, so I'm going to restrain myself from offering > > > many opinions about the new proposals other than wow, all this dependency > > > stuff looks complicated, but maybe it's worth it? I'll keep to some > > > observations from a networking performance perspective, in case it's > > > relevant to the discussion: > > > > > > * Any advantages the preloader currently gives is probably only going to be > > > magnified with HTTP/2. Browsers today will in key situations hold back > > > lower priority resource loads, even after the resource has been discovered > > > by the parser/preloader, in order to reduce network contention and > > > prioritize resources. But with HTTP/2, the browser almost never has to do > > > this since it can express the request priority in the HTTP/2 protocol > > > itself, and let the server order responses appropriately. > > > * <link rel=subresource> is great for resource discovery. Given the above > > > observation, note that it has some deficiencies. Most obviously, it does > > > not indicate the resource type. Browsers today can heuristically assign a > > > priority based on the resource type (script/image/stylesheet/etc). > > > Arguably, browsers could just use the filename extension as a hint to the > > > resource type, and that'd get us most of the way there. In any case, > > > Chromium, when it encounters <link rel=subresource> is going to assign the > > > resource load the lowest priority level, and only when the parser > > > encounters the actual resource via a <script> tag or something, will > > > another resource load be issued with the "appropriate" priority. Almost all > > > modern browsers will hold back low priority resource loads before first > > > paint in order to get critical scripts and stylesheets in <head> ASAP > > > without contention. Anything marked with <link rel=subresource> will be > > > considered low priority and in all likelihood not requested early. Note > > > that HTTP/2 currently does not support re-prioritization (and that feature > > > is being debated), so that means that when the resource load for <link > > > rel=subresource> gets issued over an HTTP/2 connection, it will have the > > > lowest priority, which is probably undesirable. FWIW, I think <link > > > rel=subresource> was a good initial start, but suffers from key weaknesses > > > and should be thrown out and replaced. > > > * Given current browser heuristics for resource prioritization based on > > > resource type, all <script> resources will have the same priority. Within > > > HTTP/1.X, that means you'll get some amount of parallelization based on the > > > connection per host limit and what origins the script resources are hosted, > > > and then get FIFO. New additions like lazyload attributes (and perhaps > > > leveraging the defer attribute) may affect this. With HTTP/2, there is a > > > very high (effectively infinite) parallelization limit. With > > > prioritization, there's no contention across priority levels. But since > > > script resources today generally all have the same priority, they will all > > > contend and most naive servers are going to round robin the response bytes, > > > which is the worst thing you could do with script resources, since current > > > JS VMs do not incrementally process script resources, but process them as a > > > whole. So round-robining all the response bytes will just push out start > > > time of JS processing for all scripts, which is rather terrible. > > > * Obviously, given what I've said above, some level of hinting of > > > prioritization/dependency amongst scripts/resources within the web platform > > > would be useful to the networking layer since the networking layer can much > > > more effectively prioritize resources and thus mitigate network contention. > > > If finer grained priority/dependency information isn't provided in the web > > > platform, my browser's networking stack is likely going to have to, even > > > with HTTP/2, do HTTP/1.X style contention mitigation by restricting > > > parallelization within a priority level. Which is a shame since web > > > developers probably think that with HTTP/2, they can have as many fine > > > grained resources as they want. > > > > Why don't we simply add "priority" content attribute to link element then? > > > > <link rel=subresource href="high-priority-resource.js" priority="high"> > > <link rel=subresource href="low-priority-resource.js" priority="low"> > > Sorry Ryosuke, I had too much scotch and can't think through your other use case. This specific proposal is a no go from my perspective though because many pages have components from different authors. I trust a single author to use the appropriate relative priority for all the resources he/she controls. Your proposal seems to imply absolute priorities, which I think is a mistake. I don't want a third party ads widget to have high priority even if they request it. > If we're doing this, then priority needs to be relative per origin or per document so that you can't sabotage other websites or be sabotaged by thirdparty ads as you suggested. e.g. If all resources on a page has the priority "high", then it should behave as if all of them have the medium priority. > I don't mind giving third parties the ability to "nice" the priority of their resource loads. This is why demoting priority based on defer/a sync/lazyload seems reasonable to me. > Let me think about this more. - R. Niwa From oliver at apple.com Wed Sep 4 11:56:32 2013 From: oliver at apple.com (Oliver Hunt) Date: Wed, 04 Sep 2013 11:56:32 -0700 Subject: [whatwg] Structured Clone of Map and Set objects Message-ID: <69B3CEC1-06BD-4137-96A2-202BDE590EB9@apple.com> The current structured clone algorithm does not include support for the Map and Set types, so a developer would need to manually implement the serialisation and deserialisation. While this would not be impossible it does seem like it is an unnecessary inconvenience for a core type in ES6. The semantics of Map and Set are stable so unless someone objects i see no reason we should not amend the internal structured clone algorithm to specially handle Set and Map in addition to Array. To support cloning of Map and Set we will want to recursively call the structured clone algorithm on each key or key/value pair in the %SetData% or %MapData% internal arrays, and maintain the order of those entries (as the Map/Set ordering is well defined) --Oliver From annevk at annevk.nl Wed Sep 4 13:12:22 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Wed, 4 Sep 2013 21:12:22 +0100 Subject: [whatwg] Structured Clone of Map and Set objects In-Reply-To: <69B3CEC1-06BD-4137-96A2-202BDE590EB9@apple.com> References: <69B3CEC1-06BD-4137-96A2-202BDE590EB9@apple.com> Message-ID: <CADnb78gb0MTfFZ9C6Djcd61RG1M4Ur+MjRRprFZp4ntkCNrVnw@mail.gmail.com> On Wed, Sep 4, 2013 at 7:56 PM, Oliver Hunt <oliver at apple.com> wrote: > The current structured clone algorithm does not include support for the Map and Set types, so a developer would need to manually implement the serialisation and deserialisation. While this would not be impossible it does seem like it is an unnecessary inconvenience for a core type in ES6. I suggested this to TC39 a while back and I still think it's a good idea even though reception was lukewarm at best (the people replying didn't like to acknowledge the existence of this seemed like). They should define this as a primitive of the Object type and define which objects support it and how. The monkey patching we do now is not great. -- http://annevankesteren.nl/ From ian at hixie.ch Wed Sep 4 15:25:41 2013 From: ian at hixie.ch (Ian Hickson) Date: Wed, 4 Sep 2013 22:25:41 +0000 (UTC) Subject: [whatwg] Cross-Origin Cookies Sharing Proposal In-Reply-To: <9F8CE942-199E-4C01-A43C-7BA7C577BC01@gmail.com> References: <CAMBN-K4y891dJcAngvw0sBgPrpC0NFGGCuq0cL17=wrn+UB1oQ@mail.gmail.com> <20130621191948.71e3bbb9@desudesudesu> <CAMBN-K6sPJkxdc-EjTKDvX9ioBn5MDO0umtGUiDpKTHBuOetcw@mail.gmail.com> <CAE-+aYLCqeGJYL7JRs5-zXGg0jKG1hi14oeq2_dchb6788Lrmg@mail.gmail.com> <CAMBN-K5DMOQ5OYVq_hZ=ozjHCXu9gF3YE0nU=MNyQw+zDK6tjg@mail.gmail.com> <CAE-+aYKUSVz5inGQEvHtC3DfX6fS_ehAVor_9+MdG4cxp5YF4A@mail.gmail.com> <9F8CE942-199E-4C01-A43C-7BA7C577BC01@gmail.com> Message-ID: <alpine.DEB.2.00.1309041932060.7443@ps20323.dreamhostps.com> On Fri, 21 Jun 2013, Huan Du wrote: > > As privacy awareness becomes prevelant, the trend is that future > browsers are going to ban third-party Cookies by default. > > This is a good thing for users, but for giant internet companies, this > has no doubt increases the difficult and complexity of implementing user > session synchronization. > > Is it possible to, like Cross-Origin Resource Sharing, allow a site to > indicate which domains it would like to share Cookies with? Why would a user be ok with sharing cookies with these sites if they're not ok with sharing them otherwise? I don't really understand what the user threat model is here. On Fri, 21 Jun 2013, Nils Dagsson Moskopp wrote: > > I have a suspicion that the only thing that cannot be done easily > without cookies is tracking ? that is, pretending that a user has an > account, but ensuring that she has not made that choice consciously. That's pretty easy to do even without cookies or other storage mechanisms. You can fingerprint a user pretty precisely. On Sat, 22 Jun 2013, Huan Du wrote: > > There are 3 web sites in Alibaba at least: taobao.com, tmall.com, > etao.com. all of them are using a same account management system > including Sign up, Sign in. > > The requirement is simple for the account management system. when user A > signed in taobao.com, we expect A is signed in tmall.com and etao.com. Right. There are lots of cases such as this where third-party cookies (or a similar mechanism) are an integral part of the experience. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Sep 4 16:22:43 2013 From: ian at hixie.ch (Ian Hickson) Date: Wed, 4 Sep 2013 23:22:43 +0000 (UTC) Subject: [whatwg] Default draggable elements In-Reply-To: <CAF3XrKomVOe5tTuT6UheP8CwYNH9J+s4WQ7SW9ru+4Ta=39-Aw@mail.gmail.com> References: <CAF3XrKomVOe5tTuT6UheP8CwYNH9J+s4WQ7SW9ru+4Ta=39-Aw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309042322080.7443@ps20323.dreamhostps.com> On Thu, 11 Jul 2013, Daniel Cheng wrote: > Regarding elements that are draggable by default: > The spec says: > > img elements and a elements with an href attribute have their > > draggable attribute set to true by default. > > I've noticed that in IE and Firefox, an <object> tag embedding an image > also defaults to draggable. It does not default to draggable in > Blink/WebKit. Should the spec be amended to include this special case? Seems reasonable. Done. > Blink/WebKit also make input[image] elements default to draggable (no > other browser does this). I'm not really sure why, but can I confirm > that this won't be in the spec? I'd like to remove it from Blink at > least. Yeah, that seems bad since it's an interactive widget. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From dino at apple.com Wed Sep 4 16:50:10 2013 From: dino at apple.com (Dean Jackson) Date: Thu, 05 Sep 2013 09:50:10 +1000 Subject: [whatwg] Challenging canvas.supportsContext In-Reply-To: <52268308.1090802@mit.edu> References: <CAJTmd9rkwsjC+WDfLr7um0=h8Pvtg9JOJCRHzH4PhdbXjgpaaA@mail.gmail.com> <CAJTmd9q-eH8fnZSP5mr3kX-quyQcNXnyXTh5o_hX+MdfuXfrGQ@mail.gmail.com> <alpine.DEB.2.00.1309032240300.7443@ps20323.dreamhostps.com> <52268308.1090802@mit.edu> Message-ID: <D3D8AD28-A2F0-4A90-A156-42871ADD4FE4@apple.com> On 4 Sep 2013, at 10:47 am, Boris Zbarsky <bzbarsky at mit.edu> wrote: > On 9/3/13 7:13 PM, Ian Hickson wrote: >> Wouldn't checking for window.WebGLRenderingContext be just as unreliable >> then? I don't understand why it's ok to be able to test that, but why >> probablySupportsContext() wouldn't be ok. > > I'm a lot more OK with the "probablySupportsContext" naming than "supportsContext" here. I will update WebKit to probablySupportsContext asap. Dean From ian at hixie.ch Wed Sep 4 17:03:52 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 5 Sep 2013 00:03:52 +0000 (UTC) Subject: [whatwg] scrdoc and session history don't play along in the spec In-Reply-To: <51E0627C.9070705@mit.edu> References: <515EF14C.4070102@mit.edu> <CAJE5ia-WtbpbhvvuWixzah+YDdY-s_-c3kHG_pVe8J5bZa2YgQ@mail.gmail.com> <51C6FB2A.1010304@mit.edu> <CAJE5ia9WnYAZKjvmfh3KbcHN_xYKfmtfxuWQP-sYebxzTePwrQ@mail.gmail.com> <51C72C0C.5000605@mit.edu> <alpine.DEB.2.00.1307121914050.15729@ps20323.dreamhostps.com> <51E0627C.9070705@mit.edu> Message-ID: <alpine.DEB.2.00.1309042338120.7443@ps20323.dreamhostps.com> On Fri, 12 Jul 2013, Boris Zbarsky wrote: > On 7/12/13 3:39 PM, Ian Hickson wrote: > > That wasn't the intent. I've tried to clarify it. > > Hmm. It might help to make it clearer in > http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate > that "new resource" does not mean "URL". Maybe have some explicit thing > that represents the resource being navigated to (which might, for > example, consist of a (url, srcdoc data) pair or something along those > lines)? Yeah... I've thought about doing something like this several times (this is by far not the only part of the spec with this issue -- the word "resource" is in the spec over a thousand times). Fundamentally I'm not really sure what to do to define "resource" in a useful way here and elsewhere. I've added a note before the navigation algorithm, though. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Sep 4 17:07:43 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 5 Sep 2013 00:07:43 +0000 (UTC) Subject: [whatwg] Alignment of empty buttons In-Reply-To: <51E06313.8030105@mit.edu> References: <CAPTJ0XEA_NMAB41UHg1cXXmQTRsxg2zhd9LCuSS2b6R2ZBSVig@mail.gmail.com> <CAPTJ0XE1337+UqNC4D9gpuWO6QHQ7gHc+x8y08SYjCJmghzEag@mail.gmail.com> <51846106.2060403@mit.edu> <alpine.DEB.2.00.1307122007550.15729@ps20323.dreamhostps.com> <51E06313.8030105@mit.edu> Message-ID: <alpine.DEB.2.00.1309050004230.7443@ps20323.dreamhostps.com> On Fri, 12 Jul 2013, Boris Zbarsky wrote: > On 7/12/13 4:08 PM, Ian Hickson wrote: > > The HTML spec is pretty explicit about it not being: > > > > # When the button binding applies to a button element, the element is > > # expected to render as an 'inline-block' box rendered as a button whose > > # contents are the contents of the element. > > -- http://www.whatwg.org/specs/web-apps/current-work/#the-button-element-0 > > Hmm. Is that compatible with the sizing of absolutely positioned > buttons with "left:0; right: 0"? > > For that matter, what happens to buttons if their display style is > changed (e.g. to block)? As far as I can tell, browsers keep treating it as an inline-block box in those cases. Do you have a specific case in mind that isn't handled that way? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From bzbarsky at MIT.EDU Wed Sep 4 22:20:45 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Thu, 05 Sep 2013 01:20:45 -0400 Subject: [whatwg] Alignment of empty buttons In-Reply-To: <alpine.DEB.2.00.1309050004230.7443@ps20323.dreamhostps.com> References: <CAPTJ0XEA_NMAB41UHg1cXXmQTRsxg2zhd9LCuSS2b6R2ZBSVig@mail.gmail.com> <CAPTJ0XE1337+UqNC4D9gpuWO6QHQ7gHc+x8y08SYjCJmghzEag@mail.gmail.com> <51846106.2060403@mit.edu> <alpine.DEB.2.00.1307122007550.15729@ps20323.dreamhostps.com> <51E06313.8030105@mit.edu> <alpine.DEB.2.00.1309050004230.7443@ps20323.dreamhostps.com> Message-ID: <522814AD.8000901@mit.edu> On 9/4/13 8:07 PM, Ian Hickson wrote: > As far as I can tell, browsers keep treating it as an inline-block box in > those cases. OK, that works, I guess. That does mean that buttons are a replaced element, clearly, though... Something needs to spell that out. -Boris From slightlyoff at google.com Wed Sep 4 23:18:27 2013 From: slightlyoff at google.com (Alex Russell) Date: Wed, 4 Sep 2013 23:18:27 -0700 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: <CA+c2ei9yR7mqkHBSBXdcY9THP3zpSRfGUFwY-Oh8kBOP_y487Q@mail.gmail.com> References: <CADnb78jksF5RdfPK4Brcib=N-jYcf0YrO=o=fFz4ZLUqTgLUMg@mail.gmail.com> <521E1168.2040506@mit.edu> <CA+c2ei9yR7mqkHBSBXdcY9THP3zpSRfGUFwY-Oh8kBOP_y487Q@mail.gmail.com> Message-ID: <CANr5HFXoWf3VVB0XzTbZzmC=A9isHoVo3CAUSPLdeC=z+eqJqA@mail.gmail.com> On Wed, Aug 28, 2013 at 9:20 AM, Jonas Sicking <jonas at sicking.cc> wrote: > On Wed, Aug 28, 2013 at 8:04 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote: > > On 8/28/13 9:32 AM, Anne van Kesteren wrote: > >> > >> I'm not sure we need to consider sub-scheme if zip-path can work as > >> it's more complex and not very well thought out. E.g. imagine > >> view-source:zip:http://www.example.org/zip!test.html. > > > > > > What's the issue with that? Gecko supports that (with jar:, not zip:), > > fwiw. > > I have two concerns with the scheme-based approach. > > * It dramatically complicates origin handling. This is something we've > seen multiple times in gecko and something that I expect authors will > struggle with too. > > * It makes it impossible to have create a relative URL from inside the > zip file to refer to something on the same server but outside of the > zip file. Since anything outside of the zip file uses a different > scheme, it means that you have to use an absolute URL. Not even URLs > starting with "/" nor "//" can be used. Apologies for being late to the thread. Just wanted to agree with both of these points. This only seems valuable to me if we can do it in the context of http(s)://. > > 3) We have implementation experience with the "sub-scheme" approach and > we > > know it can work just fine (existence proof is jar: in Gecko). The main > > difficulty it introduces is that computing the origin needs to be done > via > > object accessors, not string-parsing... Do we have any implementation > > experience with "zip-path"-like approaches? > > I don't know about "can work just fine". Sure, if everyone does the > right thing, then it works. But we're having to strictly enforce that > no one does string parsing by hand and instead use URL objects and > Principal objects. Neither of which really are an option on the web > right now as all URL-related APIs use strings. > > > I don't think relative URIs should ever escape a zip archive (though I do > > appreciate the way that would let someone replace directories with > zipped-up > > versions of those directories). The reason for that is that allowing it > > sometimes but not others seems really weird to me, and it seems like we > > don't want to allow it for toplevel zip archives. > > Why not? > > / Jonas > From annevk at annevk.nl Thu Sep 5 01:26:10 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Thu, 5 Sep 2013 09:26:10 +0100 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: <CANr5HFXoWf3VVB0XzTbZzmC=A9isHoVo3CAUSPLdeC=z+eqJqA@mail.gmail.com> References: <CADnb78jksF5RdfPK4Brcib=N-jYcf0YrO=o=fFz4ZLUqTgLUMg@mail.gmail.com> <521E1168.2040506@mit.edu> <CA+c2ei9yR7mqkHBSBXdcY9THP3zpSRfGUFwY-Oh8kBOP_y487Q@mail.gmail.com> <CANr5HFXoWf3VVB0XzTbZzmC=A9isHoVo3CAUSPLdeC=z+eqJqA@mail.gmail.com> Message-ID: <CADnb78gxm0CdHrL8itKKug0Ovk5+MjSsRZfWyhqybcRZ9V_+nQ@mail.gmail.com> On Thu, Sep 5, 2013 at 7:18 AM, Alex Russell <slightlyoff at google.com> wrote: > On Wed, Aug 28, 2013 at 9:20 AM, Jonas Sicking <jonas at sicking.cc> wrote: >> I have two concerns with the scheme-based approach. >> >> * It dramatically complicates origin handling. This is something we've >> seen multiple times in gecko and something that I expect authors will >> struggle with too. >> >> * It makes it impossible to have create a relative URL from inside the >> zip file to refer to something on the same server but outside of the >> zip file. Since anything outside of the zip file uses a different >> scheme, it means that you have to use an absolute URL. Not even URLs >> starting with "/" nor "//" can be used. > > Apologies for being late to the thread. Just wanted to agree with both of > these points. This only seems valuable to me if we can do it in the context > of http(s)://. I don't see how that relates to the points. The sub-scheme approach still works with HTTP. Origin handling would be more complicated. Anyway, unless someone volunteers I'll write up a comparison of the various approaches in due course. Meanwhile, I'd still be very much interested in hearing implementer interest as without multi-vendor buy-in this whole exercise is futile. Mozillians appears in favor. Googlers appear somewhat reluctant, and everyone else is silent. -- http://annevankesteren.nl/ From annevk at annevk.nl Thu Sep 5 03:02:38 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Thu, 5 Sep 2013 11:02:38 +0100 Subject: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments In-Reply-To: <20130628201946.26920@gmx.com> References: <20130628201946.26920@gmx.com> Message-ID: <CADnb78jxE5B2KTYXj0QBv0GSoGddb=Gbxym5Cp5tYxm7zMG1aA@mail.gmail.com> On Fri, Jun 28, 2013 at 9:19 PM, Zirak A <zirak at mail.com> wrote: > Currently, a DocumentFragment only inherits from Node, and thus loses methods like getElementById. However, the Selector API (http://www.w3.org/TR/selectors-api/) defines querySelector and querySelectorAll on document fragments. > My proposal is to add getElementById (which makes sense, as the document fragment is a root node), getElementsByTagName (and its namespace-sensitive version), getElementsByClassName and getElementsByName - in short, all of the general selection methods available on the Document. Per http://dom.spec.whatwg.org/ this is the wrong forum for DOM. Having said that, our current plan is to rely on the Selectors API (2) and slowly move away from getElement* friends over time, as their return values are less than optimal. getElementById is an exception to this, but the hope is that .querySelector("#test") will be fast enough. If it turns out to be a problem, we should re-evaluate at that point. Concrete suggestions for new traversal APIs should be discussed on www-dom at w3.org or the DOM bug database until we decide the more appropriate forum is here, it'd be unfair to the existing community otherwise. If you think I should reply to any of the remainder of this thread please let me know, but I hope this general answer is sufficient. -- http://annevankesteren.nl/ From slightlyoff at google.com Thu Sep 5 08:02:26 2013 From: slightlyoff at google.com (Alex Russell) Date: Thu, 5 Sep 2013 08:02:26 -0700 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: <CADnb78gxm0CdHrL8itKKug0Ovk5+MjSsRZfWyhqybcRZ9V_+nQ@mail.gmail.com> References: <CADnb78jksF5RdfPK4Brcib=N-jYcf0YrO=o=fFz4ZLUqTgLUMg@mail.gmail.com> <521E1168.2040506@mit.edu> <CA+c2ei9yR7mqkHBSBXdcY9THP3zpSRfGUFwY-Oh8kBOP_y487Q@mail.gmail.com> <CANr5HFXoWf3VVB0XzTbZzmC=A9isHoVo3CAUSPLdeC=z+eqJqA@mail.gmail.com> <CADnb78gxm0CdHrL8itKKug0Ovk5+MjSsRZfWyhqybcRZ9V_+nQ@mail.gmail.com> Message-ID: <CANr5HFW5x9vHDSMnyHR4ob=E4MQRUhAKkRuBowf8wGJFy+LgZA@mail.gmail.com> I can't speak for all of Google, but I'm in favour. On 5 Sep 2013 01:26, "Anne van Kesteren" <annevk at annevk.nl> wrote: > On Thu, Sep 5, 2013 at 7:18 AM, Alex Russell <slightlyoff at google.com> > wrote: > > On Wed, Aug 28, 2013 at 9:20 AM, Jonas Sicking <jonas at sicking.cc> wrote: > >> I have two concerns with the scheme-based approach. > >> > >> * It dramatically complicates origin handling. This is something we've > >> seen multiple times in gecko and something that I expect authors will > >> struggle with too. > >> > >> * It makes it impossible to have create a relative URL from inside the > >> zip file to refer to something on the same server but outside of the > >> zip file. Since anything outside of the zip file uses a different > >> scheme, it means that you have to use an absolute URL. Not even URLs > >> starting with "/" nor "//" can be used. > > > > Apologies for being late to the thread. Just wanted to agree with both of > > these points. This only seems valuable to me if we can do it in the > context > > of http(s)://. > > I don't see how that relates to the points. The sub-scheme approach > still works with HTTP. Origin handling would be more complicated. > > Anyway, unless someone volunteers I'll write up a comparison of the > various approaches in due course. Meanwhile, I'd still be very much > interested in hearing implementer interest as without multi-vendor > buy-in this whole exercise is futile. Mozillians appears in favor. > Googlers appear somewhat reluctant, and everyone else is silent. > > > -- > http://annevankesteren.nl/ > From ian at hixie.ch Thu Sep 5 13:47:12 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 5 Sep 2013 20:47:12 +0000 (UTC) Subject: [whatwg] Alignment of empty buttons In-Reply-To: <522814AD.8000901@mit.edu> References: <CAPTJ0XEA_NMAB41UHg1cXXmQTRsxg2zhd9LCuSS2b6R2ZBSVig@mail.gmail.com> <CAPTJ0XE1337+UqNC4D9gpuWO6QHQ7gHc+x8y08SYjCJmghzEag@mail.gmail.com> <51846106.2060403@mit.edu> <alpine.DEB.2.00.1307122007550.15729@ps20323.dreamhostps.com> <51E06313.8030105@mit.edu> <alpine.DEB.2.00.1309050004230.7443@ps20323.dreamhostps.com> <522814AD.8000901@mit.edu> Message-ID: <alpine.DEB.2.00.1309052044160.22377@ps20323.dreamhostps.com> On Thu, 5 Sep 2013, Boris Zbarsky wrote: > On 9/4/13 8:07 PM, Ian Hickson wrote: > > As far as I can tell, browsers keep treating it as an inline-block box > > in those cases. > > OK, that works, I guess. That does mean that buttons are a replaced > element, clearly, though... Something needs to spell that out. In what sense? The definition of "replaced element" here: http://www.w3.org/TR/CSS2/conform.html#replaced-element ...doesn't seem to apply to <button>. The rendering of <button> is very much in CSS' scope, no? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jackalmage at gmail.com Thu Sep 5 13:52:19 2013 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Thu, 5 Sep 2013 13:52:19 -0700 Subject: [whatwg] Alignment of empty buttons In-Reply-To: <alpine.DEB.2.00.1309052044160.22377@ps20323.dreamhostps.com> References: <CAPTJ0XEA_NMAB41UHg1cXXmQTRsxg2zhd9LCuSS2b6R2ZBSVig@mail.gmail.com> <CAPTJ0XE1337+UqNC4D9gpuWO6QHQ7gHc+x8y08SYjCJmghzEag@mail.gmail.com> <51846106.2060403@mit.edu> <alpine.DEB.2.00.1307122007550.15729@ps20323.dreamhostps.com> <51E06313.8030105@mit.edu> <alpine.DEB.2.00.1309050004230.7443@ps20323.dreamhostps.com> <522814AD.8000901@mit.edu> <alpine.DEB.2.00.1309052044160.22377@ps20323.dreamhostps.com> Message-ID: <CAAWBYDDSFKb4W6pU6KKNc5Po6X0d=Fj3G0Vji5wDe7UmmcA+tw@mail.gmail.com> On Thu, Sep 5, 2013 at 1:47 PM, Ian Hickson <ian at hixie.ch> wrote: > On Thu, 5 Sep 2013, Boris Zbarsky wrote: >> On 9/4/13 8:07 PM, Ian Hickson wrote: >> > As far as I can tell, browsers keep treating it as an inline-block box >> > in those cases. >> >> OK, that works, I guess. That does mean that buttons are a replaced >> element, clearly, though... Something needs to spell that out. > > In what sense? > > The definition of "replaced element" here: > > http://www.w3.org/TR/CSS2/conform.html#replaced-element > > ...doesn't seem to apply to <button>. The rendering of <button> is very > much in CSS' scope, no? Technically, no, buttons are still replaced elements. In practice, buttons are pretty much stock CSS elements across all user agents, and we should probably standardize that. ~TJ From ian at hixie.ch Thu Sep 5 13:59:45 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 5 Sep 2013 20:59:45 +0000 (UTC) Subject: [whatwg] Adding 2D Canvas features In-Reply-To: <CAK-G-KVLsECC4cETFYdcPyoqigaaoRhUxcezhMG3jZc2fAViRg@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <51D12692.4030002@artspark.co.jp> <CAK-G-KVLsECC4cETFYdcPyoqigaaoRhUxcezhMG3jZc2fAViRg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309052049070.7443@ps20323.dreamhostps.com> On Fri, 28 Jun 2013, Tom Wiltzius wrote: > > The only major Canvas2D features being actively developed in Chromium > right now are: > > - having a canvas context "alpha" attribute > - text decoration > - compositing and blending > - canvas access in workers > > (easily referenced from http://www.chromestatus.com/features) > > It is concerning to me that the list of other unimplemented features > that aren't being worked on could block the standardization of the above > (all of which have been discussed on this list at one point, but not all > of which are in the spec yet). > > How can we help reconcile this discrepancy? My goal is for the spec to match the browsers as closely as possible while providing direction for the next set of new features. >From my point of view, therefore, there's two ways to reconcile this discrepancy: either the browsers implement what's in the spec, or the spec changes to drop the things that aren't getting implemented. On Fri, 28 Jun 2013, Benoit Jacob wrote: > > Has the Canvas 2D community considered a WebGL-like model to the > introduction of additional features? > > By "the WebGL model", I mean: > - Define a core feature set that's conservative and limited, but > consistently implemented by all browsers. Enforce consistent support for > it by an exhaustive conformance test suite. That's the model we're trying to follow. > - Let any additional feature be an "extension". The goal is for there to be none of these. > - Consider, similar to WebGL, further tightening this process by letting > any new feature start at "draft" status and wait a bit before being > "approved". That doesn't work. Nobody cares if something is approved or not -- they'll use it if it works and it's what they want. Once people use it, it's not going anywhere, and the spec is de-facto frozen. > Typically, the difference that this makes is that "draft" extensions > would be exposed by browsers only "behind a flag" (a browser option > that's not enabled by default). Prerequisites for "approval" would > include: having been implemented and stable for some time, and being > covered by a conformance test. You can't tell if something is stable until people are using it, so hiding features behind a flag, once their implementation is complete, doesn't help. On Fri, 28 Jun 2013, Rik Cabanier wrote: > > If you can get them into 2 stable browsers, I'm very sure that Ian will add > it to the specification. > It seems that Ian is mostly concerned that we're adding more and more > features to the document but they are not being worked on. This makes the > WHATWG spec less useful since you can't tell what's implemented or not. (It > also makes a lot of useless work for Ian if he has to cut it later.) Precisely. > I think what's needed is that the person who proposes a feature and gets > it accepted on the mailing list, also needs to follow up and coordinate > with the browsers so it actually gets implemented. Certainly a one-browser feature is no good, specced or not. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From foolistbar at googlemail.com Thu Sep 5 15:08:04 2013 From: foolistbar at googlemail.com (Geoffrey Sneddon) Date: Thu, 05 Sep 2013 15:08:04 -0700 Subject: [whatwg] Parse errors for invalid characters Message-ID: <522900C4.2050409@googlemail.com> The phrasing content section states: > Text nodes and attribute values must consist of Unicode characters, must not contain U+0000 characters, must not contain permanently undefined Unicode characters (noncharacters), and must not contain control characters other than space characters. This specification includes extra constraints on the exact value of Text nodes and attribute values depending on their precise context. And the pre-processing the input-stream section states: > Any occurrences of any characters in the ranges U+0001 to U+0008, U+000E to U+001F, U+007F to U+009F, U+FDD0 to U+FDEF, and characters U+000B, U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, U+2FFFE, U+2FFFF, U+3FFFE, U+3FFFF, U+4FFFE, U+4FFFF, U+5FFFE, U+5FFFF, U+6FFFE, U+6FFFF, U+7FFFE, U+7FFFF, U+8FFFE, U+8FFFF, U+9FFFE, U+9FFFF, U+AFFFE, U+AFFFF, U+BFFFE, U+BFFFF, U+CFFFE, U+CFFFF, U+DFFFE, U+DFFFF, U+EFFFE, U+EFFFF, U+FFFFE, U+FFFFF, U+10FFFE, and U+10FFFF are parse errors. These are all control characters or permanently undefined Unicode characters (noncharacters). Note the first uses "Unicode characters", the second "characters" ? the former excludes surrogates as a conformance requirement. Note that every disallowed non-surrogate character is a parse error. Therefore, it would make sense to make surrogates parse errors. It should be noted that they can only occur in the input stream if they come from script (as they cannot be decoded from the input byte stream as the decoders will never emit a surrogate). /Geoffrey. From simon.sarris at gmail.com Thu Sep 5 15:19:30 2013 From: simon.sarris at gmail.com (Simon Sarris) Date: Thu, 5 Sep 2013 18:19:30 -0400 Subject: [whatwg] Adding 2D Canvas features In-Reply-To: <alpine.DEB.2.00.1309052049070.7443@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <51D12692.4030002@artspark.co.jp> <CAK-G-KVLsECC4cETFYdcPyoqigaaoRhUxcezhMG3jZc2fAViRg@mail.gmail.com> <alpine.DEB.2.00.1309052049070.7443@ps20323.dreamhostps.com> Message-ID: <CAA5isUYmMm9sHu=_Ybwmhw7GWfO+vRpP+8MdM_+OXKPCc+i4+Q@mail.gmail.com> Just FYI, Chrome now has a relatively new bug for "Canvas v5 API additions" that references all the missing features that some posters were concerned about. The default take from this bug report is that all of these are greenlighted to be worked on (no objections so far) https://code.google.com/p/chromium/issues/detail?id=281529 This bug is now (as of a few days ago) referenced at chromestatus.com under the Canvas feature's implementation status: http://www.chromestatus.com/features/5100084685438976 Simon From ian at hixie.ch Thu Sep 5 15:22:20 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 5 Sep 2013 22:22:20 +0000 (UTC) Subject: [whatwg] Blurry lines in 2D Canvas In-Reply-To: <CAGN7qDA8fe42MUR-Dt1sxtCnN=hPYLe6TcasSfjV+q+i-UmrjA@mail.gmail.com> References: <CAGN7qDAdABj2NCNcc53qDd23Twq2=999u0Sio-gEsBJURrpCcg@mail.gmail.com> <CAPeKFThd5HvtYFvokX=n7UR_Qs=wmqHy2vMFDoDs9y9Jd5jM=Q@mail.gmail.com> <CAGN7qDCOdadxurg5qp6q3UMygv0gjBNc5BoHOgtZKggD=5ppNQ@mail.gmail.com> <CABirCh_0orFzaZAUrtg3Z+Jg0LdSGMZxuapVdKZgigEdKJJVXQ@mail.gmail.com> <CAGN7qDDbS5Vy65SqiSdVtxgz8W9w+8WO3n=2H4wpSdkaQNLBCQ@mail.gmail.com> <CABirCh-NiwtSMzs5J5=cqazNYGAKufA3s1Lz1cW-6YvhGbt8pg@mail.gmail.com> <CAGN7qDBqXxY-aWmb3kWwxXh=rfD1BfHCEiESs9yHiFkpxkPFig@mail.gmail.com> <CABirCh9RSb0SEMsqy9KHEV77h7s04hgq7G6evCYLFRM10Kh+1A@mail.gmail.com> <CAGN7qDA8fe42MUR-Dt1sxtCnN=hPYLe6TcasSfjV+q+i-UmrjA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309052119410.7443@ps20323.dreamhostps.com> On Tue, 23 Jul 2013, Rik Cabanier wrote: > > we've noticed that if you draw lines in canvas or SVG, they always end > up blurry. For instance see this fiddle: http://jsfiddle.net/V92Gn/128/ Not always, only if you don't draw the line aligned with the pixel grid (e.g. you draw a diagonal line, or a horizontal or vertical line that isn't centered in the middle of pixels on the pixels grid, or a horizontal or vertical line whose width isn't an integral number of pixels, etc). The options, on a pixel grid display, are: - don't honour the position precisely -- this leads to very ugly artifacts when animating (lines jerk around), and basically means that the graphics aren't accurate. - instead of describing the shapes as vectors, describe them using programs that can adapt to the position and size they're being drawn at, such that they automatically snap to the pixel grid in a pretty fashion -- this is what fonts do. - try to trick the eye by using anti-aliasing when things don't line up exactly on the pixel grid. The first two really aren't plausible options for <canvas>. On Wed, 24 Jul 2013, Kornel Lesi?ski wrote: > > For 1-pixel lines it could be fixed by allowing authors to specify that > path should be stroked with lines aligned to inside/outside of the path > (which is a useful feature on its own). https://www.w3.org/Bugs/Public/show_bug.cgi?id=22674 On Tue, 23 Jul 2013, Rik Cabanier wrote: > > Sure, but how can we fix this? What is there to fix? The options above are basically the only options. You can't not do one of them -- there's no way to draw a crisp line that isn't pixel aligned. There's no pixels there. Similarly, there's no way to draw a line that's neither horizontal nor vertical yet is crisp and doesn't look jaggy. The pixels are squares, they don't rotate on modern pixel displays. On Wed, 24 Jul 2013, Kornel Lesi?ski wrote: > > Should arc() and bezier curves also be snapped? What if you want a line > that touches the curve? That's precisely the problem with snapping -- it is far worse than antialiasing. You can't draw precise shapes if you have snapping. On Wed, 24 Jul 2013, Dirk Schulze wrote: > > Means implementations would need to take viewport, transformations of > the document, transformations on elements in the DOM hierarchy, zoom > level, aspect ratio of the canvas, position of the canvas in the > document, transformations in the canvas and device pixel resolution into > account to snap lines to the correct position on the individual device, > right?Otherwise it sounds to be hard to guarantee that you don't see > antialiased strokes and lines might snap more then just one device > pixel. This would also be a problem for aligning shapes to each other in > the canvas I guess. What happens on the next transformation after a > drawing operation. Say you draw a line that was snapped to the grid and > then you do scale(1.1, 1.1). Shall the implementation redraw the canvas? > After all it is an pixel image. A vector based drawing format would be > better suited for such a task. Indeed. On Sat, 10 Aug 2013, Rik Cabanier wrote: > > I was wondering if this is something that happens in Flash as well. It > turns out that there's an option called "hinting: Keep stroke anchors on > full pixels to prevent blurry lines." There's a blog post on what this > does: > http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html > <http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html> > > I created an example (in flash sorry) that shows the feature: > http://cabanier.github.io/BlendExamples/pixelsnap/pixelsnap.html > 2 sets of strokes move across the screen and are also scaled. > > The top strokes behave like canvas does today. They start of blurry and > during the animation they slowly get ticker. For some reason it doesn't > look very smooth. > The bottom strokes have hinting turned on. They are sharp at the beginning > and during the animation they stay the same size until the internal stroke > width is large enough. At that point you see a 'jump'. > > I think canvas should have a similar feature... Can you elaborate on how exactly you would want this to work? How would you avoid the alignment and distortion problems when applying this to anything less trivial than a rectangle? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From cabanier at gmail.com Thu Sep 5 15:41:42 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Thu, 5 Sep 2013 15:41:42 -0700 Subject: [whatwg] Blurry lines in 2D Canvas In-Reply-To: <alpine.DEB.2.00.1309052119410.7443@ps20323.dreamhostps.com> References: <CAGN7qDAdABj2NCNcc53qDd23Twq2=999u0Sio-gEsBJURrpCcg@mail.gmail.com> <CAPeKFThd5HvtYFvokX=n7UR_Qs=wmqHy2vMFDoDs9y9Jd5jM=Q@mail.gmail.com> <CAGN7qDCOdadxurg5qp6q3UMygv0gjBNc5BoHOgtZKggD=5ppNQ@mail.gmail.com> <CABirCh_0orFzaZAUrtg3Z+Jg0LdSGMZxuapVdKZgigEdKJJVXQ@mail.gmail.com> <CAGN7qDDbS5Vy65SqiSdVtxgz8W9w+8WO3n=2H4wpSdkaQNLBCQ@mail.gmail.com> <CABirCh-NiwtSMzs5J5=cqazNYGAKufA3s1Lz1cW-6YvhGbt8pg@mail.gmail.com> <CAGN7qDBqXxY-aWmb3kWwxXh=rfD1BfHCEiESs9yHiFkpxkPFig@mail.gmail.com> <CABirCh9RSb0SEMsqy9KHEV77h7s04hgq7G6evCYLFRM10Kh+1A@mail.gmail.com> <CAGN7qDA8fe42MUR-Dt1sxtCnN=hPYLe6TcasSfjV+q+i-UmrjA@mail.gmail.com> <alpine.DEB.2.00.1309052119410.7443@ps20323.dreamhostps.com> Message-ID: <CAGN7qDC8hBPJc+HhRjgodkBAkhFEgJX0kAe=pMp9g3AnUm49Wg@mail.gmail.com> On Thu, Sep 5, 2013 at 3:22 PM, Ian Hickson <ian at hixie.ch> wrote: > On Tue, 23 Jul 2013, Rik Cabanier wrote: > > > > we've noticed that if you draw lines in canvas or SVG, they always end > > up blurry. For instance see this fiddle: http://jsfiddle.net/V92Gn/128/ > > Not always, only if you don't draw the line aligned with the pixel grid > (e.g. you draw a diagonal line, or a horizontal or vertical line that > isn't centered in the middle of pixels on the pixels grid, or a horizontal > or vertical line whose width isn't an integral number of pixels, etc). > > The options, on a pixel grid display, are: > > - don't honour the position precisely -- this leads to very ugly > artifacts when animating (lines jerk around), and basically means that > the graphics aren't accurate. > > - instead of describing the shapes as vectors, describe them using > programs that can adapt to the position and size they're being drawn > at, such that they automatically snap to the pixel grid in a pretty > fashion -- this is what fonts do. > > - try to trick the eye by using anti-aliasing when things don't line up > exactly on the pixel grid. > > The first two really aren't plausible options for <canvas>. > > > On Wed, 24 Jul 2013, Kornel Lesi?ski wrote: > > > > For 1-pixel lines it could be fixed by allowing authors to specify that > > path should be stroked with lines aligned to inside/outside of the path > > (which is a useful feature on its own). > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=22674 > > > On Tue, 23 Jul 2013, Rik Cabanier wrote: > > > > Sure, but how can we fix this? > > What is there to fix? The options above are basically the only options. > You can't not do one of them -- there's no way to draw a crisp line that > isn't pixel aligned. There's no pixels there. Similarly, there's no way to > draw a line that's neither horizontal nor vertical yet is crisp and > doesn't look jaggy. The pixels are squares, they don't rotate on modern > pixel displays. > > > On Wed, 24 Jul 2013, Kornel Lesi?ski wrote: > > > > Should arc() and bezier curves also be snapped? What if you want a line > > that touches the curve? > > That's precisely the problem with snapping -- it is far worse than > antialiasing. You can't draw precise shapes if you have snapping. > > > On Wed, 24 Jul 2013, Dirk Schulze wrote: > > > > Means implementations would need to take viewport, transformations of > > the document, transformations on elements in the DOM hierarchy, zoom > > level, aspect ratio of the canvas, position of the canvas in the > > document, transformations in the canvas and device pixel resolution into > > account to snap lines to the correct position on the individual device, > > right?Otherwise it sounds to be hard to guarantee that you don't see > > antialiased strokes and lines might snap more then just one device > > pixel. This would also be a problem for aligning shapes to each other in > > the canvas I guess. What happens on the next transformation after a > > drawing operation. Say you draw a line that was snapped to the grid and > > then you do scale(1.1, 1.1). Shall the implementation redraw the canvas? > > After all it is an pixel image. A vector based drawing format would be > > better suited for such a task. > > Indeed. > > > On Sat, 10 Aug 2013, Rik Cabanier wrote: > > > > I was wondering if this is something that happens in Flash as well. It > > turns out that there's an option called "hinting: Keep stroke anchors on > > full pixels to prevent blurry lines." There's a blog post on what this > > does: > > > http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html > > < > http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html > > > > > > I created an example (in flash sorry) that shows the feature: > > http://cabanier.github.io/BlendExamples/pixelsnap/pixelsnap.html > > 2 sets of strokes move across the screen and are also scaled. > > > > The top strokes behave like canvas does today. They start of blurry and > > during the animation they slowly get ticker. For some reason it doesn't > > look very smooth. > > The bottom strokes have hinting turned on. They are sharp at the > beginning > > and during the animation they stay the same size until the internal > stroke > > width is large enough. At that point you see a 'jump'. > > > > I think canvas should have a similar feature... > > Can you elaborate on how exactly you would want this to work? How would > you avoid the alignment and distortion problems when applying this to > anything less trivial than a rectangle? Basically, this would *just* move the control points and the width of paths so the strokes are always aligned to the pixel grid (This would take pixel density and transformations into account). After this, you would draw as usual. From barraclough at apple.com Thu Sep 5 15:45:55 2013 From: barraclough at apple.com (Gavin Barraclough) Date: Thu, 05 Sep 2013 15:45:55 -0700 Subject: [whatwg] [[GetOwnProperty]] for named properties of the Window object Message-ID: <52600B08-E2BB-4AA3-877E-797E1CF687BC@apple.com> Hi, I was wondering if anyone could help clarify expected behavior of [[GetOwnProperty]] for named properties of the Window object. (It looks like this falls across the HTML5 & WebIDL specs, apologies if this is the wrong place to ask). Per WebIDL?s definition of [Global] (http://dev.w3.org/2006/webapi/WebIDL/#Global) the named properties are exposed on a named properties object on the prototype chain. Per section 4.5.5.1 (http://dev.w3.org/2006/webapi/WebIDL/#named-properties-object) the [[GetOwnProperty]] implementation should return a descriptor with writable set to false, enumerable and configurable set to true. Firefox and Chrome both return descriptors from an object on the prototype chain per the spec, attributes of the value are configured differently, with enumerable set to false, writable and configurable set to true. There seem to be some compelling reasons to follow Firefox / Chrome (writable true seems more congruent with ECMA262 specified [[Put]], unless there is another mechanism I?m missing here, enumerable is odd since I don?t think the spec says anything about [[GetOwnPropertyNames]]),so I was hoping to better understand why the spec requires the behaviour it does (or whether I?m just following it incorrectly!) Many thanks, Gavin From cabanier at gmail.com Thu Sep 5 15:56:43 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Thu, 5 Sep 2013 15:56:43 -0700 Subject: [whatwg] Path API feedback In-Reply-To: <alpine.DEB.2.00.1308202232540.27209@ps20323.dreamhostps.com> References: <CAGN7qDATVtL08NLKvYsL+WVzGYn5fy3WxdQLQYqpB55NuhyL3g@mail.gmail.com> <Pine.LNX.4.64.1304260027360.3512@ps20323.dreamhostps.com> <CAGN7qDBcC7aPD1BcuDHbvMavfM3ez0CufFWgaLHcaPHBsuoNrA@mail.gmail.com> <alpine.DEB.2.00.1308202232540.27209@ps20323.dreamhostps.com> Message-ID: <CAGN7qDDXqyZt2gkmttoUps3qgEUiesBdpGmhotUhk4Ay6S_PVQ@mail.gmail.com> On Tue, Aug 20, 2013 at 3:36 PM, Ian Hickson <ian at hixie.ch> wrote: > On Fri, 26 Apr 2013, Rik Cabanier wrote: > > > > I think an author would expect that 'addPathByStrokingPath' and other > > path methods render as if you stroked/outlined directly on the canvas > > context. Same goes for 'addPath'. > > > > I believe very few people actually want the current behavior that's in > > the spec. > > I don't know how true that is. > > It seems logical to me that this: > > context.beginPath(); > context.rect(0,0,100,100); > context.rect(50,50,150,150); > context.fill(); > > ...should do the same as this: > > var p1 = new Path(); > p1.rect(0,0,100,100); > var p2 = new Path();s > p2.rect(50,50,150,150); > var p = new Path(); > p.addPath(p1); > p.addPath(p2); > context.fill(p); > > ...for any combination of path commands where I've put the rect()s. > Yes, that would be reasonable behavior since a path is just an aggregation of segments. The problem happens when you call fill or stroke multiple times. For instance: context.beginPath(); context.rect(0,0,100,100); context.fill(); context.beginPath(); context.rect(200,50,-150,150); context.fill(); Now I want to create a region that covers what was drawn. p1.rect(0,0,100,100); var p2 = new Path();s p2.rect(200,50,-150,150); var p = new Path(); p.addPath(p1); p.addPath(p2); 'p' won't describe the same area as what was filled. > > > > > I think the spec needs to mention that > > > > - sections of the path where both edges are filled should be removed > > > > - winding needs to be done so eofill and fill give the same result > > > > > > I've filed a bug for adding something like this: > > > > > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=21835 > > > > > > I'm not sure exactly what the algorithm should be (as we discussed on > > > IRC today), so if anyone has any input here, please don't hesitate to > > > comment. > > > > I can help if needed. I know the skia people are working on this as > > well. > > > > The algorithm is fairly straightforward to describe in prose. > > Implementation is very hard though... > > Please do add such help as comments on the bug, that would be very > helpful. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > From wiltzius at chromium.org Thu Sep 5 16:33:24 2013 From: wiltzius at chromium.org (Tom Wiltzius) Date: Thu, 5 Sep 2013 16:33:24 -0700 Subject: [whatwg] Adding 2D Canvas features In-Reply-To: <CAA5isUYmMm9sHu=_Ybwmhw7GWfO+vRpP+8MdM_+OXKPCc+i4+Q@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <51D12692.4030002@artspark.co.jp> <CAK-G-KVLsECC4cETFYdcPyoqigaaoRhUxcezhMG3jZc2fAViRg@mail.gmail.com> <alpine.DEB.2.00.1309052049070.7443@ps20323.dreamhostps.com> <CAA5isUYmMm9sHu=_Ybwmhw7GWfO+vRpP+8MdM_+OXKPCc+i4+Q@mail.gmail.com> Message-ID: <CAK-G-KUOzNXhRfZRTtmuYFHHcHDriSodcRmoORGqi4XhFevNuQ@mail.gmail.com> On Thu, Sep 5, 2013 at 3:19 PM, Simon Sarris <simon.sarris at gmail.com> wrote: > Just FYI, Chrome now has a relatively new bug for "Canvas v5 API > additions" that references all the missing features that some posters were > concerned about. > > The default take from this bug report is that all of these are > greenlighted to be worked on (no objections so far) > > https://code.google.com/p/chromium/issues/detail?id=281529 > > This bug is now (as of a few days ago) referenced at chromestatus.comunder the Canvas feature's implementation status: > > http://www.chromestatus.com/features/5100084685438976 > Yes, although that's probably somewhat misleading as the Chromium contributor who volunteered to help implement those is only human and it's a rather long list. I'll be working with him to prioritize, but it's not like suddenly these can all happen. Meanwhile this doesn't change the other Canvas2D-related work ongoing in the Chromium project, so we're still keen to see some new features added to the Canvas spec. Ian if it would help to identify items in the spec that Chromium doesn't intend to implement (at least any time soon), we can attempt to do so. > > > Simon > From jacob.benoit.1 at gmail.com Thu Sep 5 18:39:51 2013 From: jacob.benoit.1 at gmail.com (Benoit Jacob) Date: Thu, 5 Sep 2013 21:39:51 -0400 Subject: [whatwg] Challenging canvas.supportsContext In-Reply-To: <alpine.DEB.2.00.1309032240300.7443@ps20323.dreamhostps.com> References: <CAJTmd9rkwsjC+WDfLr7um0=h8Pvtg9JOJCRHzH4PhdbXjgpaaA@mail.gmail.com> <CAJTmd9q-eH8fnZSP5mr3kX-quyQcNXnyXTh5o_hX+MdfuXfrGQ@mail.gmail.com> <alpine.DEB.2.00.1309032240300.7443@ps20323.dreamhostps.com> Message-ID: <CAJTmd9q+Zyh=Fz3mRwBDBfy5q+mR5tVoNTv+rEtKJueQv2mfwg@mail.gmail.com> (I want to be clear that the long delay hinders my ability to continue this conversation. I'm just one regular Mozilla developer --- I'm not supposed to be spending a lot of time discussing the canvas standard, and right now, I can't really afford to. Back when I started this thread in june, I did have some time to invest in a long conversation on this. Right now I don't.) Some partial inline responses below. 2013/9/3 Ian Hickson <ian at hixie.ch> > > The long and short of this is that I renamed "supportsContext()" to > "probablySupportsContext()". It's already implemented in WebKit And that's the real cost of having accepted supportsContext too early in the HTML spec. > Fundamentally, it addresses a need that none of the other proposals > addressed: how to know whether or not you can expect to be able to do 3D. > It's not 100% reliable, but then neither would actually attempting to > create a context, because creating a context is so expensive on some > platforms that some UAs are going to move to doing it lazily > The only conformant way to do lazy context creation would be to have getContext return lost contexts, but given that only a tiny minority of real-world code cares about that concept, that's not going to be feasible in the foreseeable future. Maybe in a few years, optimistically. > > > On Wed, 19 Jun 2013, Benoit Jacob wrote: > > > > I'd like to question the usefulness of canvas.supportsContext. I tried to > > think of an actual application use case for it, and couldn't find one. > > The use case is libraries like Modernizr that want to do feature detection > up-front, but don't want a high performance hit on startup. > > > > However, that only shifts the question to: what is the reason for them > > to expose such APIs? In the end, I claim that the only thing that we > > should recognize as a reason to add a feature to the HTML spec, is > > *application* use cases. > > Oh well the use case for knowing whether or not 3D is supported on a > particular device is straight-forward: you want to know which set of > assets and logic to download and run. > Application developer wants things. But these are not necessarily good ideas, because they may not reflect how things really work. More below. > > > > So let's look at the naive application usage pattern for supportsContext: > > > > if (canvas.supportsContext("webgl")) { > > context = canvas.getContext("webgl"); > > } > > > > The problem is that the same can be achieved with just the getContext > > call, and checking whether it succeeded. > > Suppose you have an app that has a 3D feature, but it's not immediately > used upon startup. For example, a preview window that is displayed on > request. You want to preload all the code to run the preview window, but > you need to load different code based on whether the device can do 3D or > not. So the use case is more: > > if (canvas.supportsContext("webgl")) > load3DCode(); > else > load2DCode(); > > // 3D code: > function run() { > context = canvas.getContext("webgl"); > // ... > } > If now application developers call probablySupportsContext, it returns true, they start downloading the WebGL assets, but getContext("webgl") fails, their application startup experience will be wose, which will pressure browser developers to optimize the accuracy of probablySupportsContext, but that's going to be hard and unrewarding. So my best hope is that application developers don't use probablySupportsContext. Instead, they should do their actual getContext call --- the one creating the context that they will actually want to use --- right at the beginning of their application startup, and download the right assets based on the outcome of that getContext. The downside of course is that assets download becomes gated on getContext returning. But in practice that's not too bad: - Only the first getContext in a browser sessing can be really slow (say 100 ms), subsequent ones tend to take less than 5 ms --- not that much compared to the time to download big assets. - If any assets are shared between the two code paths, they can be downloaded first while getContext is running. > > You don't want to pay the cost of creating a throw-away 3D context on > startup just to know which scripts to load. It defeats the whole point of > not loading all the code up-front. > I'm not talking about having any throw-away 3d contexts just for testing. I understand that modernizr has an API that would force it to be implemented in that way. In my view, that makes it a bad API. There should be only one context, the one that we actually want to use. > > > > Outside of exceptional cases (out of memory...), the slow path in > > getContext is the *success* case, and again, in that case a real > > application would want to actually *use* that context. > > Not necessarily, as noted above. The <canvas> you're going to draw to > might not even exist at the point you need to know if it's 3D or not. > Precisely, that's my point: don't cater to the pathological use-a-separate-throwaway-context use case, instead assume that people are smart and that if the first getContext succeeds, they will use that context. > > > > Keep in mind that supportsContext can't guarantee that if it returns > true, > > then a subsequent getContext will succeed. > > Sure. getContext() can't guarantee that if it returns a context, the > context will work forever, either. > Indeed, there is some non-determinism inherent to how GPUs work. I'm just talking about not adding more non-determinism to it. > > > Given such deep problems, I think that the usefulness bar for accepting > > supportsContext into the spec should be quite high. > > The problem is that there's no alternative solution. > As I've been advocating, there is a more reasonable alternative which is not to have anything else than getContext. Benoit From bzbarsky at MIT.EDU Thu Sep 5 18:50:33 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Thu, 05 Sep 2013 21:50:33 -0400 Subject: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments In-Reply-To: <CADnb78jxE5B2KTYXj0QBv0GSoGddb=Gbxym5Cp5tYxm7zMG1aA@mail.gmail.com> References: <20130628201946.26920@gmx.com> <CADnb78jxE5B2KTYXj0QBv0GSoGddb=Gbxym5Cp5tYxm7zMG1aA@mail.gmail.com> Message-ID: <522934E9.5070603@mit.edu> On 9/5/13 6:02 AM, Anne van Kesteren wrote: > Having said that, our current plan is to rely on the Selectors API (2) In that case I think we need to add a function to the platform that CSS-escapes a string. Because right now, writing querySelector("#" + id) is a total footgun unless you control the id. In particular, if you're a library you're in trouble... > but the hope is that .querySelector("#test") will be fast > enough. As I explained in the thread, they have quite different behavior: getElementById takes the ID, but querySelector needs a CSS-escaped form of the ID. I'm happy to raise this point on www-dom if you want. Just let me know. -Boris From bzbarsky at MIT.EDU Thu Sep 5 18:57:37 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Thu, 05 Sep 2013 21:57:37 -0400 Subject: [whatwg] Alignment of empty buttons In-Reply-To: <alpine.DEB.2.00.1309052044160.22377@ps20323.dreamhostps.com> References: <CAPTJ0XEA_NMAB41UHg1cXXmQTRsxg2zhd9LCuSS2b6R2ZBSVig@mail.gmail.com> <CAPTJ0XE1337+UqNC4D9gpuWO6QHQ7gHc+x8y08SYjCJmghzEag@mail.gmail.com> <51846106.2060403@mit.edu> <alpine.DEB.2.00.1307122007550.15729@ps20323.dreamhostps.com> <51E06313.8030105@mit.edu> <alpine.DEB.2.00.1309050004230.7443@ps20323.dreamhostps.com> <522814AD.8000901@mit.edu> <alpine.DEB.2.00.1309052044160.22377@ps20323.dreamhostps.com> Message-ID: <52293691.90301@mit.edu> On 9/5/13 4:47 PM, Ian Hickson wrote: > In what sense? In the sense that if its computed display is "block" but its layout behavior is not that of a non-replaced block (CSS 2.1 section 10.3.3 and so forth), then it's clearly a replaced element with layout behavior defined by something other than CSS. > The definition of "replaced element" here: > > http://www.w3.org/TR/CSS2/conform.html#replaced-element > > ...doesn't seem to apply to <button>. The rendering of <button> is very > much in CSS' scope, no? Sure doesn't seem to be, since no UA actually renders <button style="display: block"> the way a CSS block renders; they do something totally different which is presumably covered by some other spec (e.g. HTML). -Boris From bzbarsky at MIT.EDU Thu Sep 5 19:15:34 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Thu, 05 Sep 2013 22:15:34 -0400 Subject: [whatwg] [[GetOwnProperty]] for named properties of the Window object In-Reply-To: <52600B08-E2BB-4AA3-877E-797E1CF687BC@apple.com> References: <52600B08-E2BB-4AA3-877E-797E1CF687BC@apple.com> Message-ID: <52293AC6.5020108@mit.edu> Ccing public-script-coord, since that's the right place for this discussion (because WebIDL is the relevant specification). On 9/5/13 6:45 PM, Gavin Barraclough wrote: > Firefox and Chrome both return descriptors from an object on the prototype chain per the spec Chrome doesn't quite follow the spec here, for what it's worth: it returns them from Window.prototype as far as I can tell, not from an actual named properties object. > attributes of the value are configured differently, with enumerable set to false, writable and configurable set to true. Current tip Firefox returns {"configurable":true,"enumerable":true,"writable":true} and enumerates the properties. Probably a change from https://bugzilla.mozilla.org/show_bug.cgi?id=895758 to align better with the spec in terms of the enumeration behavior. > There seem to be some compelling reasons to follow Firefox / Chrome (writable true seems more congruent with ECMA262 specified [[Put]] Indeed. I think the current setup in the spec would make window.foo not settable if <img id="foo"> exists.... That seems bad. > unless there is another mechanism I?m missing here, enumerable is odd since I don?t think the spec says anything about [[GetOwnPropertyNames]]) It doesn't, but it does talk about enumeration; see http://dev.w3.org/2006/webapi/WebIDL/#property-enumeration (whether that's applicable to the Named Properties Object is an interesting question). Granted, I would rather that were defined in terms of [[GetOwnPropertyNames]] on the relevant objects instead; that's what actually needs to happen under the hood anyway. > ,so I was hoping to better understand why the spec requires the behaviour it does (or whether I?m just following it incorrectly!) I think you're following it correctly; it's just buggy. ;) -Boris From kanghaol at oupeng.com Thu Sep 5 20:05:56 2013 From: kanghaol at oupeng.com (Kang-Hao (Kenny) Lu) Date: Fri, 06 Sep 2013 11:05:56 +0800 Subject: [whatwg] Parse errors for invalid characters In-Reply-To: <522900C4.2050409@googlemail.com> References: <522900C4.2050409@googlemail.com> Message-ID: <52294694.9080309@oupeng.com> (2013/09/06 6:08), Geoffrey Sneddon wrote: > The phrasing content section states: > >> Text nodes and attribute values must consist of Unicode characters, >> must not contain U+0000 characters, must not contain permanently >> undefined Unicode characters (noncharacters), and must not contain >> control characters other than space characters. This specification >> includes extra constraints on the exact value of Text nodes and >> attribute values depending on their precise context. > > And the pre-processing the input-stream section states: > >> Any occurrences of any characters in the ranges U+0001 to U+0008, >> U+000E to U+001F, U+007F to U+009F, U+FDD0 to U+FDEF, and characters >> U+000B, U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, U+2FFFE, U+2FFFF, U+3FFFE, >> U+3FFFF, U+4FFFE, U+4FFFF, U+5FFFE, U+5FFFF, U+6FFFE, U+6FFFF, >> U+7FFFE, U+7FFFF, U+8FFFE, U+8FFFF, U+9FFFE, U+9FFFF, U+AFFFE, >> U+AFFFF, U+BFFFE, U+BFFFF, U+CFFFE, U+CFFFF, U+DFFFE, U+DFFFF, >> U+EFFFE, U+EFFFF, U+FFFFE, U+FFFFF, U+10FFFE, and U+10FFFF are parse >> errors. These are all control characters or permanently undefined >> Unicode characters (noncharacters). > > Note the first uses "Unicode characters", the second "characters" ? the > former excludes surrogates as a conformance requirement. > > Note that every disallowed non-surrogate character is a parse error. Except U+0000 or am I missing something? > Therefore, it would make sense to make surrogates parse errors. > > It should be noted that they can only occur in the input stream if they > come from script (as they cannot be decoded from the input byte stream > as the decoders will never emit a surrogate). which means that this seems ... cubersome ... to implement in a conformance checker. Which reminds me, does # Conformance checkers must report at least one parse error # condition to the user if one or more parse error conditions exist # in the document and must not report parse error conditions if none # exist in the document. Conformance checkers may report more than # one parse error condition if more than one parse error condition # exists in the document. mean validator.nu and Firefox view source are non-conforming because they do nothing about document.write() ? I think we should exempt conformance checkers from scripts instead. Cheers, Kenny -- Web Specialist, Opera Sphinx Game Force, Oupeng Browser, Beijing Try Oupeng: http://www.oupeng.com/ From cabanier at gmail.com Thu Sep 5 20:48:54 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Thu, 5 Sep 2013 20:48:54 -0700 Subject: [whatwg] Stroking algorithm in Canvas 2d Message-ID: <CAGN7qDA-iib4SULW-JDf4_vpsyuxpg1m8AkXq=qgDtY1OkXahA@mail.gmail.com> All, we've looked over the algorithm in the Canvas spec that describes how strokes are computed. [1] We think that this section is making some incorrect assumptions. For instance, the dashes are calculated over the total lenght of all subpaths, but each subpath should be treated separately. It's also a bit strange that the spec is trying to describe how to stroke. For instance, it goes in minute detail on how dashes are applied but the hardest part of stroking ("inflating the paths in path perpendicular to the direction") is not described at all. Wouldn't it be better to remove all these steps and simply show the desired effect? If not, what would be the best way to fix the wording? The mailing list or a bug? 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#trace-a-path From annevk at annevk.nl Fri Sep 6 04:22:34 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Fri, 6 Sep 2013 12:22:34 +0100 Subject: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments In-Reply-To: <522934E9.5070603@mit.edu> References: <20130628201946.26920@gmx.com> <CADnb78jxE5B2KTYXj0QBv0GSoGddb=Gbxym5Cp5tYxm7zMG1aA@mail.gmail.com> <522934E9.5070603@mit.edu> Message-ID: <CADnb78iJVBVomf_hiWQOSHc6Umh+UwqjjwKLbathV54XFm3-uQ@mail.gmail.com> On Fri, Sep 6, 2013 at 2:50 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote: > In that case I think we need to add a function to the platform that > CSS-escapes a string. Maybe a thing for window.CSS? Simon? Such a function already exists in the wild btw: http://mothereff.in/css-escapes -- http://annevankesteren.nl/ From simonp at opera.com Fri Sep 6 05:20:01 2013 From: simonp at opera.com (Simon Pieters) Date: Fri, 06 Sep 2013 14:20:01 +0200 Subject: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments In-Reply-To: <CADnb78iJVBVomf_hiWQOSHc6Umh+UwqjjwKLbathV54XFm3-uQ@mail.gmail.com> References: <20130628201946.26920@gmx.com> <CADnb78jxE5B2KTYXj0QBv0GSoGddb=Gbxym5Cp5tYxm7zMG1aA@mail.gmail.com> <522934E9.5070603@mit.edu> <CADnb78iJVBVomf_hiWQOSHc6Umh+UwqjjwKLbathV54XFm3-uQ@mail.gmail.com> Message-ID: <op.w2zojngdidj3kv@simons-macbook-pro.local> On Fri, 06 Sep 2013 13:22:34 +0200, Anne van Kesteren <annevk at annevk.nl> wrote: > On Fri, Sep 6, 2013 at 2:50 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote: >> In that case I think we need to add a function to the platform that >> CSS-escapes a string. > > Maybe a thing for window.CSS? Simon? > > Such a function already exists in the wild btw: > http://mothereff.in/css-escapes So the use case is getting an element by id with an "untrusted" id as input, in an element or document fragment as opposed to the document? -- Simon Pieters Opera Software From scott.gonzalez at gmail.com Fri Sep 6 05:21:24 2013 From: scott.gonzalez at gmail.com (=?ISO-8859-1?Q?Scott_Gonz=E1lez?=) Date: Fri, 6 Sep 2013 08:21:24 -0400 Subject: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments In-Reply-To: <op.w2zojngdidj3kv@simons-macbook-pro.local> References: <20130628201946.26920@gmx.com> <CADnb78jxE5B2KTYXj0QBv0GSoGddb=Gbxym5Cp5tYxm7zMG1aA@mail.gmail.com> <522934E9.5070603@mit.edu> <CADnb78iJVBVomf_hiWQOSHc6Umh+UwqjjwKLbathV54XFm3-uQ@mail.gmail.com> <op.w2zojngdidj3kv@simons-macbook-pro.local> Message-ID: <CAO8i3iet-6D+j3Z=UQ6r7EHvxTW1PxSz1yiAEejwdf4ztVYCuA@mail.gmail.com> On Fri, Sep 6, 2013 at 8:20 AM, Simon Pieters <simonp at opera.com> wrote: > So the use case is getting an element by id with an "untrusted" id as > input, in an element or document fragment as opposed to the document? > Yes. Take the example of finding the input associated with a label: <label for="foo">foo</label> <input id="foo"> If you have a reference to the label and you want to find the input, you need to escape the value of the for attribute before querying. From simonp at opera.com Fri Sep 6 05:40:00 2013 From: simonp at opera.com (Simon Pieters) Date: Fri, 06 Sep 2013 14:40:00 +0200 Subject: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments In-Reply-To: <CAO8i3iet-6D+j3Z=UQ6r7EHvxTW1PxSz1yiAEejwdf4ztVYCuA@mail.gmail.com> References: <20130628201946.26920@gmx.com> <CADnb78jxE5B2KTYXj0QBv0GSoGddb=Gbxym5Cp5tYxm7zMG1aA@mail.gmail.com> <522934E9.5070603@mit.edu> <CADnb78iJVBVomf_hiWQOSHc6Umh+UwqjjwKLbathV54XFm3-uQ@mail.gmail.com> <op.w2zojngdidj3kv@simons-macbook-pro.local> <CAO8i3iet-6D+j3Z=UQ6r7EHvxTW1PxSz1yiAEejwdf4ztVYCuA@mail.gmail.com> Message-ID: <op.w2zpgyomidj3kv@simons-macbook-pro.local> On Fri, 06 Sep 2013 14:21:24 +0200, Scott Gonz?lez <scott.gonzalez at gmail.com> wrote: > On Fri, Sep 6, 2013 at 8:20 AM, Simon Pieters <simonp at opera.com> wrote: > >> So the use case is getting an element by id with an "untrusted" id as >> input, in an element or document fragment as opposed to the document? >> > > Yes. Take the example of finding the input associated with a label: > > <label for="foo">foo</label> > <input id="foo"> > > If you have a reference to the label and you want to find the input, you > need to escape the value of the for attribute before querying. In this example, are the elements in the document? -- Simon Pieters Opera Software From scott.gonzalez at gmail.com Fri Sep 6 05:43:14 2013 From: scott.gonzalez at gmail.com (=?ISO-8859-1?Q?Scott_Gonz=E1lez?=) Date: Fri, 6 Sep 2013 08:43:14 -0400 Subject: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments In-Reply-To: <op.w2zpgyomidj3kv@simons-macbook-pro.local> References: <20130628201946.26920@gmx.com> <CADnb78jxE5B2KTYXj0QBv0GSoGddb=Gbxym5Cp5tYxm7zMG1aA@mail.gmail.com> <522934E9.5070603@mit.edu> <CADnb78iJVBVomf_hiWQOSHc6Umh+UwqjjwKLbathV54XFm3-uQ@mail.gmail.com> <op.w2zojngdidj3kv@simons-macbook-pro.local> <CAO8i3iet-6D+j3Z=UQ6r7EHvxTW1PxSz1yiAEejwdf4ztVYCuA@mail.gmail.com> <op.w2zpgyomidj3kv@simons-macbook-pro.local> Message-ID: <CAO8i3ifim0vvaA_vG_FfjkkirWHUYB--MHrXidr54exFvd-FtA@mail.gmail.com> On Fri, Sep 6, 2013 at 8:40 AM, Simon Pieters <simonp at opera.com> wrote: > On Fri, 06 Sep 2013 14:21:24 +0200, Scott Gonz?lez < > scott.gonzalez at gmail.com> wrote: > >> Yes. Take the example of finding the input associated with a label: >> >> <label for="foo">foo</label> >> <input id="foo"> >> >> If you have a reference to the label and you want to find the input, you >> need to escape the value of the for attribute before querying. >> > > In this example, are the elements in the document? For jQuery, the answer tends to be "it doesn't matter." There are very few places where we treat in-document and out-of-document situations differently. From scott.gonzalez at gmail.com Fri Sep 6 05:47:56 2013 From: scott.gonzalez at gmail.com (=?ISO-8859-1?Q?Scott_Gonz=E1lez?=) Date: Fri, 6 Sep 2013 08:47:56 -0400 Subject: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments In-Reply-To: <CAAWBYDDi9s9+6v3RQfugDR=nRXrtV=7xZUBuFcMxUiU1+wN-cQ@mail.gmail.com> References: <20130628212857.262740@gmx.com> <CAAWBYDDi9s9+6v3RQfugDR=nRXrtV=7xZUBuFcMxUiU1+wN-cQ@mail.gmail.com> Message-ID: <CAO8i3icHF=MeWrzPGL2j2-tvfx4XauhdUQDKMZgKiy6pSjxj2w@mail.gmail.com> On Fri, Jun 28, 2013 at 6:51 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote: > On Fri, Jun 28, 2013 at 2:28 PM, Zirak A <zirak at mail.com> wrote: > > Besides my personal aversion towards selectors being in the DOM API, > there's > > also the simple fact that it makes sense for document fragments to have > these > > methods. > > That's far from obvious, given that I don't think it makes sense to > spread those obsolete methods around any further. They were already spread to ShadowRoot. Does anyone have a reference to that discussion that led to that decision? It seems like if they're being added to ShadowRoot, which inherits from DocumentFragment, we might as well just add them to DocumentFragment and be done with it. At least from a non-implementor's view that seems to make sense. From simonp at opera.com Fri Sep 6 05:59:06 2013 From: simonp at opera.com (Simon Pieters) Date: Fri, 06 Sep 2013 14:59:06 +0200 Subject: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments In-Reply-To: <CAO8i3ifim0vvaA_vG_FfjkkirWHUYB--MHrXidr54exFvd-FtA@mail.gmail.com> References: <20130628201946.26920@gmx.com> <CADnb78jxE5B2KTYXj0QBv0GSoGddb=Gbxym5Cp5tYxm7zMG1aA@mail.gmail.com> <522934E9.5070603@mit.edu> <CADnb78iJVBVomf_hiWQOSHc6Umh+UwqjjwKLbathV54XFm3-uQ@mail.gmail.com> <op.w2zojngdidj3kv@simons-macbook-pro.local> <CAO8i3iet-6D+j3Z=UQ6r7EHvxTW1PxSz1yiAEejwdf4ztVYCuA@mail.gmail.com> <op.w2zpgyomidj3kv@simons-macbook-pro.local> <CAO8i3ifim0vvaA_vG_FfjkkirWHUYB--MHrXidr54exFvd-FtA@mail.gmail.com> Message-ID: <op.w2zqcszwidj3kv@simons-macbook-pro.local> On Fri, 06 Sep 2013 14:43:14 +0200, Scott Gonz?lez <scott.gonzalez at gmail.com> wrote: > For jQuery, the answer tends to be "it doesn't matter." There are very > few > places where we treat in-document and out-of-document situations > differently. OK. There's http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#dom-label-control but it only works when in a document. Maybe that should be changed, though. -- Simon Pieters Opera Software From junov at google.com Fri Sep 6 07:11:57 2013 From: junov at google.com (Justin Novosad) Date: Fri, 6 Sep 2013 10:11:57 -0400 Subject: [whatwg] Stroking algorithm in Canvas 2d In-Reply-To: <CAGN7qDA-iib4SULW-JDf4_vpsyuxpg1m8AkXq=qgDtY1OkXahA@mail.gmail.com> References: <CAGN7qDA-iib4SULW-JDf4_vpsyuxpg1m8AkXq=qgDtY1OkXahA@mail.gmail.com> Message-ID: <CABpaAqQFx71oeoF3_vqCZnSqhnrVTMEgZzn8FYdM8QPnYHWZcQ@mail.gmail.com> On Thu, Sep 5, 2013 at 11:48 PM, Rik Cabanier <cabanier at gmail.com> wrote: > All, > > we've looked over the algorithm in the Canvas spec that describes how > strokes are computed. [1] > We think that this section is making some incorrect assumptions. For > instance, the dashes are calculated over the total lenght of all subpaths, > but each subpath should be treated separately. > Why? Don't we want there to be continuity in the dash pattern across joins? Especially considering that step 3 of the algorithm breaks all subpaths into elementary line segment subpaths. Or am I misunderstanding your comment? > It's also a bit strange that the spec is trying to describe how to stroke. > For instance, it goes in minute detail on how dashes are applied but the > hardest part of stroking ("inflating the paths in path perpendicular to the > direction") is not described at all. Wouldn't it be better to remove all > these steps and simply show the desired effect? > I agree. I think it would be clearer if the spec focused on what the expected output is. I see the current algorithm-based specification as unnecessarily challenging for implementors and web developers alike. The challenge for implementors is that this algorithm in unlikely to be implemented exactly as is since implementors will want to leverage services, respect constraints, and consider performance characteristics of the graphics APIs they are using. In other words, implementors are likely to have to figure-out alternate algorithms that produce equivalent results, which means they have to start by reverse-engineering the spec in order to figure-out what the desired output is. Reverse-engineering the spec is also necessary just for writing conformance tests. The algorithm in itself is still very useful as an example of how the spec could be implemented. FWIW, In general I have no issue with other parts of the spec that are specified as algorithms. It is just this one that I find particularly unwieldy. If not, what would be the best way to fix the wording? The mailing list or > a bug? > > 1: > > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#trace-a-path > From bzbarsky at MIT.EDU Fri Sep 6 07:42:47 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Fri, 06 Sep 2013 10:42:47 -0400 Subject: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments In-Reply-To: <op.w2zojngdidj3kv@simons-macbook-pro.local> References: <20130628201946.26920@gmx.com> <CADnb78jxE5B2KTYXj0QBv0GSoGddb=Gbxym5Cp5tYxm7zMG1aA@mail.gmail.com> <522934E9.5070603@mit.edu> <CADnb78iJVBVomf_hiWQOSHc6Umh+UwqjjwKLbathV54XFm3-uQ@mail.gmail.com> <op.w2zojngdidj3kv@simons-macbook-pro.local> Message-ID: <5229E9E7.3040404@mit.edu> On 9/6/13 8:20 AM, Simon Pieters wrote: > So the use case is getting an element by id with an "untrusted" id as > input, in an element or document fragment as opposed to the document? Or getting elements by tag name in a document fragment, for that matter (though "weird" chars in tag names are harder to produce; largely limited to leading digits). -Boris From cabanier at gmail.com Fri Sep 6 11:24:53 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Fri, 6 Sep 2013 11:24:53 -0700 Subject: [whatwg] Stroking algorithm in Canvas 2d In-Reply-To: <CABpaAqQFx71oeoF3_vqCZnSqhnrVTMEgZzn8FYdM8QPnYHWZcQ@mail.gmail.com> References: <CAGN7qDA-iib4SULW-JDf4_vpsyuxpg1m8AkXq=qgDtY1OkXahA@mail.gmail.com> <CABpaAqQFx71oeoF3_vqCZnSqhnrVTMEgZzn8FYdM8QPnYHWZcQ@mail.gmail.com> Message-ID: <CAGN7qDDwTbMuutK_C7QFCezA78rQtRCCaRjTL=FzBLqgUCUcSw@mail.gmail.com> On Fri, Sep 6, 2013 at 7:11 AM, Justin Novosad <junov at google.com> wrote: > > > > On Thu, Sep 5, 2013 at 11:48 PM, Rik Cabanier <cabanier at gmail.com> wrote: > >> All, >> >> we've looked over the algorithm in the Canvas spec that describes how >> strokes are computed. [1] >> We think that this section is making some incorrect assumptions. For >> instance, the dashes are calculated over the total lenght of all subpaths, >> but each subpath should be treated separately. >> > > Why? Don't we want there to be continuity in the dash pattern across > joins? Especially considering that step 3 of the algorithm breaks all > subpaths into elementary line segment subpaths. Or am I misunderstanding > your comment? > Maybe. The spec currently says: 1. Let width be the aggregate length of all the lines of all the subpaths in path, in coordinate space units. For dashing, each subpath should be treated separately. There shouldn't be a step that takes the total length of all subpaths. You are correct that dashing should result in a new series of subpaths that are then stroked (with joins and endcaps) usual. > >> It's also a bit strange that the spec is trying to describe how to stroke. >> For instance, it goes in minute detail on how dashes are applied but the >> hardest part of stroking ("inflating the paths in path perpendicular to >> the >> direction") is not described at all. Wouldn't it be better to remove all >> these steps and simply show the desired effect? >> > > I agree. I think it would be clearer if the spec focused on what the > expected output is. I see the current algorithm-based specification as > unnecessarily challenging for implementors and web developers alike. The > challenge for implementors is that this algorithm in unlikely to be > implemented exactly as is since implementors will want to leverage > services, respect constraints, and consider performance characteristics of > the graphics APIs they are using. In other words, implementors are likely > to have to figure-out alternate algorithms that produce equivalent results, > which means they have to start by reverse-engineering the spec in order to > figure-out what the desired output is. Reverse-engineering the spec is also > necessary just for writing conformance tests. The algorithm in itself is > still very useful as an example of how the spec could be implemented. > > FWIW, In general I have no issue with other parts of the spec that are > specified as algorithms. It is just this one that I find particularly > unwieldy. > > If not, what would be the best way to fix the wording? The mailing list or >> a bug? >> >> 1: >> >> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#trace-a-path >> > > From jackalmage at gmail.com Fri Sep 6 11:54:11 2013 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Fri, 6 Sep 2013 11:54:11 -0700 Subject: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments In-Reply-To: <CADnb78iJVBVomf_hiWQOSHc6Umh+UwqjjwKLbathV54XFm3-uQ@mail.gmail.com> References: <20130628201946.26920@gmx.com> <CADnb78jxE5B2KTYXj0QBv0GSoGddb=Gbxym5Cp5tYxm7zMG1aA@mail.gmail.com> <522934E9.5070603@mit.edu> <CADnb78iJVBVomf_hiWQOSHc6Umh+UwqjjwKLbathV54XFm3-uQ@mail.gmail.com> Message-ID: <CAAWBYDB4__DmZBKwfbS6+v3ADhJkODe-BtRcMAhjDdRrQResFQ@mail.gmail.com> On Fri, Sep 6, 2013 at 4:22 AM, Anne van Kesteren <annevk at annevk.nl> wrote: > On Fri, Sep 6, 2013 at 2:50 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote: >> In that case I think we need to add a function to the platform that >> CSS-escapes a string. > > Maybe a thing for window.CSS? Simon? Yeah, exposing window.CSS.escapeIdent(DOMString) would make sense. As noted, this is useful for ids, for tag names, and maybe even things like attribute names and values. ~TJ From danya.postfactum at gmail.com Fri Sep 6 23:23:06 2013 From: danya.postfactum at gmail.com (=?KOI8-R?B?5MHOycnMIOvP09TJzg==?=) Date: Sat, 7 Sep 2013 16:23:06 +1000 Subject: [whatwg] Should UA start dragging if [draggable] attr was set after mousedown? Message-ID: <CAGbmyKZ=so6h7+=vwOBGsD4jnb3zXZ6-9qQWgjemdfgzCjzvnw@mail.gmail.com> Hello. I am web developer. I contribute to the ACE (ace.ajax.org) project (web-based code editor). I faced with the issue that IE does not start dragging element if it's [draggable] attribute was set with some delay after mousedown event: element.draggable = false; > element.onmousedown = function() { > setTimeout(function(){ element.draggable = true }, 150); > }; Meanwhile, this works fine in other browsers. I tried to find this behavior to be defined by DND specification ( http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#dnd) but found nothing related. I reported the bug ( https://connect.microsoft.com/IE/feedback/details/799913/ie-8-11-ignores-draggable-attribute-when-set-after-mousedown-event-using-settimeout) but I am not sure this is really bug. May we we should add more specific explanation of DND initiatialization, to prevent such kind of misunderstanding? From foolistbar at googlemail.com Sat Sep 7 03:54:47 2013 From: foolistbar at googlemail.com (Geoffrey Sneddon) Date: Sat, 07 Sep 2013 11:54:47 +0100 Subject: [whatwg] Parse errors for invalid characters In-Reply-To: <52294694.9080309@oupeng.com> References: <522900C4.2050409@googlemail.com> <52294694.9080309@oupeng.com> Message-ID: <522B05F7.3070701@googlemail.com> On 06/09/2013 04:05, Kang-Hao (Kenny) Lu wrote: > (2013/09/06 6:08), Geoffrey Sneddon wrote: >> The phrasing content section states: >> >>> Text nodes and attribute values must consist of Unicode characters, >>> must not contain U+0000 characters, must not contain permanently >>> undefined Unicode characters (noncharacters), and must not contain >>> control characters other than space characters. This specification >>> includes extra constraints on the exact value of Text nodes and >>> attribute values depending on their precise context. >> >> And the pre-processing the input-stream section states: >> >>> Any occurrences of any characters in the ranges U+0001 to U+0008, >>> U+000E to U+001F, U+007F to U+009F, U+FDD0 to U+FDEF, and characters >>> U+000B, U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, U+2FFFE, U+2FFFF, U+3FFFE, >>> U+3FFFF, U+4FFFE, U+4FFFF, U+5FFFE, U+5FFFF, U+6FFFE, U+6FFFF, >>> U+7FFFE, U+7FFFF, U+8FFFE, U+8FFFF, U+9FFFE, U+9FFFF, U+AFFFE, >>> U+AFFFF, U+BFFFE, U+BFFFF, U+CFFFE, U+CFFFF, U+DFFFE, U+DFFFF, >>> U+EFFFE, U+EFFFF, U+FFFFE, U+FFFFF, U+10FFFE, and U+10FFFF are parse >>> errors. These are all control characters or permanently undefined >>> Unicode characters (noncharacters). >> >> Note the first uses "Unicode characters", the second "characters" ? the >> former excludes surrogates as a conformance requirement. >> >> Note that every disallowed non-surrogate character is a parse error. > > Except U+0000 or am I missing something? This is handled inline in the parser, as noted in the preprocessing section. It sometimes gets passed through as U+0000, sometimes gets changed to U+FFFD, sometimes gets ignored, but always creates a parser error. >> Therefore, it would make sense to make surrogates parse errors. >> >> It should be noted that they can only occur in the input stream if they >> come from script (as they cannot be decoded from the input byte stream >> as the decoders will never emit a surrogate). > > which means that this seems ... cubersome ... to implement in a > conformance checker. Which reminds me, does > > # Conformance checkers must report at least one parse error > # condition to the user if one or more parse error conditions exist > # in the document and must not report parse error conditions if none > # exist in the document. Conformance checkers may report more than > # one parse error condition if more than one parse error condition > # exists in the document. > > mean validator.nu and Firefox view source are non-conforming because > they do nothing about document.write() ? > > I think we should exempt conformance checkers from scripts instead. They already are. From the "Conformance classes" section: > Conformance checkers must check that the input document conforms when parsed without a browsing context (meaning that no scripts are run, and that the parser's scripting flag is disabled), and should also check that the input document conforms when parsed with a browsing context in which scripts execute, and that the scripts never cause non-conforming states to occur other than transiently during script execution itself. (This is only a "SHOULD" and not a "MUST" requirement because it has been proven to be impossible. [COMPUTABLE]) (I feel like pedanting and pointing out this is untrue ? it has not been proven impossible to do, it has been proven impossible to do in general. It wouldn't be that hard to design a conformance checker to check "<html><script>document.write("<p>")</script>".) On the other hand, a JS console can reasonably report parse errors from script, so the parse errors are still worthwhile to have. /Geoffrey. From simonp at opera.com Sat Sep 7 10:40:08 2013 From: simonp at opera.com (Simon Pieters) Date: Sat, 07 Sep 2013 19:40:08 +0200 Subject: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments In-Reply-To: <5229E9E7.3040404@mit.edu> References: <20130628201946.26920@gmx.com> <CADnb78jxE5B2KTYXj0QBv0GSoGddb=Gbxym5Cp5tYxm7zMG1aA@mail.gmail.com> <522934E9.5070603@mit.edu> <CADnb78iJVBVomf_hiWQOSHc6Umh+UwqjjwKLbathV54XFm3-uQ@mail.gmail.com> <op.w2zojngdidj3kv@simons-macbook-pro.local> <5229E9E7.3040404@mit.edu> Message-ID: <op.w21x0617idj3kv@simons-macbook-pro.local> On Fri, 06 Sep 2013 16:42:47 +0200, Boris Zbarsky <bzbarsky at mit.edu> wrote: > On 9/6/13 8:20 AM, Simon Pieters wrote: >> So the use case is getting an element by id with an "untrusted" id as >> input, in an element or document fragment as opposed to the document? > > Or getting elements by tag name in a document fragment, for that matter > (though "weird" chars in tag names are harder to produce; largely > limited to leading digits). Leading digits in tag names is not possible. Valid tag names in HTML/SVG/MathML all use non-weird chars. -- Simon Pieters Opera Software From kornel at geekhood.net Sun Sep 8 11:11:28 2013 From: kornel at geekhood.net (=?utf-8?B?S29ybmVsIExlc2nFhHNraQ==?=) Date: Sun, 08 Sep 2013 19:11:28 +0100 Subject: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments In-Reply-To: <op.w2zojngdidj3kv@simons-macbook-pro.local> References: <20130628201946.26920@gmx.com> <CADnb78jxE5B2KTYXj0QBv0GSoGddb=Gbxym5Cp5tYxm7zMG1aA@mail.gmail.com> <522934E9.5070603@mit.edu> <CADnb78iJVBVomf_hiWQOSHc6Umh+UwqjjwKLbathV54XFm3-uQ@mail.gmail.com> <op.w2zojngdidj3kv@simons-macbook-pro.local> Message-ID: <op.w23t5ef7te2ec8@aimac.local> On Fri, 06 Sep 2013 13:20:01 +0100, Simon Pieters <simonp at opera.com> wrote: >> Such a function already exists in the wild btw: >> http://mothereff.in/css-escapes > > So the use case is getting an element by id with an "untrusted" id as > input, in an element or document fragment as opposed to the document? I wouldn't call it "untrusted". It's needed to correctly find arbitrary ID. It's not too eccentric to have non-alphanumeric IDs. For example you need to use `[]` in form element name to receive multiple values in PHP, and it makes sense for form-generating libraries to use same name and ID. I don't understand "deprecation" of getElementById(). querySelector('#'+CSS.escapeIdent(id)) is significantly worse: less readable, slower (generates garbage strings) and error-prone (unescaped incorrect use is much easier than the correct use). It's like deprecating indexOf(), because properly-escaped regular expressions can do the same. getElementById() is a very well-known API. It's pretty convenient. It cannot be removed from the platform, so every browser already has to implement it and cost of exposing it on document fragments should be minimal. Maybe it's not "cool", but keeping it away from document fragments buys nothing, and just makes the platform less consistent. -- regards, Kornel From ian at hixie.ch Mon Sep 9 09:33:57 2013 From: ian at hixie.ch (Ian Hickson) Date: Mon, 9 Sep 2013 16:33:57 +0000 (UTC) Subject: [whatwg] Stroking algorithm in Canvas 2d In-Reply-To: <CAGN7qDA-iib4SULW-JDf4_vpsyuxpg1m8AkXq=qgDtY1OkXahA@mail.gmail.com> References: <CAGN7qDA-iib4SULW-JDf4_vpsyuxpg1m8AkXq=qgDtY1OkXahA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309091626010.12210@ps20323.dreamhostps.com> On Thu, 5 Sep 2013, Rik Cabanier wrote: > > we've looked over the algorithm in the Canvas spec that describes how > strokes are computed. [1] > We think that this section is making some incorrect assumptions. For > instance, the dashes are calculated over the total lenght of all subpaths, > but each subpath should be treated separately. That's intentional, otherwise if you stroke an already-dashed line, you get weird results. > It's also a bit strange that the spec is trying to describe how to stroke. It's trying to describe sufficient detail to get interoperable behaviour. > For instance, it goes in minute detail on how dashes are applied but the > hardest part of stroking ("inflating the paths in path perpendicular to the > direction") is not described at all. Is there any ambiguity in the part that's not described? > Wouldn't it be better to remove all these steps and simply show the > desired effect? Yes. I try to do this as much as possible, but whenever I can't figure out a way to describe something declaratively, I describe it imperatively instead. If you have a way to describe it that is as precise, covers all the same cases, yet is declarative, please don't hesitate to suggest it. I unfortunately find that describing things declaratively is usually only able to get one 90% of the way to a complete description. > If not, what would be the best way to fix the wording? What's wrong with the wording? > The mailing list or a bug? Either is fine and equivalent. (Don't do both, though, please!). -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From cabanier at gmail.com Mon Sep 9 12:56:07 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Mon, 9 Sep 2013 12:56:07 -0700 Subject: [whatwg] Stroking algorithm in Canvas 2d In-Reply-To: <alpine.DEB.2.00.1309091626010.12210@ps20323.dreamhostps.com> References: <CAGN7qDA-iib4SULW-JDf4_vpsyuxpg1m8AkXq=qgDtY1OkXahA@mail.gmail.com> <alpine.DEB.2.00.1309091626010.12210@ps20323.dreamhostps.com> Message-ID: <CAGN7qDDgfZmoZvj9JEwzM764LHWivn=nh_WyGfJOX7SdW31vvg@mail.gmail.com> On Mon, Sep 9, 2013 at 9:33 AM, Ian Hickson <ian at hixie.ch> wrote: > On Thu, 5 Sep 2013, Rik Cabanier wrote: > > > > we've looked over the algorithm in the Canvas spec that describes how > > strokes are computed. [1] > > We think that this section is making some incorrect assumptions. For > > instance, the dashes are calculated over the total lenght of all > subpaths, > > but each subpath should be treated separately. > > That's intentional, otherwise if you stroke an already-dashed line, you > get weird results. > As Stephan said, when would this happen? Are you thinking of a case where you did the dashing yourself and then dash/stroke it again? If so, that is expected to give different results. > > > > It's also a bit strange that the spec is trying to describe how to > stroke. > > It's trying to describe sufficient detail to get interoperable behaviour. > > > > For instance, it goes in minute detail on how dashes are applied but the > > hardest part of stroking ("inflating the paths in path perpendicular to > the > > direction") is not described at all. > > Is there any ambiguity in the part that's not described? > Yes. What is "inflating"? A stroked bezier curve is no longer a bezier and has to be calculated. > > > > Wouldn't it be better to remove all these steps and simply show the > > desired effect? > > Yes. I try to do this as much as possible, but whenever I can't figure out > a way to describe something declaratively, I describe it imperatively > instead. If you have a way to describe it that is as precise, covers all > the same cases, yet is declarative, please don't hesitate to suggest it. I > unfortunately find that describing things declaratively is usually only > able to get one 90% of the way to a complete description. > That's certainly reasonable. I looked at several graphics libraries (CoreGraphics, PDF, Postscript, D2D, Cairo) and none of them really say how they stroke. They just show the result of stroking and at best describe how dashing, joins and endcaps should look. Stephan and I can describe how stroking process but are not familiar with writing it down as normative text. > > > > If not, what would be the best way to fix the wording? > > What's wrong with the wording? > > > > The mailing list or a bug? > > Either is fine and equivalent. (Don't do both, though, please!). > :-) We'll continue this on the mailing list. That way it's more visible and people can chime in. From ian at hixie.ch Mon Sep 9 17:00:25 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Sep 2013 00:00:25 +0000 (UTC) Subject: [whatwg] High-density canvases In-Reply-To: <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> On Wed, 17 Jul 2013, Rik Cabanier wrote: > Ian wrote: > > > > The density aspect of this might be pointless, given the failure of > > getImageDataHD(); if we're dropping that one, I'll drop this one at > > the same time. > > Yes, please drop it since the HD methods are going away from the one > implementation. On Tue, 9 Jul 2013, Stephen White wrote: > > Conversely, if it helps to bring the spec closer to the implementations, > one thing we do not intend to implement in Chrome is the automatic > high-DPI canvas scaling (ie., auto-doubling of backing stores, > getImageDataHD(), putImageDataHD(), etc). > > I believe Apple has also announced that they are dropping support for > this in Safari 7. So my understanding is that the reason this feature failed is that there's existing content that assumes a 1:1 ratio, and having an automatic high-density mode was making some pages end up with canvases with four canvas pixels per CSS pixel (linearly) -- two from the browser making a native canvas, times two from the page scaling the canvas for high DPI displays. This is a factor of sixteen over a 1:1 canvas, a factor of four more than it should be for high DPI, and a big waste of resources. As much as sites do this manually, though, it's a huge pain in the neck to have to worry about pixel density when you're creating your canvas and drawing on it, especially if you're not drawing sprites on it. While we're talking about annoying things, there's also the annoyance that canvases tend to not take zoom into account (either density-affecting zoom like page zoom on desktop, or "transparent" zoom like pinch-zoom on mobile for non-mobile-optimised sites, which the site isn't supposed to know about): you have to remember to listen for onresize, and then manually blow away your canvas and recreate it at the right density and then squeeze it into place so that the coordinate space matches what your code is expecting while the <canvas> is actually sized for the display. There's also the issue of full-bleed canvases where every time the container changes, you have to remember to re-update the canvas coordinate space and repaint because otherwise your pretty page gets all warped. It would be nice to fix these all at once, and I think we can, by introducing a configuration option on getContext(), in the style of WebGL: getContext('2d', { density: 'autosize' }); This would trigger the following behaviour: When the context is created, and subsequently when the <canvas> changes size (e.g. due to being sized with CSS relative units and the element they're relative to changing), or when the display density changes size (e.g. due to page zoom), then: - the width and height of the canvas bitmaps get updated to match the new native size of the <canvas>, at native density. - the coordinate space of the canvas (context.width/context.height) gets updated to match the size of the <canvas> in CSS pixel units. - a 'resize' event gets fired at the <canvas>. We would dump the *HD versions of the methods, and make the regular ones go back to returning the actual raw pixels, since that would now work fine and still provide HD-quality content everywhere it's available. What do people think? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jackalmage at gmail.com Mon Sep 9 17:07:30 2013 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Mon, 9 Sep 2013 17:07:30 -0700 Subject: [whatwg] High-density canvases In-Reply-To: <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> Message-ID: <CAAWBYDCY-aCuZUDF+Snh25QNcS7ZkWFQGxgeMKW1MsYf0e_c+w@mail.gmail.com> On Mon, Sep 9, 2013 at 5:00 PM, Ian Hickson <ian at hixie.ch> wrote: > It would be nice to fix these all at once, and I think we can, by > introducing a configuration option on getContext(), in the style of WebGL: > > getContext('2d', { density: 'autosize' }); > > This would trigger the following behaviour: When the context is created, > and subsequently when the <canvas> changes size (e.g. due to being sized > with CSS relative units and the element they're relative to changing), or > when the display density changes size (e.g. due to page zoom), then: > > - the width and height of the canvas bitmaps get updated to match the > new native size of the <canvas>, at native density. > > - the coordinate space of the canvas (context.width/context.height) > gets updated to match the size of the <canvas> in CSS pixel units. > > - a 'resize' event gets fired at the <canvas>. > > We would dump the *HD versions of the methods, and make the regular ones > go back to returning the actual raw pixels, since that would now work fine > and still provide HD-quality content everywhere it's available. > > What do people think? Sounds reasonable to me. Firing a resize directly at the <canvas> is nice and convenient. ~TJ From dino at apple.com Mon Sep 9 17:18:09 2013 From: dino at apple.com (Dean Jackson) Date: Tue, 10 Sep 2013 10:18:09 +1000 Subject: [whatwg] High-density canvases In-Reply-To: <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> Message-ID: <5989691D-4430-4FA0-8E22-BCDD35CC5DC7@apple.com> On 10 Sep 2013, at 10:00 am, Ian Hickson <ian at hixie.ch> wrote: > On Wed, 17 Jul 2013, Rik Cabanier wrote: >> Ian wrote: >>> >>> The density aspect of this might be pointless, given the failure of >>> getImageDataHD(); if we're dropping that one, I'll drop this one at >>> the same time. >> >> Yes, please drop it since the HD methods are going away from the one >> implementation. > > On Tue, 9 Jul 2013, Stephen White wrote: >> >> Conversely, if it helps to bring the spec closer to the implementations, >> one thing we do not intend to implement in Chrome is the automatic >> high-DPI canvas scaling (ie., auto-doubling of backing stores, >> getImageDataHD(), putImageDataHD(), etc). >> >> I believe Apple has also announced that they are dropping support for >> this in Safari 7. > > So my understanding is that the reason this feature failed is that there's > existing content that assumes a 1:1 ratio, and having an automatic > high-density mode was making some pages end up with canvases with four > canvas pixels per CSS pixel (linearly) -- two from the browser making a > native canvas, times two from the page scaling the canvas for high DPI > displays. This is a factor of sixteen over a 1:1 canvas, a factor of four > more than it should be for high DPI, and a big waste of resources. It wasn?t just that. A lot of existing code did something like this: var pixels = ctx.getImageData(0, 0, canvas.width, canvas.height); for (var i = 0; i < canvas.width; i++) { for (var j = 0; j < canvas.height; j++) { pixels[j * canvas.width + i][0] = newRedValue; pixels[j * canvas.width + i][1] = newGreenValue; pixels[j * canvas.width + i][2] = newBlueValue; } } ctx.putImageData(?) i.e. no one read the spec that says you should check the width and height of the returned ImageData. Then there is toDataURL(). Should that return a full-sized bitmap? Then you need to be sure what you?re uploading it to will handle the larger size. Basically, there was pretty unanimous support from Web developers to ?just give us the damn pixels we asked for?, as well as Chrome and Mozilla suggesting they didn?t want to implement the auto-doubling. We (Safari) were in a position where we were requiring developers to write extra code just for us, as well as potentially breaking some (existing) content. > > As much as sites do this manually, though, it's a huge pain in the neck to > have to worry about pixel density when you're creating your canvas and > drawing on it, especially if you're not drawing sprites on it. > > While we're talking about annoying things, there's also the annoyance that > canvases tend to not take zoom into account (either density-affecting zoom > like page zoom on desktop, or "transparent" zoom like pinch-zoom on mobile > for non-mobile-optimised sites, which the site isn't supposed to know > about): you have to remember to listen for onresize, and then manually > blow away your canvas and recreate it at the right density and then > squeeze it into place so that the coordinate space matches what your code > is expecting while the <canvas> is actually sized for the display. Yes, but I think the developer is the one who best knows what size/quality her content requires. A great developer will do exactly as you suggest: constantly examine the rendered size of the canvas (taking into account pixel density and viewport/zoom). > > There's also the issue of full-bleed canvases where every time the > container changes, you have to remember to re-update the canvas coordinate > space and repaint because otherwise your pretty page gets all warped. > > It would be nice to fix these all at once, and I think we can, by > introducing a configuration option on getContext(), in the style of WebGL: > > getContext('2d', { density: 'autosize' }); > > This would trigger the following behaviour: When the context is created, > and subsequently when the <canvas> changes size (e.g. due to being sized > with CSS relative units and the element they're relative to changing), or > when the display density changes size (e.g. due to page zoom), then: > > - the width and height of the canvas bitmaps get updated to match the > new native size of the <canvas>, at native density. > > - the coordinate space of the canvas (context.width/context.height) > gets updated to match the size of the <canvas> in CSS pixel units. Note that this would reset the context, which would throw away the contents and context state. This might be exactly what you want though - put this attribute on a full-bleed canvas and resize your window -> everything disappears unless you implement the ?resize? event handler. > > - a 'resize' event gets fired at the <canvas>. > > We would dump the *HD versions of the methods, and make the regular ones > go back to returning the actual raw pixels, since that would now work fine > and still provide HD-quality content everywhere it's available. > > What do people think? This seems ok to me. I still worry we?ll get into a situation where developers will add density:?autosize? (in order to get the resizing behaviour) and NOT check the results of getImageData - everything will work fine if they never test on a high-dpi screen. Maybe there should be two attributes? Dean From ian at hixie.ch Mon Sep 9 17:31:44 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Sep 2013 00:31:44 +0000 (UTC) Subject: [whatwg] High-density canvases In-Reply-To: <5989691D-4430-4FA0-8E22-BCDD35CC5DC7@apple.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <5989691D-4430-4FA0-8E22-BCDD35CC5DC7@apple.com> Message-ID: <alpine.DEB.2.00.1309100021320.12210@ps20323.dreamhostps.com> On Tue, 10 Sep 2013, Dean Jackson wrote: > > > > So my understanding is that the reason this feature failed is that > > there's existing content that assumes a 1:1 ratio, and having an > > automatic high-density mode was making some pages end up with canvases > > with four canvas pixels per CSS pixel (linearly) -- two from the > > browser making a native canvas, times two from the page scaling the > > canvas for high DPI displays. This is a factor of sixteen over a 1:1 > > canvas, a factor of four more than it should be for high DPI, and a > > big waste of resources. > > It wasn?t just that. A lot of existing code did something like this: > > var pixels = ctx.getImageData(0, 0, canvas.width, canvas.height); > for (var i = 0; i < canvas.width; i++) { > for (var j = 0; j < canvas.height; j++) { > pixels[j * canvas.width + i][0] = newRedValue; > pixels[j * canvas.width + i][1] = newGreenValue; > pixels[j * canvas.width + i][2] = newBlueValue; > } > } > ctx.putImageData(?) > > i.e. no one read the spec that says you should check the width and > height of the returned ImageData. Per spec, that should work fine even in the current spec fiction of automatic high-density canvases, because getImageData() returns CSS-pixel level data (and the putImageData() call scales it up to native res). That's why we added the *HD methods. > Then there is toDataURL(). Should that return a full-sized bitmap? Per spec, it returns the low-res version, with toDataURLHD() for the full version. > Then you need to be sure what you?re uploading it to will handle the > larger size. Right, hence the two versions. > Basically, there was pretty unanimous support from Web developers to > ?just give us the damn pixels we asked for? Agreed. The proposal {density:'autosize'} seems to do that, while avoiding the back-compat issues that prevent the current spec fiction from working in practice. > > While we're talking about annoying things, there's also the annoyance > > that canvases tend to not take zoom into account (either > > density-affecting zoom like page zoom on desktop, or "transparent" > > zoom like pinch-zoom on mobile for non-mobile-optimised sites, which > > the site isn't supposed to know about): you have to remember to listen > > for onresize, and then manually blow away your canvas and recreate it > > at the right density and then squeeze it into place so that the > > coordinate space matches what your code is expecting while the > > <canvas> is actually sized for the display. > > Yes, but I think the developer is the one who best knows what > size/quality her content requires. > > A great developer will do exactly as you suggest: constantly examine the > rendered size of the canvas (taking into account pixel density and > viewport/zoom). Only because they have to. There's basically three cases that I can see: 1. People dealing only with low-density 96dpi graphics, who just want 96dpi canvases (CSS pixel = canvas pixel = coordinate space unit) and that's it. 2. People who want native resolution graphics. 3. People doing crazy complicated stuff. Currently we're supporting #3 and #1, with #1 being the default, and if you want #2 you have to actually do #3. There are authors (e.g. me, but I suspect it's actually a majority of the more casual authoring community) who want high-quality native-resolution graphics, but who don't want to have to jump through hoops to get them. > > This would trigger the following behaviour: When the context is > > created, and subsequently when the <canvas> changes size (e.g. due to > > being sized with CSS relative units and the element they're relative > > to changing), or when the display density changes size (e.g. due to > > page zoom), then: > > > > - the width and height of the canvas bitmaps get updated to match the > > new native size of the <canvas>, at native density. > > > > - the coordinate space of the canvas (context.width/context.height) > > gets updated to match the size of the <canvas> in CSS pixel units. > > Note that this would reset the context, which would throw away the > contents and context state. This might be exactly what you want though - > put this attribute on a full-bleed canvas and resize your window -> > everything disappears unless you implement the ?resize? event handler. Right, resetting the context would definitely be part of the deal. This mode would be specifically defined as a mode where you had to listen to onresize or your canvas would almost certainly get cleared sooner or later. In fact, we could go further, and say that canvases that aren't getting rendered at all (e.g. display:none, off-screen, background tab) can get cleared, with the deal being that next time you need to show the canvas you immediately get an onresize. The more things we have that trigger onresize, the more likely it is that authors won't forget to implement it. > > - a 'resize' event gets fired at the <canvas>. > > > > We would dump the *HD versions of the methods, and make the regular > > ones go back to returning the actual raw pixels, since that would now > > work fine and still provide HD-quality content everywhere it's > > available. > > > > What do people think? > > This seems ok to me. I still worry we?ll get into a situation where > developers will add density:?autosize? (in order to get the resizing > behaviour) and NOT check the results of getImageData - everything will > work fine if they never test on a high-dpi screen. Yeah, my suggestion, if we do this, would be to not do it until high density displays are even more widely available than now. This is mostly a convenience and performance-improving API, not a critical feature add. > Maybe there should be two attributes? What would the two attributes do? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From cabanier at gmail.com Mon Sep 9 17:48:24 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Mon, 9 Sep 2013 17:48:24 -0700 Subject: [whatwg] High-density canvases In-Reply-To: <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> Message-ID: <CAGN7qDC9-KLHa4+UcsLoowkxoCCPeAOutdKsBaz7y0EBmJEYGQ@mail.gmail.com> On Mon, Sep 9, 2013 at 5:00 PM, Ian Hickson <ian at hixie.ch> wrote: > On Wed, 17 Jul 2013, Rik Cabanier wrote: > > Ian wrote: > > > > > > The density aspect of this might be pointless, given the failure of > > > getImageDataHD(); if we're dropping that one, I'll drop this one at > > > the same time. > > > > Yes, please drop it since the HD methods are going away from the one > > implementation. > > On Tue, 9 Jul 2013, Stephen White wrote: > > > > Conversely, if it helps to bring the spec closer to the implementations, > > one thing we do not intend to implement in Chrome is the automatic > > high-DPI canvas scaling (ie., auto-doubling of backing stores, > > getImageDataHD(), putImageDataHD(), etc). > > > > I believe Apple has also announced that they are dropping support for > > this in Safari 7. > > So my understanding is that the reason this feature failed is that there's > existing content that assumes a 1:1 ratio, and having an automatic > high-density mode was making some pages end up with canvases with four > canvas pixels per CSS pixel (linearly) -- two from the browser making a > native canvas, times two from the page scaling the canvas for high DPI > displays. This is a factor of sixteen over a 1:1 canvas, a factor of four > more than it should be for high DPI, and a big waste of resources. > > As much as sites do this manually, though, it's a huge pain in the neck to > have to worry about pixel density when you're creating your canvas and > drawing on it, especially if you're not drawing sprites on it. > > While we're talking about annoying things, there's also the annoyance that > canvases tend to not take zoom into account (either density-affecting zoom > like page zoom on desktop, or "transparent" zoom like pinch-zoom on mobile > for non-mobile-optimised sites, which the site isn't supposed to know > about): you have to remember to listen for onresize, and then manually > blow away your canvas and recreate it at the right density and then > squeeze it into place so that the coordinate space matches what your code > is expecting while the <canvas> is actually sized for the display. > > There's also the issue of full-bleed canvases where every time the > container changes, you have to remember to re-update the canvas coordinate > space and repaint because otherwise your pretty page gets all warped. > > It would be nice to fix these all at once, and I think we can, by > introducing a configuration option on getContext(), in the style of WebGL: > > getContext('2d', { density: 'autosize' }); > > This would trigger the following behaviour: When the context is created, > and subsequently when the <canvas> changes size (e.g. due to being sized > with CSS relative units and the element they're relative to changing), or > when the display density changes size (e.g. due to page zoom), then: > > - the width and height of the canvas bitmaps get updated to match the > new native size of the <canvas>, at native density. > > - the coordinate space of the canvas (context.width/context.height) > gets updated to match the size of the <canvas> in CSS pixel units. > > - a 'resize' event gets fired at the <canvas>. > Will this workflow introduce flickering? > > We would dump the *HD versions of the methods, and make the regular ones > go back to returning the actual raw pixels, since that would now work fine > and still provide HD-quality content everywhere it's available. > > What do people think? > I'm unsure if these calls are really needed. An author can already do this today with a couple of lines of JS. By doing the actual resizing in the event handler, I believe flickering is avoided. I share Dean's worry that it will lead to bad redrawing if people don't test all scenarios that causes resizing. (Temporary canvases would also have to be resized manually) From ian at hixie.ch Mon Sep 9 21:34:28 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Sep 2013 04:34:28 +0000 (UTC) Subject: [whatwg] High-density canvases In-Reply-To: <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> Message-ID: <alpine.DEB.2.00.1309100433100.12210@ps20323.dreamhostps.com> On Tue, 10 Sep 2013, Ian Hickson wrote: > > It would be nice to fix these all at once, and I think we can, by > introducing a configuration option on getContext(), in the style of > WebGL: > > getContext('2d', { density: 'autosize' }); > > This would trigger the following behaviour: When the context is created, > and subsequently when the <canvas> changes size (e.g. due to being sized > with CSS relative units and the element they're relative to changing), > or when the display density changes size (e.g. due to page zoom), then: > > - the width and height of the canvas bitmaps get updated to match the > new native size of the <canvas>, at native density. > > - the coordinate space of the canvas (context.width/context.height) > gets updated to match the size of the <canvas> in CSS pixel units. > > - a 'resize' event gets fired at the <canvas>. > > We would dump the *HD versions of the methods, and make the regular ones > go back to returning the actual raw pixels, since that would now work > fine and still provide HD-quality content everywhere it's available. > > What do people think? Rik pointed out on IRC that it's common to have out-of-DOM canvases, e.g. for storing textures, which would need to track the density of the one in the DOM. I'd have to think about it in more detail, but in principle it seems some sort of slaving mechanism should be able to handle that too. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From senorblanco at chromium.org Tue Sep 10 07:14:40 2013 From: senorblanco at chromium.org (Stephen White) Date: Tue, 10 Sep 2013 10:14:40 -0400 Subject: [whatwg] High-density canvases In-Reply-To: <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> Message-ID: <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> For posterity, here were our objections to the original high-DPI canvas spec: - The API feels like a short-term hack to automagically do something that the developer may or may not want done (e.g., if the game/app was tuned for particular resolution, or for pixel-exact rendering) that we'll be stuck with in the web platform long after its short-term usefulness has expired - It doesn't scale well to non-integer devicePixelRatios - It is easy for developers to implement the above behaviour in JS if desired I think the new proposal addresses the first point, since it's opt-in. I don't think the second point is a problem, since [get|put]ImageData() will be back to manipulating exact backing store pixels, so no non-integer resizing will be required. The third point becomes moot. One question: now that some browsers are including browser zoom (page zoom) in window.devicePixelRatio, will/should the new proposal automatically cause a resize callback on page zoom, in order to preserve 1:1 device pixels? (Note that I think this is a problem with current JS-based implementations of canvas auto-scale as well, although perhaps there's a DOM event for this that you can listen to; I might just be showing my ignorance here.) Stephen On Mon, Sep 9, 2013 at 8:00 PM, Ian Hickson <ian at hixie.ch> wrote: > On Wed, 17 Jul 2013, Rik Cabanier wrote: > > Ian wrote: > > > > > > The density aspect of this might be pointless, given the failure of > > > getImageDataHD(); if we're dropping that one, I'll drop this one at > > > the same time. > > > > Yes, please drop it since the HD methods are going away from the one > > implementation. > > On Tue, 9 Jul 2013, Stephen White wrote: > > > > Conversely, if it helps to bring the spec closer to the implementations, > > one thing we do not intend to implement in Chrome is the automatic > > high-DPI canvas scaling (ie., auto-doubling of backing stores, > > getImageDataHD(), putImageDataHD(), etc). > > > > I believe Apple has also announced that they are dropping support for > > this in Safari 7. > > So my understanding is that the reason this feature failed is that there's > existing content that assumes a 1:1 ratio, and having an automatic > high-density mode was making some pages end up with canvases with four > canvas pixels per CSS pixel (linearly) -- two from the browser making a > native canvas, times two from the page scaling the canvas for high DPI > displays. This is a factor of sixteen over a 1:1 canvas, a factor of four > more than it should be for high DPI, and a big waste of resources. > > As much as sites do this manually, though, it's a huge pain in the neck to > have to worry about pixel density when you're creating your canvas and > drawing on it, especially if you're not drawing sprites on it. > > While we're talking about annoying things, there's also the annoyance that > canvases tend to not take zoom into account (either density-affecting zoom > like page zoom on desktop, or "transparent" zoom like pinch-zoom on mobile > for non-mobile-optimised sites, which the site isn't supposed to know > about): you have to remember to listen for onresize, and then manually > blow away your canvas and recreate it at the right density and then > squeeze it into place so that the coordinate space matches what your code > is expecting while the <canvas> is actually sized for the display. > > There's also the issue of full-bleed canvases where every time the > container changes, you have to remember to re-update the canvas coordinate > space and repaint because otherwise your pretty page gets all warped. > > It would be nice to fix these all at once, and I think we can, by > introducing a configuration option on getContext(), in the style of WebGL: > > getContext('2d', { density: 'autosize' }); > > This would trigger the following behaviour: When the context is created, > and subsequently when the <canvas> changes size (e.g. due to being sized > with CSS relative units and the element they're relative to changing), or > when the display density changes size (e.g. due to page zoom), then: > > - the width and height of the canvas bitmaps get updated to match the > new native size of the <canvas>, at native density. > > - the coordinate space of the canvas (context.width/context.height) > gets updated to match the size of the <canvas> in CSS pixel units. > > - a 'resize' event gets fired at the <canvas>. > > We would dump the *HD versions of the methods, and make the regular ones > go back to returning the actual raw pixels, since that would now work fine > and still provide HD-quality content everywhere it's available. > > What do people think? > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > From junov at google.com Tue Sep 10 07:44:33 2013 From: junov at google.com (Justin Novosad) Date: Tue, 10 Sep 2013 10:44:33 -0400 Subject: [whatwg] High-density canvases In-Reply-To: <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> Message-ID: <CABpaAqRc1y-G_Oh1JgNDFXSZ-7nYMHKX+GJxpenJ1R1-8W9nPg@mail.gmail.com> There is another closely related issue that's been discussed before: adding a redraw callback to 2d canvas. In the past we discussed this for solving the problem of recoverring from a gpu context loss, but it seems there may be better reasons to consider adding a redraw callback such as freeing memory consumed by canvas backing stores that are in background tabs, and re-building the content when needed. This discussion was revived in the past few days on the chromium graphics-dev mailing list: https://groups.google.com/a/chromium.org/forum/?fromgroups#!topic/graphics-dev/CQJXpXxO6dk The idea is still embryonic and we're brainstorming in this chromium issue: crbug.com/287823 I think that discussion should be merged with this thread because a resize event is another case where one may want to redraw. It would be great to solve all of these issues together. On Tue, Sep 10, 2013 at 10:14 AM, Stephen White <senorblanco at chromium.org>wrote: > For posterity, here were our objections to the original high-DPI canvas > spec: > > - The API feels like a short-term hack to automagically do something > that the developer may or may not want done (e.g., if the game/app was > tuned for particular resolution, or for pixel-exact rendering) that > we'll > be stuck with in the web platform long after its short-term usefulness > has > expired > - It doesn't scale well to non-integer devicePixelRatios > - It is easy for developers to implement the above behaviour in JS if > desired > > I think the new proposal addresses the first point, since it's opt-in. I > don't think the second point is a problem, since [get|put]ImageData() will > be back to manipulating exact backing store pixels, so no non-integer > resizing will be required. The third point becomes moot. > > One question: now that some browsers are including browser zoom (page zoom) > in window.devicePixelRatio, will/should the new proposal automatically > cause a resize callback on page zoom, in order to preserve 1:1 device > pixels? (Note that I think this is a problem with current JS-based > implementations of canvas auto-scale as well, although perhaps there's a > DOM event for this that you can listen to; I might just be showing my > ignorance here.) > > Stephen > > > On Mon, Sep 9, 2013 at 8:00 PM, Ian Hickson <ian at hixie.ch> wrote: > > > On Wed, 17 Jul 2013, Rik Cabanier wrote: > > > Ian wrote: > > > > > > > > The density aspect of this might be pointless, given the failure of > > > > getImageDataHD(); if we're dropping that one, I'll drop this one at > > > > the same time. > > > > > > Yes, please drop it since the HD methods are going away from the one > > > implementation. > > > > On Tue, 9 Jul 2013, Stephen White wrote: > > > > > > Conversely, if it helps to bring the spec closer to the > implementations, > > > one thing we do not intend to implement in Chrome is the automatic > > > high-DPI canvas scaling (ie., auto-doubling of backing stores, > > > getImageDataHD(), putImageDataHD(), etc). > > > > > > I believe Apple has also announced that they are dropping support for > > > this in Safari 7. > > > > So my understanding is that the reason this feature failed is that > there's > > existing content that assumes a 1:1 ratio, and having an automatic > > high-density mode was making some pages end up with canvases with four > > canvas pixels per CSS pixel (linearly) -- two from the browser making a > > native canvas, times two from the page scaling the canvas for high DPI > > displays. This is a factor of sixteen over a 1:1 canvas, a factor of four > > more than it should be for high DPI, and a big waste of resources. > > > > As much as sites do this manually, though, it's a huge pain in the neck > to > > have to worry about pixel density when you're creating your canvas and > > drawing on it, especially if you're not drawing sprites on it. > > > > While we're talking about annoying things, there's also the annoyance > that > > canvases tend to not take zoom into account (either density-affecting > zoom > > like page zoom on desktop, or "transparent" zoom like pinch-zoom on > mobile > > for non-mobile-optimised sites, which the site isn't supposed to know > > about): you have to remember to listen for onresize, and then manually > > blow away your canvas and recreate it at the right density and then > > squeeze it into place so that the coordinate space matches what your code > > is expecting while the <canvas> is actually sized for the display. > > > > There's also the issue of full-bleed canvases where every time the > > container changes, you have to remember to re-update the canvas > coordinate > > space and repaint because otherwise your pretty page gets all warped. > > > > It would be nice to fix these all at once, and I think we can, by > > introducing a configuration option on getContext(), in the style of > WebGL: > > > > getContext('2d', { density: 'autosize' }); > > > > This would trigger the following behaviour: When the context is created, > > and subsequently when the <canvas> changes size (e.g. due to being sized > > with CSS relative units and the element they're relative to changing), or > > when the display density changes size (e.g. due to page zoom), then: > > > > - the width and height of the canvas bitmaps get updated to match the > > new native size of the <canvas>, at native density. > > > > - the coordinate space of the canvas (context.width/context.height) > > gets updated to match the size of the <canvas> in CSS pixel units. > > > > - a 'resize' event gets fired at the <canvas>. > > > > We would dump the *HD versions of the methods, and make the regular ones > > go back to returning the actual raw pixels, since that would now work > fine > > and still provide HD-quality content everywhere it's available. > > > > What do people think? > > > > -- > > Ian Hickson U+1047E )\._.,--....,'``. fL > > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > > > From dino at apple.com Tue Sep 10 11:55:25 2013 From: dino at apple.com (Dean Jackson) Date: Wed, 11 Sep 2013 04:55:25 +1000 Subject: [whatwg] High-density canvases In-Reply-To: <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> Message-ID: <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> On 11 Sep 2013, at 12:14 am, Stephen White <senorblanco at chromium.org> wrote: > now that some browsers are including browser zoom (page zoom) in window.devicePixelRatio Ouch. Who is doing this and why? Dean From bzbarsky at MIT.EDU Tue Sep 10 12:02:33 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Tue, 10 Sep 2013 15:02:33 -0400 Subject: [whatwg] High-density canvases In-Reply-To: <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> Message-ID: <522F6CC9.6020405@mit.edu> On 9/10/13 2:55 PM, Dean Jackson wrote: > Ouch. Who is doing this and why? Any browser in which zoom changes the size of a CSS pixel, and because that's the definition of devicePixelRatio? -Boris From ian at hixie.ch Tue Sep 10 12:32:10 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Sep 2013 19:32:10 +0000 (UTC) Subject: [whatwg] High-density canvases In-Reply-To: <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> Message-ID: <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> On Wed, 11 Sep 2013, Dean Jackson wrote: > On 11 Sep 2013, at 12:14 am, Stephen White <senorblanco at chromium.org> > wrote: > > > > now that some browsers are including browser zoom (page zoom) in > > window.devicePixelRatio > > Ouch. Who is doing this and why? Why ouch? Actually what I really think we should do is also change the window.devicePixelRatio for pinch zoom. Combined with the suggestions for canvas, that would allow (as Rik pointed out on IRC) for high-quality canvas all the way zoomed in, and for cheap canvases when zoomed out. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 10 12:34:23 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Sep 2013 19:34:23 +0000 (UTC) Subject: [whatwg] URL resolution of fragment urls in html5 webapps In-Reply-To: <CAO9zZYOuSfkkGbqFWeeJ-gu1k0mZLFfnjrgkiweL+EN9aGGoiw@mail.gmail.com> References: <CAO9zZYMo79Dqn-EK8S0j-M9sNJeFEGQg_XgP6+fsszDmq5oDMQ@mail.gmail.com> <CANr5HFXkxQuiy+n1jDkd=jP92Wz=E0_BrGbo40A0xxjpbAw2dQ@mail.gmail.com> <CAO9zZYOuSfkkGbqFWeeJ-gu1k0mZLFfnjrgkiweL+EN9aGGoiw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309100013320.12199@ps20323.dreamhostps.com> On Tue, 9 Jul 2013, Igor Minar wrote: > > The current url resolution as described in the spec results in some > unhelpful behavior when the following combination of web technologies > are used in a client-side web app: > > - a combination of path-relative urls (<a > href="relative/url/to/somewhere">link</a>) and fragment/anchor urls (<a > href="#anchorUrl">link</a>) > - history.pushState - used for deep-linking > - base[href] - used to properly resolve the relative urls to the root of > the application in various deployment environments > > Once history.pushState is used to change location.href, the > path-relative urls resolve correctly as expected against the base[href], > but anchor urls that are only useful if resolved against the current > document.baseURI also unsurprisingly resolve against the base[href]. The fragment identifiers resolve that way before the pushState(), too. > This behavior makes them unsuitable for this kind of applications which > is a big loss in developers toolbox and in fact breaks existing web > features like svg that depend on anchor urls to reference nodes in the > current document. How do they work in SVG with a <base> with no pushState()? http://hixie.ch/tests/adhoc/svg/use/001-with-base.html In Safari and Firefox, the relative URLs, even in SVG, are affected by <base>, so again, it seems it's <base> that is relevant here, not pushState(). (In Chrome, some URLs are resolved locally and some not, which is wacked.) > Does anyone have thoughts on how one could build a client-side app that > can be deployed in various contexts without any special server-side > templating or build-time pre-processing? > > The base element looks like a perfect solution for this, if only it > didn't break anchor urls. Use only site-absolute URLs, and not <base>, and then everything will work fine, as far as I can tell. On Wed, 10 Jul 2013, Alex Russell wrote: > > Was just discussing this with Rafael, and it seems like the core issue > you're flagging is that if a document has a <base> element, all #anchor > navigations (which would otherwise be document relative) are now > full-page navigations to the URL specified in the <base>, not the > document's "natural" URL. Is that right? > > If so, we might be able give you some control over this in the > Navigation Controller (although it's not currently scoped as many folks > didn't want to contemplate in-document navigation for the time being). > > But perhaps we don't need to do that: is the current behavior the same > across browsers? If it's not, we might be able to change the spec. If it > is, it'll be harder. It seems pretty consistent. On Wed, 10 Jul 2013, Rafael Weinstein wrote: > > I'm curious: Is it useful to have fragment URL resolve against anything > other than the "display" url? I.e. when is the current behavior wrt > fragments appropriate. It's a good question. I thought the old IETF specs for URLs said you had to do otherwise, but nobody seems to have implemented that. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From dino at apple.com Tue Sep 10 12:45:13 2013 From: dino at apple.com (Dean Jackson) Date: Wed, 11 Sep 2013 05:45:13 +1000 Subject: [whatwg] High-density canvases In-Reply-To: <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> Message-ID: <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> On 11 Sep 2013, at 5:32 am, Ian Hickson <ian at hixie.ch> wrote: > On Wed, 11 Sep 2013, Dean Jackson wrote: >> On 11 Sep 2013, at 12:14 am, Stephen White <senorblanco at chromium.org> >> wrote: >>> >>> now that some browsers are including browser zoom (page zoom) in >>> window.devicePixelRatio >> >> Ouch. Who is doing this and why? > > Why ouch? Because we?ve always operated under the assumption that devicePixelRatio is the mapping from CSS px to device pixels at 1:1 scale/zoom, and that it is constant for a particular display. The only change content would see is if the window is dragged to/from a high resolution screen. There are other ways to query the page zoom. I fear this will break existing content. I don?t think we?d ever want to change the behaviour. Dean > > Actually what I really think we should do is also change the > window.devicePixelRatio for pinch zoom. Combined with the suggestions for > canvas, that would allow (as Rik pointed out on IRC) for high-quality > canvas all the way zoomed in, and for cheap canvases when zoomed out. From ian at hixie.ch Tue Sep 10 12:54:31 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Sep 2013 19:54:31 +0000 (UTC) Subject: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use In-Reply-To: <CADnb78iniuYkyc4cH+RECg1p=ANVQPMz_sod9_Q11C=YDN=ZXg@mail.gmail.com> References: <514A7477.6040905@mit.edu> <alpine.DEB.2.00.1307121809430.15729@ps20323.dreamhostps.com> <51E04C76.30200@mit.edu> <CAJE5ia_WTqejajPZVxf=cxTipvPyE=g0FWQfj-kJaj1tK583kw@mail.gmail.com> <51E04FDD.2080702@mit.edu> <CADnb78iniuYkyc4cH+RECg1p=ANVQPMz_sod9_Q11C=YDN=ZXg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309101934520.12199@ps20323.dreamhostps.com> On Fri, 12 Jul 2013, Boris Zbarsky wrote: > On 7/12/13 2:15 PM, Ian Hickson wrote: > > > > > > The "document's referrer" is not really defined anywhere in a useful > > > way that I can find. > > > > What's not useful about the way it's defined? It's set to a specific > > string. > > I couldn't find where it was normatively set to anything. It's normatively set in two places. For the about:blank Document, it's set (if necessary) here: # If the browsing context has a creator Document, then the browsing # context's Document's referrer must be set to the address of that creator # Document at the time of the browsing context's creation. -- http://whatwg.org/html#windows For regular Documents, it's set in the "Creating a new Document object" steps: # Set the document's referrer to the address of the resource from which # Request-URIs are obtained as determined when the fetch algorithm # obtained the resource, if that algorithm was used and determined such a # value; otherwise, set it to the empty string. -- http://whatwg.org/html#create-a-document-object These seem like the logical places for it to be set. Am I missing something? > > > In cases when the hostname is non-ASCII, the Referer header will > > > have it encoded in punycode. > > > > Is that defined anywhere? > > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36 which > defines it syntactically as a URI, which means that if you have an IRI > you have to convert it to an IRI before putting it in there. That's normatively imported by the HTML spec's "fetch" algorithm, so it's the case per HTML too. Specifically, HTML just says to generate the Referer header's value "as required by HTTP" using a particular URL as the input. > > That's correct per spec (assuming the punycoding is required > > anywhere). The latter two are set separately than document.referrer: > > > > http://whatwg.org/html/#set-the-document's-address > > The thing is, people are comparing origins from postMessage to origins > from document.referrer. See > <https://bugzilla.mozilla.org/show_bug.cgi?id=852796#c6>. Also see > <https://bugzilla.mozilla.org/show_bug.cgi?id=720331>. Well, then they'll be broken, I guess. (They'll break safe, though.) > Also, as a note, nothing above makes it particularly clear that "the URL > that was originally to be fetched" is not already punycode... Ah, well. It might be, depends on what the URL is. > > If other browsers don't match this, file bugs on them. :-) > > <shrug>. It probably won't do much good, but: > > http://code.google.com/p/chromium/issues/detail?id=259920&thanks=259920&ts=1373653828 > > https://bugs.webkit.org/show_bug.cgi?id=118611 Thanks. On Fri, 12 Jul 2013, Adam Barth wrote: > > I don't think we're likely to change this behavior. We always use > punycode for URLs except in the location bar. Why? On Fri, 12 Jul 2013, Boris Zbarsky wrote: > On 7/12/13 2:40 PM, Adam Barth wrote: > > Why not change Firefox to use punycode in window.location? > > If nothing else because that seems user-hostile (both to web developers > examining location values and users who are shown document.URL or > location.href in web pages). Yeah... On Fri, 12 Jul 2013, Anne van Kesteren wrote: > > But then we shouldn't garble pathname either and we do because we have > to. So I'm not sure that line of reasoning makes sense. I do think we > should offer some kind of conversion utility between the two. It is unfortunate that resolving URLs does that, it's true. But just because we're constrained here, why should we mess up domains also? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 10 13:13:02 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Sep 2013 20:13:02 +0000 (UTC) Subject: [whatwg] High-density canvases In-Reply-To: <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> Message-ID: <alpine.DEB.2.00.1309102011560.12210@ps20323.dreamhostps.com> On Wed, 11 Sep 2013, Dean Jackson wrote: > On 11 Sep 2013, at 5:32 am, Ian Hickson <ian at hixie.ch> wrote: > > On Wed, 11 Sep 2013, Dean Jackson wrote: > >> On 11 Sep 2013, at 12:14 am, Stephen White <senorblanco at chromium.org> > >> wrote: > >>> > >>> now that some browsers are including browser zoom (page zoom) in > >>> window.devicePixelRatio > >> > >> Ouch. Who is doing this and why? > > > > Why ouch? > > Because we?ve always operated under the assumption that devicePixelRatio > is the mapping from CSS px to device pixels at 1:1 scale/zoom, and that > it is constant for a particular display. The only change content would > see is if the window is dragged to/from a high resolution screen. > > There are other ways to query the page zoom. That seems broken... why would you want to hide the page zoom? > I fear this will break existing content. I don?t think we?d ever want to > change the behaviour. I guess we'll just have to treat devicePixelRatio as legacy and introduce a new value that's the real device:pixel ratio, then. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 10 13:14:06 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Sep 2013 20:14:06 +0000 (UTC) Subject: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use In-Reply-To: <alpine.DEB.2.00.1309101934520.12199@ps20323.dreamhostps.com> References: <514A7477.6040905@mit.edu> <alpine.DEB.2.00.1307121809430.15729@ps20323.dreamhostps.com> <51E04C76.30200@mit.edu> <CAJE5ia_WTqejajPZVxf=cxTipvPyE=g0FWQfj-kJaj1tK583kw@mail.gmail.com> <51E04FDD.2080702@mit.edu> <CADnb78iniuYkyc4cH+RECg1p=ANVQPMz_sod9_Q11C=YDN=ZXg@mail.gmail.com> <alpine.DEB.2.00.1309101934520.12199@ps20323.dreamhostps.com> Message-ID: <alpine.DEB.2.00.1309102013220.12210@ps20323.dreamhostps.com> On Tue, 10 Sep 2013, Ian Hickson wrote: > > > > > > > > In cases when the hostname is non-ASCII, the Referer header will > > > > have it encoded in punycode. > > > > > > Is that defined anywhere? > > > > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36 which > > defines it syntactically as a URI, which means that if you have an IRI > > you have to convert it to an IRI before putting it in there. > > That's normatively imported by the HTML spec's "fetch" algorithm, so > it's the case per HTML too. Specifically, HTML just says to generate the > Referer header's value "as required by HTTP" using a particular URL as > the input. Incidentally, Anne, fetch.spec.whatwg.org seems to have omitted the dependency on HTTP so this is broken there, if I'm not mistaken. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From dino at apple.com Tue Sep 10 13:22:51 2013 From: dino at apple.com (Dean Jackson) Date: Wed, 11 Sep 2013 06:22:51 +1000 Subject: [whatwg] High-density canvases In-Reply-To: <alpine.DEB.2.00.1309102011560.12210@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> <alpine.DEB.2.00.1309102011560.12210@ps20323.dreamhostps.com> Message-ID: <BBF7063D-027A-48C5-92CD-F5EF829BC800@apple.com> On 11 Sep 2013, at 6:13 am, Ian Hickson <ian at hixie.ch> wrote: > On Wed, 11 Sep 2013, Dean Jackson wrote: >> On 11 Sep 2013, at 5:32 am, Ian Hickson <ian at hixie.ch> wrote: >>> On Wed, 11 Sep 2013, Dean Jackson wrote: >>>> On 11 Sep 2013, at 12:14 am, Stephen White <senorblanco at chromium.org> >>>> wrote: >>>>> >>>>> now that some browsers are including browser zoom (page zoom) in >>>>> window.devicePixelRatio >>>> >>>> Ouch. Who is doing this and why? >>> >>> Why ouch? >> >> Because we?ve always operated under the assumption that devicePixelRatio >> is the mapping from CSS px to device pixels at 1:1 scale/zoom, and that >> it is constant for a particular display. The only change content would >> see is if the window is dragged to/from a high resolution screen. >> >> There are other ways to query the page zoom. > > That seems broken... why would you want to hide the page zoom? We don?t want to hide page zoom. I think there are two separate things a developer might want: - the number of actual pixels that correspond to 1 CSS px without zoom - the page zoom If you merge the two, then an unsuspecting developer might think that the user has zoomed in by 2x on an iPhone, and decide to make things smaller. Yes, that?s not necessarily great content, but it makes some sense. For most page content you don?t really care about the device:pixel ratio - text looks fine! For images, you should use the mechanisms we?ve developed (srcset and image-set). Now, I completely agree that there are going to be cases where you might want the image selected for srcset and image-set to respond to zoom. After all, there is no point loading a huge image if it is going to be 1x1 cm^2. But I think that?s separate from changing devicePixelRatio. >> I fear this will break existing content. I don?t think we?d ever want to >> change the behaviour. > > I guess we'll just have to treat devicePixelRatio as legacy and introduce > a new value that's the real device:pixel ratio, then. Indeed. I?m not opposed to exposing this. I am reluctant to change something that has behaved a particular way for a number of years. Meanwhile, back to canvas, why don?t we change canvas to be purely callback based, and pass in all the info a developer needs to decide what the best output should be? Put something like requestAnimationFrame into the canvas spec (although that is a bad name - it only sometimes is related to animation). That way you could even imagine a future where a single canvas could have multiple render targets (when printing you get an even higher resolution). Dean From cabanier at gmail.com Tue Sep 10 13:26:23 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 10 Sep 2013 13:26:23 -0700 Subject: [whatwg] High-density canvases In-Reply-To: <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> Message-ID: <CAGN7qDCC=8EZUpEmN=10tcWGU=8TPQ7rej+sOGhbPaWqqAjWRA@mail.gmail.com> On Tue, Sep 10, 2013 at 12:45 PM, Dean Jackson <dino at apple.com> wrote: > > On 11 Sep 2013, at 5:32 am, Ian Hickson <ian at hixie.ch> wrote: > > > On Wed, 11 Sep 2013, Dean Jackson wrote: > >> On 11 Sep 2013, at 12:14 am, Stephen White <senorblanco at chromium.org> > >> wrote: > >>> > >>> now that some browsers are including browser zoom (page zoom) in > >>> window.devicePixelRatio > >> > >> Ouch. Who is doing this and why? > > > > Why ouch? > > Because we?ve always operated under the assumption that devicePixelRatio > is the mapping from CSS px to device pixels at 1:1 scale/zoom, and that it > is constant for a particular display. The only change content would see is > if the window is dragged to/from a high resolution screen. > > There are other ways to query the page zoom. > > I fear this will break existing content. I don?t think we?d ever want to > change the behaviour. There's a thread on www-style: http://lists.w3.org/Archives/Public/www-style/2012Nov/0144.html It's been in firefox for a while and blink is going to ship it soon: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/RyUSi3zdumQ > > > > > > Actually what I really think we should do is also change the > > window.devicePixelRatio for pinch zoom. Combined with the suggestions for > > canvas, that would allow (as Rik pointed out on IRC) for high-quality > > canvas all the way zoomed in, and for cheap canvases when zoomed out > I believe pinch zoom should not change devicePixelRatio. It would be nice if there was a standard way to determine pinch zoom though and if the canvas could automatically resize. From bzbarsky at MIT.EDU Tue Sep 10 13:32:22 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Tue, 10 Sep 2013 16:32:22 -0400 Subject: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use In-Reply-To: <alpine.DEB.2.00.1309101934520.12199@ps20323.dreamhostps.com> References: <514A7477.6040905@mit.edu> <alpine.DEB.2.00.1307121809430.15729@ps20323.dreamhostps.com> <51E04C76.30200@mit.edu> <CAJE5ia_WTqejajPZVxf=cxTipvPyE=g0FWQfj-kJaj1tK583kw@mail.gmail.com> <51E04FDD.2080702@mit.edu> <CADnb78iniuYkyc4cH+RECg1p=ANVQPMz_sod9_Q11C=YDN=ZXg@mail.gmail.com> <alpine.DEB.2.00.1309101934520.12199@ps20323.dreamhostps.com> Message-ID: <522F81D6.1060909@mit.edu> On 9/10/13 3:54 PM, Ian Hickson wrote: > These seem like the logical places for it to be set. Am I missing > something? No, you're not. I was. > Well, then they'll be broken, I guess. (They'll break safe, though.) Well, the outcome is "user can't use site". (Which they care more about than whether the site is safe or not, too, though the safety bit is not relevant to the discussion per se.) > It might be, depends on what the URL is. Basically, if we want interop on this stuff we need to define which things get punycoded where and which things are stored as ACE instead and whatnot. :( -Boris From bzbarsky at MIT.EDU Tue Sep 10 13:33:02 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Tue, 10 Sep 2013 16:33:02 -0400 Subject: [whatwg] High-density canvases In-Reply-To: <alpine.DEB.2.00.1309102011560.12210@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> <alpine.DEB.2.00.1309102011560.12210@ps20323.dreamhostps.com> Message-ID: <522F81FE.3080708@mit.edu> On 9/10/13 4:13 PM, Ian Hickson wrote: > I guess we'll just have to treat devicePixelRatio as legacy and introduce > a new value that's the real device:pixel ratio, then. I would be interested in some data on what different UAs do with devicePixelRatio... -Boris From bzbarsky at MIT.EDU Tue Sep 10 13:36:06 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Tue, 10 Sep 2013 16:36:06 -0400 Subject: [whatwg] High-density canvases In-Reply-To: <BBF7063D-027A-48C5-92CD-F5EF829BC800@apple.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> <alpine.DEB.2.00.1309102011560.12210@ps20323.dreamhostps.com> <BBF7063D-027A-48C5-92CD-F5EF829BC800@apple.com> Message-ID: <522F82B6.7090605@mit.edu> On 9/10/13 4:22 PM, Dean Jackson wrote: > I think there are two separate things a developer might want: > > - the number of actual pixels that correspond to 1 CSS px without zoom What are the use cases for this, as opposed to "number of actual pixels that correspond to 1 CSS px"? And are you talking about the sort of zoom that changes layout (because it changes the number of CSS px per device px and hence changes font rasterization), or the sort that does not (which basically does a zoom without changing font metrics)? > - the page zoom Which one? > Indeed. I?m not opposed to exposing this. I am reluctant to change something that has behaved a particular way for a number of years. Shipping UAs already disagree on how devicePixelRatio works with zoom. They also disagree on how zoom behaves in general. -Boris From ian at hixie.ch Tue Sep 10 13:37:10 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Sep 2013 20:37:10 +0000 (UTC) Subject: [whatwg] High-density canvases In-Reply-To: <BBF7063D-027A-48C5-92CD-F5EF829BC800@apple.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> <alpine.DEB.2.00.1309102011560.12210@ps20323.dreamhostps.com> <BBF7063D-027A-48C5-92CD-F5EF829BC800@apple.com> Message-ID: <alpine.DEB.2.00.1309102032170.12210@ps20323.dreamhostps.com> On Wed, 11 Sep 2013, Dean Jackson wrote: > > I think there are two separate things a developer might want: > > - the number of actual pixels that correspond to 1 CSS px without zoom > - the page zoom Why? Exposing page zoom separately from device density seems like a fundamental abstraction failure. What's the difference between page zoom and native density? > If you merge the two, then an unsuspecting developer might think that > the user has zoomed in by 2x on an iPhone, and decide to make things > smaller. That's precisely why we should never make page zoom detectable. The entire point of zooming is that the author should _not_ make things smaller. Zooming should make CSS pixels bigger. Authors should always treat CSS pixels as the core unit, so if something should be 10 CSS pixels wide, then that's what the author should do. If the user happens to have zoomed in so that those 10 pixels are 30cm across, then that's what the user wants -- why would the author be able to override that? > Yes, that?s not necessarily great content, but it makes some sense. What sense does it make? > For most page content you don?t really care about the device:pixel ratio > - text looks fine! For images, you should use the mechanisms we?ve > developed (srcset and image-set). Well the context here is canvas, right? > Now, I completely agree that there are going to be cases where you might > want the image selected for srcset and image-set to respond to zoom. Not edge cases, they're pretty core cases. srcset="" should definitely be influenced by page zoom, there's no question there. Otherwise, users who zoom in will get low quality images, which defeats the whole point. > After all, there is no point loading a huge image if it is going to be > 1x1 cm^2. But I think that?s separate from changing devicePixelRatio. Why? > >> I fear this will break existing content. I don?t think we?d ever want > >> to change the behaviour. > > > > I guess we'll just have to treat devicePixelRatio as legacy and > > introduce a new value that's the real device:pixel ratio, then. > > Indeed. I?m not opposed to exposing this. I am reluctant to change > something that has behaved a particular way for a number of years. > > Meanwhile, back to canvas, why don?t we change canvas to be purely > callback based, and pass in all the info a developer needs to decide > what the best output should be? Put something like requestAnimationFrame > into the canvas spec (although that is a bad name - it only sometimes is > related to animation). That way you could even imagine a future where a > single canvas could have multiple render targets (when printing you get > an even higher resolution). I'm not really understanding what you're proposing here. Can you elaborate? What's the problem this is trying to solve? How would this work in a multi-worker environment? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 10 13:40:36 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Sep 2013 20:40:36 +0000 (UTC) Subject: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use In-Reply-To: <522F81D6.1060909@mit.edu> References: <514A7477.6040905@mit.edu> <alpine.DEB.2.00.1307121809430.15729@ps20323.dreamhostps.com> <51E04C76.30200@mit.edu> <CAJE5ia_WTqejajPZVxf=cxTipvPyE=g0FWQfj-kJaj1tK583kw@mail.gmail.com> <51E04FDD.2080702@mit.edu> <CADnb78iniuYkyc4cH+RECg1p=ANVQPMz_sod9_Q11C=YDN=ZXg@mail.gmail.com> <alpine.DEB.2.00.1309101934520.12199@ps20323.dreamhostps.com> <522F81D6.1060909@mit.edu> Message-ID: <alpine.DEB.2.00.1309102038110.12210@ps20323.dreamhostps.com> On Tue, 10 Sep 2013, Boris Zbarsky wrote: > On 9/10/13 3:54 PM, Ian Hickson wrote: > > > > > [some sites compare values that are always-punycoded domains with > > > values that can be full Unicode for security checks] > > > > Well, then they'll be broken, I guess. (They'll break safe, though.) > > Well, the outcome is "user can't use site". (Which they care more about > than whether the site is safe or not, too, though the safety bit is not > relevant to the discussion per se.) Do you have a concrete example I can look at here? I agree we should make this interoperable. > > It might be, depends on what the URL is. > > Basically, if we want interop on this stuff we need to define which > things get punycoded where and which things are stored as ACE instead > and whatnot. :( Agreed. I think we have (if it doesn't say to punycode, don't punycode; nothing ever unpunycodes). The current definitions might not be always what we want, but I think to the extent that they are not, we need to study concrete examples to see what we should do. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 10 14:22:12 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Sep 2013 21:22:12 +0000 (UTC) Subject: [whatwg] Forcing orientation in content In-Reply-To: <op.wz8k70f4te2ec8@aimac> References: <516F27BF.4060508@gmail.com> <alpine.DEB.2.00.1307121944480.15729@ps20323.dreamhostps.com> <420FE1A33AB14ACB9667D659D8F415D5@gmail.com> <op.wz8k70f4te2ec8@aimac> Message-ID: <alpine.DEB.2.00.1309102107450.12199@ps20323.dreamhostps.com> On Fri, 12 Jul 2013, Glenn Maynard wrote: > On Fri, Jul 12, 2013 at 2:45 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > Why? As a user on desktop, I can resize my window however I want, to > > be landscape or portrait. Why wouldn't I be allowed to do the same on > > any other device? > > In mobile accelerometer/gyro-based games, you don't want the user's > shifting the device around to cause the screen to change orientation > while they're playing. This means locking the current orientation, > though, rather than a specific orientation (for example, you'd probably > want to unlock it when the user is in a menu and not actually playing > the game). I could see locking the orientation in full-screen mode, sure (as Kornel suggested in a later e-mail, see below). > On Fri, Jul 12, 2013 at 7:07 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > Sure, some orientations might be better -- just like the HTML spec is > > more readable on a taller large screen than on a landscape phone > > screen -- but if the user wants to play the other way, it seems wrong > > to be able to prevent it. > > In practice, game developers are rarely willing to spend the time to > make their games work well in both portrait and landscape. That's certainly true, but the reality is that on the Web a web browser window might be any number of dimensions, so that's a problem you have to deal with regardless. > The Web solution is probably not to lock the display, though, but to > letterbox the display if the window's aspect ratio is too far off, as > with videos. Well, not so much letterbox as just fit in the given width, leaving a lot of space at the bottom (or centering vertically), sure. On Fri, 12 Jul 2013, Jonas Sicking wrote: > On Fri, Jul 12, 2013 at 12:45 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Thu, 18 Apr 2013, David Bruant wrote: > >> > >> Currently working on a web project where tablet support (iPad > >> especially) is important, I'm facing a need which apparently the > >> platform doesn't support. I would need to lock the screen in > >> landscape mode. > > > > Why? As a user on desktop, I can resize my window however I want, to > > be landscape or portrait. Why wouldn't I be allowed to do the same on > > any other device? > > If the content is sized better for portrait or landscape, then it's > generally good for the user if the mode is forced by the application. I disagree. The author doens't know better than I do what I want. > Otherwise the user will have to scroll, or will see content that is > smaller than it otherwise would be. Or rotate the device, which the user will have to do regardless if the application forces it. > Users can't always rotate the screen themselves to control this since > many times users disable screen rotation controlled by gravity. If the user disables it, the user can just as easily re-enable it... Also, if the user disabled it, I think it's even more of a reason not to rotate the display for the user. > Common cases when this is done is if they find that the screen too often > erratically rotates due to the user moving around the device. Another > scenario is if laying down with the device in bed in which case rotating > according to gravity will result in a screen that is off by 90 degrees > from the users orientation. Indeed. > The reason we don't do this on desktop systems is that desktop platforms > generally don't let the user adjust to an application rendering itself > sideways to fit in the current window size. On tablets and mobile > platforms, there is an established UI paradigm of simply rotating the > device when content renders itself sideways. A quite annoying UI paradigm... > If we don't provide webplatform support for setting orientation, content > will simply use things like CSS transformation to render itself > sideways. This results in a much poorer experience for the user since it > interacts poorly with for example gravitational orientation. I.e. the > user might see the content sideways, then rotate the device in order to > see the content correctly, resulting in the device then changing > rendering orientation. The page will then detect this and undo the > transformation. The result is a lot of back and forth which is > disruptive to the user. Any automatic rotation not under the control of the user, or locking of rotation not under the control of the user, is disruptive to the user. > Another problem that is likely to occur is authors accidentally applying > CSS transformation in on devices where the user can't reorient the > device. > > Not to mention that using CSS transformation will likely result in > content that has to use more javascript driven layout with all the > downsides that come with that. I'm certainly not advocating for authors manually rotating the content to be at 90 degrees to the device's native orientation. > By supporting pages setting the orientation we can put the user more in > charge by ignoring that orientation when appropriate. Such as on devices > where changing the orientation is bad, or when the user has explicitly > requested the orientation not to change. I'm confused as to what UI you are envisaging here. Would this be in addition to, or instead of, the native UI to prevent rotation? > In Firefox we have implemented the screen orientation spec > https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html That is unfortuate. I don't think that API puts the user first. (I also don't understand what it means in non-mobile environments. It seems very medium-specific, which is not very Webby.) > However I personally would like to see declarative support in addition > to the script API. Can you elaborate on what user problems we are solving here and what such a declarative mechanism would look like? On Mon, 15 Jul 2013, Roger H?gensen wrote: > On 2013-07-13 06:17, Glenn Maynard wrote: > > > > Changing orientation is disruptive. > > > > I can hardly imagine how obnoxious Web browsing would be on a mobile > > device, if every second page I navigated to decided to flip my device > > to a different orientation. This feels like the same sort of > > misfeature as allowing pages to resize the browser window: "best > > viewed in 800x600" (so we'll force it), "best viewed in portrait" (so > > we'll force it). > > I have a tablet here that does that with a few apps. And one of them > actually does it within itself during certain parts of the program. > > And I can testify it's annoying as hell. For those curious it was a > banking app. And the main menu is forced/locked. But the rest like > account activity etc. is not. And you can imagine how stupid it is when > you have to rotate the tablet each time you go back to the main menu. Indeed. > I find responsive and scalable design (so it looks good) on multiple > aspects ratios and multiple PPIs is a must for modern coding. I agree. It also seems to be the only way to actually make things work on some media, such as desktop windows, which can't be rotated yet can have any aspect ratio. On Sat, 13 Jul 2013, Tobie Langel wrote: > > It is not uncommon for mobile experiences to rely on the accelerometer > as an input mechanism, for example to control page scrolling (e.g. > Instapaper) or for gameplay. > > In such cases, auto-rotation of the viewport is completely disruptive to > the user's experience and needs to be inhibited. Sure, but that's an OS-level feature. > So this isn't so much about forcing orientation as it is about > inhibiting auto-rotation. This would only work if the page was already in the orientation the user wants, but how can we ensure that? > Your desktop comparison is inadequate, as there aren't comparable > auto-rotation mechanisms there. It would be equivalent to forcing a particular window size. On Mon, 15 Jul 2013, Kornel Lesi?ski wrote: > > Since specific, locked screen orientation is mostly needed in games, and > forced rotation is disruptive to other things on the screen (e.g. moving > buttons/addressbar to other physical edge of the screen), maybe it > should be tied to the Fullscreen API? > > element.requestFullscreen({orientation:'landscape', autorotation:false}) That makes sense to me. Anne? In any case, this seems to be out of scope of HTML, so I haven't added anything to the HTML spec. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 10 14:28:32 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Sep 2013 21:28:32 +0000 (UTC) Subject: [whatwg] scrdoc and session history don't play along in the spec In-Reply-To: <CA+c2ei-93BY=-9fGsie_c+q6=OWz3NA3HB9xLyGj2SLBi=OTXg@mail.gmail.com> References: <515EF14C.4070102@mit.edu> <CAJE5ia-WtbpbhvvuWixzah+YDdY-s_-c3kHG_pVe8J5bZa2YgQ@mail.gmail.com> <51C6FB2A.1010304@mit.edu> <CAJE5ia9WnYAZKjvmfh3KbcHN_xYKfmtfxuWQP-sYebxzTePwrQ@mail.gmail.com> <51C72C0C.5000605@mit.edu> <alpine.DEB.2.00.1307121914050.15729@ps20323.dreamhostps.com> <51E0627C.9070705@mit.edu> <CA+c2ei-93BY=-9fGsie_c+q6=OWz3NA3HB9xLyGj2SLBi=OTXg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309102122410.12199@ps20323.dreamhostps.com> On Fri, 12 Jul 2013, Jonas Sicking wrote: > > The algorithms in the spec are great when it comes to defining things > with high level of exactness. However they only work well when the > implementations of those algorithms actually look like the algorithms in > the spec. > > When they don't, the implementor has to read in all relevant algorithms > defined in the spec. Then map those algorithms into the semantics and > behavior they actually result in for the feature that the implementor is > working on implementing. Then map those semantics and behaviors into an > implementation that fits with existing code. Yeah. This is further complicated by the way all the implementations are implemented in ways that differ from each other, so that there's no way to write a single description that would be easy to understand for all vendors. I do sometimes actually try to follow one or the other browser's implementation, if I understand it well enough and it's clear enough. > Generally speaking, it would be easier if the spec defined the semantics > and the behaviors instead. Thereby avoiding having to do the initial > algorithms->behavior mapping. I agree. Unfortunately, it's really hard (for me) to describe behaviours like navigation in a declarative way while still covering all the edge cases. I'd be very happy to consider alternatives ways to describe the behaviours in the spec that are currently algorithmic in declarative ways, if anyone has any suggestions for how to do this. I do actually do it where possible. > Another fix would of course be to rewrite implementations to match the > algorithms and concepts in the spec more precisely. Though that's a > very risky undertaking for something like navigation since the spec > probably isn't getting all edge cases right. Yup. > Additionally the spec doesn't deal with all the situations that at least > Gecko has to deal with (desktop shortcuts being clicked. Bookmarklets > being clicked. Commandlines being executed. Addons. Etc) which means > that it might not be possible to get the two to align very well. Yup. > That said, I totally understand that it's very hard to define behavior > to the level of exactness that's currently there, without writing the > spec the way it's currently written. But I believe that this is what's > making the spec hard to read. What's making the spec hard to read is the same thing that makes the implementations hard to read. The topic in question is complicated. At the end of the day, there's a limit to how simply one can describe something that is fundamentally complicated. But as I said above, I'm very open to any suggestions. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 10 14:45:15 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Sep 2013 21:45:15 +0000 (UTC) Subject: [whatwg] Proposal: Media element - add attributes for discovery of playback rate support In-Reply-To: <CAEd8_SzCL+=ipSg5=_D30m+fE3kYky8mYfZbxh3cwG2SUn7CZA@mail.gmail.com> References: <m24nbtdv10.fsf@eoconnor.apple.com> <B7FD9B3C6E47A647A898FFE84DF32B953216A44A@xmb-rcd-x15.cisco.com> <CAG_kaUa9YQGzV6jJczEX90ze+3_LchXUHifS_WJB6Kc-q9cc3w@mail.gmail.com> <51E84C4F.7080900@brendanlong.com> <860226D3-29AC-4709-BB65-DEC36CF7C20E@apple.com> <51E864F3.2060701@brendanlong.com> <alpine.DEB.2.00.1307192108150.27623@ps20323.dreamhostps.com> <CAEd8_SzCL+=ipSg5=_D30m+fE3kYky8mYfZbxh3cwG2SUn7CZA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309102144130.12199@ps20323.dreamhostps.com> On Fri, 19 Jul 2013, Brendan Long wrote: > On Jul 19, 2013 3:14 PM, "Ian Hickson" <ian at hixie.ch> wrote: > > > > > > What if we added a "supportedPlaybackRates" attribute, which holds > > > an array of playback rates supported by the server, plus > > > (optionally) any rates the user agent can support due to the > > > currently buffered data (possibly requiring that the user agent have > > > enough data buffered to play at that speed for some amount of time). > > > > Wouldn't that be 0.0 .. Infinity, basically? > > I've been thinking about this more, and it seems like the buffered > attribute is enough for a JavaScript application to determine for itself > if it's safe to play faster. It does seem useful to expose the rates > supported by the server though, so an application can realize that it's > safe to play at those rates, even if there's not much buffered yet. How do browsers determine what speeds the server supports? IS that information in the protocol? I'd need to read more about this to figure out how to expose it. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From annevk at annevk.nl Tue Sep 10 15:10:22 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Tue, 10 Sep 2013 23:10:22 +0100 Subject: [whatwg] Forcing orientation in content In-Reply-To: <alpine.DEB.2.00.1309102107450.12199@ps20323.dreamhostps.com> References: <516F27BF.4060508@gmail.com> <alpine.DEB.2.00.1307121944480.15729@ps20323.dreamhostps.com> <420FE1A33AB14ACB9667D659D8F415D5@gmail.com> <op.wz8k70f4te2ec8@aimac> <alpine.DEB.2.00.1309102107450.12199@ps20323.dreamhostps.com> Message-ID: <CADnb78jSQJ8LJM6Qq0k1By2MPRWSucBdU0Oe5_OoHegvFgcWfA@mail.gmail.com> On Tue, Sep 10, 2013 at 10:22 PM, Ian Hickson <ian at hixie.ch> wrote: > On Mon, 15 Jul 2013, Kornel Lesi?ski wrote: >> Since specific, locked screen orientation is mostly needed in games, and >> forced rotation is disruptive to other things on the screen (e.g. moving >> buttons/addressbar to other physical edge of the screen), maybe it >> should be tied to the Fullscreen API? >> >> element.requestFullscreen({orientation:'landscape', autorotation:false}) > > That makes sense to me. Anne? Almost missed this! Filed: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23204 Implementer feedback welcome. -- http://annevankesteren.nl/ From tobie.langel at gmail.com Tue Sep 10 15:20:32 2013 From: tobie.langel at gmail.com (Tobie Langel) Date: Wed, 11 Sep 2013 00:20:32 +0200 Subject: [whatwg] Forcing orientation in content In-Reply-To: <alpine.DEB.2.00.1309102107450.12199@ps20323.dreamhostps.com> References: <516F27BF.4060508@gmail.com> <alpine.DEB.2.00.1307121944480.15729@ps20323.dreamhostps.com> <420FE1A33AB14ACB9667D659D8F415D5@gmail.com> <op.wz8k70f4te2ec8@aimac> <alpine.DEB.2.00.1309102107450.12199@ps20323.dreamhostps.com> Message-ID: <54FCF24DEB484FA8BA259B56D55DD661@gmail.com> On Tuesday, September 10, 2013 at 11:22 PM, Ian Hickson wrote: > On Sat, 13 Jul 2013, Tobie Langel wrote: > > It is not uncommon for mobile experiences to rely on the accelerometer > > as an input mechanism, for example to control page scrolling (e.g. > > Instapaper) or for gameplay. > > > > In such cases, auto-rotation of the viewport is completely disruptive to > > the user's experience and needs to be inhibited. > > Sure, but that's an OS-level feature. Arguably. Signaling auto-rotation inhibited requirements isn't, though. That's application-level. Auto-rotation inhibition needs to be automatic and scoped to the document. > > So this isn't so much about forcing orientation as it is about > > inhibiting auto-rotation. > > This would only work if the page was already in the orientation the user > wants, but how can we ensure that? The UA is free to provide whatever UI it wants to allow the user to enable/disable auto-rotation inhibition and/or pick a preferred orientation. From the use cases can be derived requirements for the content author to be able to signal to the UA the preference to inhibit auto-roation. Whether the UA decides to comply to this stated pref, allow its user to override it, etc. should be implementation-specific. > > Your desktop comparison is inadequate, as there aren't comparable > > auto-rotation mechanisms there. > > It would be equivalent to forcing a particular window size. No. A better analogy is the autoplay feature of video elements. Merely a hint that can be overridden by the user/UA. And frankly even that comparison is dodgy: playing a video doesn't have close to the discoverability and usability issues inhibiting auto-rotation at the OS level has. > On Mon, 15 Jul 2013, Kornel Lesi?ski wrote: > > Since specific, locked screen orientation is mostly needed in games, and > > forced rotation is disruptive to other things on the screen (e.g. moving > > buttons/addressbar to other physical edge of the screen), maybe it > > should be tied to the Fullscreen API? > > > > element.requestFullscreen({orientation:'landscape', autorotation:false}) > That makes sense to me. Anne? Agreed these requirements are generally tied to fullscreen/absence of browser-chrome context. Unfortunately, this is achieved using a variety of AP across implementations (e.g. iOS/Android?). So this proposition would only cater to those situation where the fullscreen API was used. --tobie From kornel at geekhood.net Tue Sep 10 16:02:21 2013 From: kornel at geekhood.net (=?utf-8?B?S29ybmVsIExlc2nFhHNraQ==?=) Date: Wed, 11 Sep 2013 00:02:21 +0100 Subject: [whatwg] High-density canvases In-Reply-To: <BBF7063D-027A-48C5-92CD-F5EF829BC800@apple.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> <alpine.DEB.2.00.1309102011560.12210@ps20323.dreamhostps.com> <BBF7063D-027A-48C5-92CD-F5EF829BC800@apple.com> Message-ID: <op.w27wx7bote2ec8@aimac.local> On Tue, 10 Sep 2013 21:22:51 +0100, Dean Jackson <dino at apple.com> wrote: > I think there are two separate things a developer might want: > > - the number of actual pixels that correspond to 1 CSS px without zoom > - the page zoom > > If you merge the two, then an unsuspecting developer might think that > the user has zoomed in by 2x on an iPhone, and decide to make things > smaller. Do you have an example of a page that does make things smaller to counter the zoom? Are you referring to some iPhone-specific workarounds (like position:fixed elements being problematic for zoom?) I assumed that sites which don't like being zoomed in would just block it via <meta viewport>. -- regards, Kornel From dmazzoni at google.com Tue Sep 10 16:19:15 2013 From: dmazzoni at google.com (Dominic Mazzoni) Date: Tue, 10 Sep 2013 16:19:15 -0700 Subject: [whatwg] Outline style to use for drawSystemFocusRing In-Reply-To: <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> References: <CAFz-FYxS-sLLOMA2=5bj-aJ1bmsBq8w_4Rminw_JLCMnYaMfPw@mail.gmail.com> <alpine.DEB.2.00.1307242308540.27623@ps20323.dreamhostps.com> <CAGN7qDCdCR1F-D9PtEKUcHkh5KdwKhum4vEAyUQ0VkLeeC+PCA@mail.gmail.com> <alpine.DEB.2.00.1307292147040.27623@ps20323.dreamhostps.com> <CAGN7qDAaq8XnX1z_BbpLVhgE5m4j--b720ZuHSEzq_iN1es0=Q@mail.gmail.com> <alpine.DEB.2.00.1307300020510.27623@ps20323.dreamhostps.com> <CAGN7qDAjRPOQ25gQT+BY+sp8Y503_9KxTa1j2aZSGYU-9BmBVA@mail.gmail.com> <CAFz-FYzzPFU3g+fM+QGbEDAJ-3DSU2qGHY9R+heZRbAWVAN2rw@mail.gmail.com> <CAGN7qDDu3PNxK9PTVr09sqUc0FrOnXgRaQDwLXQ13BhH_=85Bw@mail.gmail.com> <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> Message-ID: <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> We've finished implementing drawSystemFocusRing and drawCustomFocusRing in Chrome. Try it in Chrome 31 or higher (either canary or dev channel should work today). You'll need to go to chrome://flags and enable *experimental canvas features*, then restart the browser. Here's a demo I built that uses drawSystemFocusRing: http://dmazzoni-google.github.io/canvas-focus-ring-demo/ - Dominic From ian at hixie.ch Tue Sep 10 16:35:00 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Sep 2013 23:35:00 +0000 (UTC) Subject: [whatwg] Should <video controls> generate click events? In-Reply-To: <CAO9Q3iKwpDwFpxaQOBeeg7SQZJR+9rmAVbobF7QU7jcHcO7Uhg@mail.gmail.com> References: <op.wzbxjpiqsr6mfa@kirk> <alpine.DEB.2.00.1308062124340.9685@ps20323.dreamhostps.com> <CAO9Q3iJCXefD+cn+7zsWw6z19Hof5efO85zO=CAvG1GhjxYjGQ@mail.gmail.com> <CAO9Q3iKwpDwFpxaQOBeeg7SQZJR+9rmAVbobF7QU7jcHcO7Uhg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309102145290.12199@ps20323.dreamhostps.com> On Tue, 20 Aug 2013, Edward O'Connor wrote: > >>> > >>> [W]e do want users to be able to bring up the native controls via a > >>> context menu and be able to use them regardless of what the page > >>> does in its event handlers. So, I request that the spec be explicit > >>> that interacting with the video controls does not cause the normal > >>> script-visible events to be fired. > >[?] > >> I've made the spec say this is a valid (and recommended) > >> implemenation strategy. > > > > The change <http://html5.org/r/8134> looks good to me, thanks! > > I don't see why <video controls> should be any different than, say, > <button> here. If I install an event handler on an ancestor of an > element, I'm able to capture events and prevent the descendent element > from seeing them. It's more similar to clicking on a context menu (or indeed a menu bar) than clicking on a button, IMHO. Or like clicking on a control in the popup from <input type=file>. Or clicking in the colour wheel that pops up when you active an <input type=color> control. A <button> is an in-page control. A <video>'s controls are not an in-page control -- there's no in-page element for them, they might not even be positioned over the page (they could be on a palette that the user has dragged out of the page). Also, with <button> the UA and the page are working together. The UA renders the button and shows how it is being pressed; the author makes it do something. The case we're talking about here is where the user presses a button and both the user agent and the author want to do something (and the author has no way to know what the user agent wants to do, or what the user thinks will happen). > A UI which allows users to activate a control "regardless of what the > page does in its event handlers" is a general feature not specific to > media elements?and may be worth considering?but we shouldn't make a > one-off exception to the basic model of DOM events just for <video>. I agree that it's not specific to <video>, but I don't think we have to mention it for other things because it's only <video> where the spec suggests having such a UI model and where browsers have historically also fired an event. On Wed, 21 Aug 2013, Silvia Pfeiffer wrote: > > The paragraph added in <http://html5.org/r/8134> should probably be > restricted to the case where the default video controls have been > enabled by the user (e.g. through the context menu) rather than by the > Web page. It would indeed be bad if the Web page author, who is using > the default controls through a <video controls> attribute could not rely > on the events firing. Why? > IMHO, the example that Philip provided in http://people.opera.com/~** > philipj/click.html <http://people.opera.com/~philipj/click.html> is not > a realistic example of something a JS dev would do. Seem pretty reasonable to me. How else would you make the video play/pause when you click the video frame, yet also have UA controls? On Wed, 21 Aug 2013, Silvia Pfeiffer wrote: > > What I'm saying is that the idea that the JS developer controls > pause/play as well as exposes <video controls> is a far-fetched example. I don't see why. It's what I'd do. On Tue, 20 Aug 2013, Bob Lund wrote: > > What about a Web page that uses JS to control pause/play/etc based on > external messages, say from a WebSocket? The sender in this case acts as > a remote control. That seems unrelated to this issue, unless I'm missing something. On Tue, 20 Aug 2013, Rick Waldron wrote: > > Firefox actually implements click-to-play <video> by default. It's > unfortunate and all <video> interaction projects that I've worked on > directly or consulted for have been forced to include video surface > click -> event.preventDefault() calls to stop the behaviour. This may be > irrelevant to the current discussion, but I'm trying to get a better > understanding for the behavioural changes implied by this spec update, > so correction is highly desirable. The change wouldn't affect this as far as I can tell. We're talking about interaction with specific controls enabled by controls="" (or manually by the user). On Tue, 20 Aug 2013, Glenn Maynard wrote: > > It's the behavior users expect when watching videos, which is the case > <video> should optimize for. If you're doing something else where the > user interacts with the video in other ways, then it's expected that you > need to prevent this behavior explicitly. > > Unlike browser controls, this is visible to scripts and something that > affects authors, so this probably should be in the spec if it isn't. I'm not sure what you want in the spec here. Can you elaborate? On Wed, 21 Aug 2013, Robert O'Callahan wrote: > > Just to be clear, we only do click-to-play when the "controls" attribute > is set. So if that's causing problems for you, I guess you want most of > our built-in controls but not all of them? On Tue, 20 Aug 2013, Rick Waldron wrote: > > Also, at the time, the surface click to play was non-standard and > incredibly annoying because it just "showed up" as someone's pet feature > in Firefox. (I'm still not sure if it's a "standard" feature, I can't > find anything in the spec about it, but I could've just missed it) It's not documented in the spec, but it seems reasonable. Should we make this an explicit activation behaviour for the <video> element if it has a controls="" attribute? On Wed, 21 Aug 2013, Robert O'Callahan wrote: > > I think you basically have to assume that if you specify "controls" then > the controls may accept clicks anywhere in the video element. There's > nothing in the spec to say that the controls must be restricted to a bar > of a certain height at the bottom of the element. True, but there _is_ something now that says that if the browser considers it the user interacting with a control, that there shouldn't be events sent to the page. It's either a control (no events), or an activation behaviour (click events, can be canceled by preventDefault()). On Wed, 21 Aug 2013, Silvia Pfeiffer wrote: > > Indeed. As a JS dev you make a choice: either you roll your own, or you > don't. > > If you roll your own, you write the JS to handle the clicks from the > controls and do video.pause() and video.play() yourself. > > If you don't roll your own, you write <video controls> and you expect > the browser to handle pausing/playing. You don't do what Philip's demo ( > http://people.opera.com/~philipj/click.html) does: handle pause and play > toggling in JS. Because the browser already does that for you. I think doing both is perfectly reasonable, especially since we don't define an explicit activation behaviour currently. > This is why I am saying: Philip's example is not a typical use case. It > only happens when the developer made the choice to roll their own, but > the user activates the default controls (e.g. through the context menu) > as well. This can't happen on YouTube, because YouTube hide away the > context menu on the video element. There's no way for a page to definitely prevent the user from enabling these controls. A browser could always have some other way to enable them, or allow access to the context menu regardless, etc. > However, the patch has a wider implication: namely that the User agent > will suppress all user interaction events from the browser-provided > video controls. I.e. if the user clicks on the play button, no click > event is raised on the video element and the elements that the video > element is in. That's what Edward is objecting to - and I agree. Why do you object? What sense is there in sending the event to the page? On Tue, 20 Aug 2013, Rick Waldron wrote: > > Thank you, this is the clarification I was looking for in my previous > inquiries. Given this explanation, I absolutely object to any change > (such as this) that will effectively cripple the interaction > "programmability" of <video> elements. There are commercial products > that have been developed and are being developed that rely on the > ability to add listeners for events that occur on the <video controls> > as part of reach and engagement data collection, eg. Did the user click > the Play button on the video and watch it all the way through? Did they > click Pause? Did they drag to seek? How can you tell what they clicked? On Wed, 21 Aug 2013, Simon Pieters wrote: > > Just listen for the 'play', 'paused', 'seeked', 'ended' etc events for > this. The change doesn't cripple the <video> API at all. Listening for > 'click' doesn't tell you whether the user clicked play or pause or > seeked or none of those, so it's quite useless for that purpose. Indeed. On Tue, 20 Aug 2013, Peter Occil wrote: > > I'm afraid this example doesn't work well in Firefox and Google Chrome. > It affects not only the video itself but also the browser-provided > controls, and in Firefox it seems to interfere with those controls. I > think that at most the click-to-play behavior should only affect the > video itself, not the buttons or other controls (for this to work, this > would require hit-testing to see if the video or a control was clicked, > and only override the default behavior if the video itself was clicked; > the hit-testing, though, will be browser-specific and may require > defining a new method in the spec). In this way, the video controls > would remain unaffected or be specially handled in a different way. > Another -- less realistic --solution may be to define new event handlers > ("videoclick"? "videopauseclick"?) that only affect parts of the video > element and not the entire video element. On Wed, 21 Aug 2013, Philip J?genstedt wrote: > > Indeed, the demo was precisely to show how the native controls become > unusable when the scripts on the page haven't taken them into > consideration. Right, that's what the spec has since had fixed. On Tue, 20 Aug 2013, Brian Chirls wrote: > > Rick makes some good points. It seems there is a clear cost to this > change, but I'm afraid that there is little benefit, since it won't > prevent the proposed control-breaking scenario anyway. > > It seems to me that danger of Mr. J?genstedt's proposed scenario is that > the user is annoyed by being forced to watch and/or listen to a piece of > media against his/her will. No, the problem is that the page's logic interacts with the browser's logic in a way that nobody can predict or handle. You can't force the user to do anything. They control the computer, at the end of the day, and can do whatever they want. On Wed, 21 Aug 2013, Silvia Pfeiffer wrote: > On Wed, Aug 21, 2013 at 8:59 PM, Simon Pieters <simonp at opera.com> wrote: > > > > The problem was this: if you want to do something when a user clicks > > on a video but not when the user interacts with the native controls, > > you're basically out of luck. > > No, you can do as you do below: you can define an onclick handler and do > something. As long as you don't do something that the native controls > are already taking care of, such as play() and pause(). If you are > indeed trying to influence the play/pause state of the video element > both from script and native controls, you need to be more creative with > your event handlers and use onclick and onpause and onplay event > handlers and carefully manage which ones cancel out which other ones. Since you don't know what the controls can do, I don't see how that makes sense. What if you want to mute the volume when the user clicks on a non-control part of the video, but do nothing when they click on the controls? You can't do it without the browser suppressing events when the user is interacting with the controls. > It also means that in the case of Firefox or in the case of Android > Chrome, where the native controls cover the full video with a overlay > button when not on autoplay, you cannot get any onclick events on the > video element at all. Right, that seems perfectly reasonable. On Wed, 21 Aug 2013, Simon Pieters wrote: > > It may be the case that the change is suboptimal especially now that > some browsers make the whole video a big play/pause button. I don't see how that affects the issue. > For instance, I can imagine exposing a property on the click event that > tells whether the user clicked on the controls, and maybe even what was > being clicked (as a string). > > <video onclick="if (controlsTarget == null) { if (paused) play(); else > pause(); }" ...></video> That seems like it would be far more complicated than necessary. What's the use case? (Why would you ever want the event when the user did click on a control?) On Wed, 21 Aug 2013, Brian Chirls wrote: > > Yes, I think adding information to the click event is a great approach. > Event objects often have additional information, like mouse coordinates > or key code, so it wouldn't feel like an unusual or special case. The > previous approach removes information, where this one adds it. Let's not > forget that the same information should apply to touch and hover events > as well. What is this information for? We're talking about a lot of complexity here, we shouldn't do that unless we have a really solid reason. On Wed, 21 Aug 2013, Tab Atkins Jr. wrote: > > The problem with trying to use click, even with additional information, > is that *the UA-defined controls are unknown*. Maybe they have a > play-pause button. Maybe they've only got a scrubber, and rely on > clicking on the face to play/pause. Maybe they do something quite > different. The HTML spec makes *zero* guarantees about what's inside of > that, which is *intentional*. Indeed. > The correct thing to do is listen for the defined events which indicate > that a particular state has changed. I can't think of a reasonable > use-case for wanting to know which button was clicked that isn't solved > at least as well by just listening for the event for the state change. Indeed. The API is very carefully designed to enable multiple independent controllers to interact sanely, especially the case of UA controls and page controls. On Wed, 21 Aug 2013, Brian Chirls wrote: > > So, perhaps we need a separate set of events. So, when a user clicks the > play button, events would fire in this order: > 1. play requested by user agent from some UI. Cancelable. > 2. 'play' event. The browser has been asked to play the video, whether by > the UI or by API. > 3. 'playing' event. After all the network magic has happened, the video is > actually playing. We already have all these events (not precisely how you describe them, but more or less). Please do see the spec: http://whatwg.org/html#mediaevents On Thu, 22 Aug 2013, Elliott Sprehn wrote: > > This means that if I have <video controls> on the page and then I click > something that shows a non-modal dialog that should dismiss on clicking > elsewhere in the page, and then click the video the page popup doesn't > disappear. If you click one of the controls on that video, right. It's similar to what happens if you click another window, or in an <iframe>. (It's conceptually the same thing.) > Should authors be listening for mouseup instead to take actions when > users click inside <video>? mouseup would be suppressed also. On Thu, 22 Aug 2013, Elliott Sprehn wrote: > > This is wrong, it means I have no way to tell if you click inside the > <video> to dismiss popups or notifications. I don't think we should be > making <video controls> a blackhole to events, it breaks lots of use > cases. What use cases does it break that aren't already broken? If we want to support "any click outside this non-modal <dialog> should close it", then we should just provide that feature directly, we shouldn't rely on authors knowing to check for window.onblur and descendant iframe mouse events and so on. > Instead we should expose the controls as a pseudo element on the event, > just like TransitionEvent has a String pseudoElement so you can tell if > the thing transitioning is the "::before" or the "::after", we should > add ::controls and inside the click handler you can take no action if > the target is the controls. If we assume the new Shadow DOM spec, we > could just use the "part" feature which was designed specifically for > this kind of thing and should be exposed on all events. I don't think this solves the problem -- foolip's example would still fail. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From glenn at zewt.org Tue Sep 10 16:53:10 2013 From: glenn at zewt.org (Glenn Maynard) Date: Tue, 10 Sep 2013 18:53:10 -0500 Subject: [whatwg] Should <video controls> generate click events? In-Reply-To: <alpine.DEB.2.00.1309102145290.12199@ps20323.dreamhostps.com> References: <op.wzbxjpiqsr6mfa@kirk> <alpine.DEB.2.00.1308062124340.9685@ps20323.dreamhostps.com> <CAO9Q3iJCXefD+cn+7zsWw6z19Hof5efO85zO=CAvG1GhjxYjGQ@mail.gmail.com> <CAO9Q3iKwpDwFpxaQOBeeg7SQZJR+9rmAVbobF7QU7jcHcO7Uhg@mail.gmail.com> <alpine.DEB.2.00.1309102145290.12199@ps20323.dreamhostps.com> Message-ID: <CABirCh-GV-BUsFSWUFYbuUh=Qpb84yWLLp3+X8_4CVLM6HUK_A@mail.gmail.com> On Tue, Sep 10, 2013 at 6:35 PM, Ian Hickson <ian at hixie.ch> wrote: > On Tue, 20 Aug 2013, Glenn Maynard wrote: > > It's the behavior users expect when watching videos, which is the case > > <video> should optimize for. If you're doing something else where the > > user interacts with the video in other ways, then it's expected that you > > need to prevent this behavior explicitly. > > > > Unlike browser controls, this is visible to scripts and something that > > affects authors, so this probably should be in the spec if it isn't. > > I'm not sure what you want in the spec here. Can you elaborate? > The same thing you described: the activation behavior for videos should be to toggle play/pause. If only some browsers do it, it's an interop problem, and it seems like the right default behavior. I'm not sure whether this should only be when browser controls are enabled or not. It might be best to keep them orthogonal, so browser controls are always UI controls that don't generate click events at all. On Wed, 21 Aug 2013, Silvia Pfeiffer wrote: > > This is why I am saying: Philip's example is not a typical use case. It > > only happens when the developer made the choice to roll their own, but > > the user activates the default controls (e.g. through the context menu) > > as well. This can't happen on YouTube, because YouTube hide away the > > context menu on the video element. > You can't do that. Browsers have options to remove the ability for pages to prevent the context menu from opening. I always use it, since it's disruptive (the browser's context menu belongs to me, not the page). -- Glenn Maynard From glenn at zewt.org Tue Sep 10 18:24:20 2013 From: glenn at zewt.org (Glenn Maynard) Date: Tue, 10 Sep 2013 20:24:20 -0500 Subject: [whatwg] High-density canvases In-Reply-To: <alpine.DEB.2.00.1309100021320.12210@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <5989691D-4430-4FA0-8E22-BCDD35CC5DC7@apple.com> <alpine.DEB.2.00.1309100021320.12210@ps20323.dreamhostps.com> Message-ID: <CABirCh-6Z2wBhc=upZx7EQpTxThCx8ft4K72Zt0acVm_UTj_NA@mail.gmail.com> On Mon, Sep 9, 2013 at 7:31 PM, Ian Hickson <ian at hixie.ch> wrote: > Right, resetting the context would definitely be part of the deal. This > mode would be specifically defined as a mode where you had to listen to > onresize or your canvas would almost certainly get cleared sooner or > later. In fact, we could go further, and say that canvases that aren't > getting rendered at all (e.g. display:none, off-screen, background tab) > can get cleared, with the deal being that next time you need to show the > canvas you immediately get an onresize. > It would be better if the resize didn't happen until the page is actually ready to re-render. That way, the canvas doesn't flicker if it's rendered before the page actually does render (eg. it may need to reload resources to render). Rendering a blurry canvas briefly is better than rendering a blank canvas. For example, add a method "resizeToCurrentDPI()", and don't do it automatically at all. Fire an event when calling the method *would* cause a change of canvas size. The page can then load resources asynchronously as needed, and call the method when it's ready to redraw, avoiding any period where a blank canvas might be composited. > Yeah, my suggestion, if we do this, would be to not do it until high > density displays are even more widely available than now. This is mostly a > convenience and performance-improving API, not a critical feature add. > High-DPI displays are already widespread in mobile (all Apple devices except for the iPad Mini; the Kindle Fire HD), and by contrast there's no sign of them for desktops, so I think we're either there now or we won't be for a long time. -- Glenn Maynard From jackalmage at gmail.com Tue Sep 10 22:46:24 2013 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Tue, 10 Sep 2013 22:46:24 -0700 Subject: [whatwg] High-density canvases In-Reply-To: <CABirCh-6Z2wBhc=upZx7EQpTxThCx8ft4K72Zt0acVm_UTj_NA@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <5989691D-4430-4FA0-8E22-BCDD35CC5DC7@apple.com> <alpine.DEB.2.00.1309100021320.12210@ps20323.dreamhostps.com> <CABirCh-6Z2wBhc=upZx7EQpTxThCx8ft4K72Zt0acVm_UTj_NA@mail.gmail.com> Message-ID: <CAAWBYDDyVLvsiO4fhgogOgn2XgvDBOswON9+0tPVA9CGvDi7ag@mail.gmail.com> On Tue, Sep 10, 2013 at 6:24 PM, Glenn Maynard <glenn at zewt.org> wrote: >> Yeah, my suggestion, if we do this, would be to not do it until high >> density displays are even more widely available than now. This is mostly a >> convenience and performance-improving API, not a critical feature add. > > High-DPI displays are already widespread in mobile (all Apple devices > except for the iPad Mini; the Kindle Fire HD), and by contrast there's no > sign of them for desktops, so I think we're either there now or we won't be > for a long time. High-end laptops have high-dpi screens (the Pixel I'm using right now has one), and they're slowly spreading down the price scale. ~TJ From robert at ocallahan.org Wed Sep 11 01:18:51 2013 From: robert at ocallahan.org (Robert O'Callahan) Date: Wed, 11 Sep 2013 01:18:51 -0700 Subject: [whatwg] High-density canvases In-Reply-To: <CAAWBYDDyVLvsiO4fhgogOgn2XgvDBOswON9+0tPVA9CGvDi7ag@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <5989691D-4430-4FA0-8E22-BCDD35CC5DC7@apple.com> <alpine.DEB.2.00.1309100021320.12210@ps20323.dreamhostps.com> <CABirCh-6Z2wBhc=upZx7EQpTxThCx8ft4K72Zt0acVm_UTj_NA@mail.gmail.com> <CAAWBYDDyVLvsiO4fhgogOgn2XgvDBOswON9+0tPVA9CGvDi7ag@mail.gmail.com> Message-ID: <CAOp6jLZ+EA355PgSx08b+jqv=e=gvwMA3cbTnK2hkRiX3Bb8sQ@mail.gmail.com> On Tue, Sep 10, 2013 at 10:46 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote: > High-end laptops have high-dpi screens (the Pixel I'm using right now > has one), and they're slowly spreading down the price scale. > On Mac there are Retinas of course, and on Windows Firefox defaults to a non-1.0 devicePixelRatio on many systems now (anything where the default "Windows font DPI" is not 96). Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * From robert at ocallahan.org Wed Sep 11 01:20:21 2013 From: robert at ocallahan.org (Robert O'Callahan) Date: Wed, 11 Sep 2013 01:20:21 -0700 Subject: [whatwg] High-density canvases In-Reply-To: <CAGN7qDCC=8EZUpEmN=10tcWGU=8TPQ7rej+sOGhbPaWqqAjWRA@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> <CAGN7qDCC=8EZUpEmN=10tcWGU=8TPQ7rej+sOGhbPaWqqAjWRA@mail.gmail.com> Message-ID: <CAOp6jLZFD_HVKgEfEUB0myCdvz60i_=1NASVQ-YKyzcHxkDxVw@mail.gmail.com> On Tue, Sep 10, 2013 at 1:26 PM, Rik Cabanier <cabanier at gmail.com> wrote: > There's a thread on www-style: > http://lists.w3.org/Archives/Public/www-style/2012Nov/0144.html > It's been in firefox for a while and blink is going to ship it soon: > > https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/RyUSi3zdumQ > devicePixelRatio has reflected page zoom in Firefox ever since we first exposed it (because the thing it maps to internally has always been affected by page zoom). > > > Actually what I really think we should do is also change the > > > window.devicePixelRatio for pinch zoom. Combined with the suggestions > for > > > canvas, that would allow (as Rik pointed out on IRC) for high-quality > > > canvas all the way zoomed in, and for cheap canvases when zoomed out > > I believe pinch zoom should not change devicePixelRatio. It would be nice > if there was a standard way to determine pinch zoom though and if the > canvas could automatically resize. > Pinch-zoom is hard because we don't want to trigger reflows or other expensive behavior on pinch-zoom. I'd leave pinch-zoom out of it for now. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * From simonp at opera.com Wed Sep 11 01:48:29 2013 From: simonp at opera.com (Simon Pieters) Date: Wed, 11 Sep 2013 10:48:29 +0200 Subject: [whatwg] Should <video controls> generate click events? In-Reply-To: <alpine.DEB.2.00.1309102145290.12199@ps20323.dreamhostps.com> References: <op.wzbxjpiqsr6mfa@kirk> <alpine.DEB.2.00.1308062124340.9685@ps20323.dreamhostps.com> <CAO9Q3iJCXefD+cn+7zsWw6z19Hof5efO85zO=CAvG1GhjxYjGQ@mail.gmail.com> <CAO9Q3iKwpDwFpxaQOBeeg7SQZJR+9rmAVbobF7QU7jcHcO7Uhg@mail.gmail.com> <alpine.DEB.2.00.1309102145290.12199@ps20323.dreamhostps.com> Message-ID: <op.w28n23m8idj3kv@simons-macbook-pro.local> On Wed, 11 Sep 2013 01:35:00 +0200, Ian Hickson <ian at hixie.ch> wrote: > On Tue, 20 Aug 2013, Rick Waldron wrote: >> >> Also, at the time, the surface click to play was non-standard and >> incredibly annoying because it just "showed up" as someone's pet feature >> in Firefox. (I'm still not sure if it's a "standard" feature, I can't >> find anything in the spec about it, but I could've just missed it) > > It's not documented in the spec, but it seems reasonable. > On Wed, 21 Aug 2013, Robert O'Callahan wrote: >> >> I think you basically have to assume that if you specify "controls" then >> the controls may accept clicks anywhere in the video element. There's >> nothing in the spec to say that the controls must be restricted to a bar >> of a certain height at the bottom of the element. > > True, but there _is_ something now that says that if the browser > considers > it the user interacting with a control, that there shouldn't be events > sent to the page. It's either a control (no events), or an activation > behaviour (click events, can be canceled by preventDefault()). Saying that Firefox's "click anywhere to play" isn't a control but rather activation behavior for the element makes sense. If other browsers want to implement that behavior, it would be good if the spec called out this difference. > Should we make this an explicit activation behaviour for the <video> > element if it has a controls="" attribute? That might be good so that the behavior is consistent between browsers. However, I think it should be conditional on whether the controls are visible rather than whether the controls attribute is present. -- Simon Pieters Opera Software From philipj at opera.com Wed Sep 11 01:51:44 2013 From: philipj at opera.com (=?ISO-8859-1?Q?Philip_J=E4genstedt?=) Date: Wed, 11 Sep 2013 10:51:44 +0200 Subject: [whatwg] Should <video controls> generate click events? In-Reply-To: <op.w28n23m8idj3kv@simons-macbook-pro.local> References: <op.wzbxjpiqsr6mfa@kirk> <alpine.DEB.2.00.1308062124340.9685@ps20323.dreamhostps.com> <CAO9Q3iJCXefD+cn+7zsWw6z19Hof5efO85zO=CAvG1GhjxYjGQ@mail.gmail.com> <CAO9Q3iKwpDwFpxaQOBeeg7SQZJR+9rmAVbobF7QU7jcHcO7Uhg@mail.gmail.com> <alpine.DEB.2.00.1309102145290.12199@ps20323.dreamhostps.com> <op.w28n23m8idj3kv@simons-macbook-pro.local> Message-ID: <CAMQvoC=Na_25VMzLeY=fWhtQ1Ot-mPPhy5G=4stCfJaUcGDdMw@mail.gmail.com> On Wed, Sep 11, 2013 at 10:48 AM, Simon Pieters <simonp at opera.com> wrote: > On Wed, 11 Sep 2013 01:35:00 +0200, Ian Hickson <ian at hixie.ch> wrote: > >> On Wed, 21 Aug 2013, Robert O'Callahan wrote: >>> >>> >>> I think you basically have to assume that if you specify "controls" then >>> the controls may accept clicks anywhere in the video element. There's >>> nothing in the spec to say that the controls must be restricted to a bar >>> of a certain height at the bottom of the element. >> >> >> True, but there _is_ something now that says that if the browser considers >> it the user interacting with a control, that there shouldn't be events >> sent to the page. It's either a control (no events), or an activation >> behaviour (click events, can be canceled by preventDefault()). > > > Saying that Firefox's "click anywhere to play" isn't a control but rather > activation behavior for the element makes sense. If other browsers want to > implement that behavior, it would be good if the spec called out this > difference. > > >> Should we make this an explicit activation behaviour for the <video> >> element if it has a controls="" attribute? > > > That might be good so that the behavior is consistent between browsers. > However, I think it should be conditional on whether the controls are > visible rather than whether the controls attribute is present. What does "visible" mean here, is it to handle cases where the UA force-enables the controls without adding the controls attribute to the DOM? Philip From jackalmage at gmail.com Wed Sep 11 02:04:56 2013 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Wed, 11 Sep 2013 02:04:56 -0700 Subject: [whatwg] High-density canvases In-Reply-To: <CAOp6jLZFD_HVKgEfEUB0myCdvz60i_=1NASVQ-YKyzcHxkDxVw@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> <CAGN7qDCC=8EZUpEmN=10tcWGU=8TPQ7rej+sOGhbPaWqqAjWRA@mail.gmail.com> <CAOp6jLZFD_HVKgEfEUB0myCdvz60i_=1NASVQ-YKyzcHxkDxVw@mail.gmail.com> Message-ID: <CAAWBYDBKs481S3c14TEnatWuvJrtg4F9jARy6wKVHAfER8Q+yg@mail.gmail.com> On Wed, Sep 11, 2013 at 1:20 AM, Robert O'Callahan <robert at ocallahan.org> wrote: >> > > Actually what I really think we should do is also change the >> > > window.devicePixelRatio for pinch zoom. Combined with the suggestions >> for >> > > canvas, that would allow (as Rik pointed out on IRC) for high-quality >> > > canvas all the way zoomed in, and for cheap canvases when zoomed out >> >> I believe pinch zoom should not change devicePixelRatio. It would be nice >> if there was a standard way to determine pinch zoom though and if the >> canvas could automatically resize. >> > > Pinch-zoom is hard because we don't want to trigger reflows or other > expensive behavior on pinch-zoom. I'd leave pinch-zoom out of it for now. Yes. Somewhere (HTML? CSSOM? CSSOM-View?) needs to define "layout-affecting zoom" and "visual zoom", define what goes where, and then we can just hook things to "layout-affecting zoom" and be done with it. (I think dbaron had some name suggestions, or at least some name *objections*, related to this stuff.) ~TJ From simonp at opera.com Wed Sep 11 02:18:00 2013 From: simonp at opera.com (Simon Pieters) Date: Wed, 11 Sep 2013 11:18:00 +0200 Subject: [whatwg] Should <video controls> generate click events? In-Reply-To: <CAMQvoC=Na_25VMzLeY=fWhtQ1Ot-mPPhy5G=4stCfJaUcGDdMw@mail.gmail.com> References: <op.wzbxjpiqsr6mfa@kirk> <alpine.DEB.2.00.1308062124340.9685@ps20323.dreamhostps.com> <CAO9Q3iJCXefD+cn+7zsWw6z19Hof5efO85zO=CAvG1GhjxYjGQ@mail.gmail.com> <CAO9Q3iKwpDwFpxaQOBeeg7SQZJR+9rmAVbobF7QU7jcHcO7Uhg@mail.gmail.com> <alpine.DEB.2.00.1309102145290.12199@ps20323.dreamhostps.com> <op.w28n23m8idj3kv@simons-macbook-pro.local> <CAMQvoC=Na_25VMzLeY=fWhtQ1Ot-mPPhy5G=4stCfJaUcGDdMw@mail.gmail.com> Message-ID: <op.w28pgaa5idj3kv@simons-macbook-pro.local> On Wed, 11 Sep 2013 10:51:44 +0200, Philip J?genstedt <philipj at opera.com> wrote: >> That might be good so that the behavior is consistent between browsers. >> However, I think it should be conditional on whether the controls are >> visible rather than whether the controls attribute is present. > > What does "visible" mean here, is it to handle cases where the UA > force-enables the controls without adding the controls attribute to > the DOM? Yes. http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#expose-a-user-interface-to-the-user -- Simon Pieters Opera Software From philipj at opera.com Wed Sep 11 02:18:28 2013 From: philipj at opera.com (=?ISO-8859-1?Q?Philip_J=E4genstedt?=) Date: Wed, 11 Sep 2013 11:18:28 +0200 Subject: [whatwg] Should <video controls> generate click events? In-Reply-To: <op.w28pgaa5idj3kv@simons-macbook-pro.local> References: <op.wzbxjpiqsr6mfa@kirk> <alpine.DEB.2.00.1308062124340.9685@ps20323.dreamhostps.com> <CAO9Q3iJCXefD+cn+7zsWw6z19Hof5efO85zO=CAvG1GhjxYjGQ@mail.gmail.com> <CAO9Q3iKwpDwFpxaQOBeeg7SQZJR+9rmAVbobF7QU7jcHcO7Uhg@mail.gmail.com> <alpine.DEB.2.00.1309102145290.12199@ps20323.dreamhostps.com> <op.w28n23m8idj3kv@simons-macbook-pro.local> <CAMQvoC=Na_25VMzLeY=fWhtQ1Ot-mPPhy5G=4stCfJaUcGDdMw@mail.gmail.com> <op.w28pgaa5idj3kv@simons-macbook-pro.local> Message-ID: <CAMQvoC=X3m7N4FiAXhP4S+HQF+4EL-zivwEZY6jGVsFaOGEZVg@mail.gmail.com> On Wed, Sep 11, 2013 at 11:18 AM, Simon Pieters <simonp at opera.com> wrote: > On Wed, 11 Sep 2013 10:51:44 +0200, Philip J?genstedt <philipj at opera.com> > wrote: > >>> That might be good so that the behavior is consistent between browsers. >>> However, I think it should be conditional on whether the controls are >>> visible rather than whether the controls attribute is present. >> >> >> What does "visible" mean here, is it to handle cases where the UA >> force-enables the controls without adding the controls attribute to >> the DOM? > > > Yes. > > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#expose-a-user-interface-to-the-user Right, connecting it to the "expose a user interface to the user" concept seems best. Philip From annevk at annevk.nl Wed Sep 11 03:53:35 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Wed, 11 Sep 2013 11:53:35 +0100 Subject: [whatwg] URL resolution of fragment urls in html5 webapps In-Reply-To: <alpine.DEB.2.00.1309100013320.12199@ps20323.dreamhostps.com> References: <CAO9zZYMo79Dqn-EK8S0j-M9sNJeFEGQg_XgP6+fsszDmq5oDMQ@mail.gmail.com> <CANr5HFXkxQuiy+n1jDkd=jP92Wz=E0_BrGbo40A0xxjpbAw2dQ@mail.gmail.com> <CAO9zZYOuSfkkGbqFWeeJ-gu1k0mZLFfnjrgkiweL+EN9aGGoiw@mail.gmail.com> <alpine.DEB.2.00.1309100013320.12199@ps20323.dreamhostps.com> Message-ID: <CADnb78iS2LsMporp8qKxFmmBy-rHH7q++_-osP94oaWAtjzdcw@mail.gmail.com> On Tue, Sep 10, 2013 at 8:34 PM, Ian Hickson <ian at hixie.ch> wrote: > On Wed, 10 Jul 2013, Rafael Weinstein wrote: >> I'm curious: Is it useful to have fragment URL resolve against anything >> other than the "display" url? I.e. when is the current behavior wrt >> fragments appropriate. > > It's a good question. I thought the old IETF specs for URLs said you had > to do otherwise, but nobody seems to have implemented that. Browsers have been inconsistent on this actually, not sure if they still are. I think if we want to do this differently, then after trimming whitespace to obtain the URL, the <a> element should have a special case for # and pick a different base URL at that point. https://tools.ietf.org/html/rfc2396#section-4.2 has the vague wording that does not take the base URL into account. In https://tools.ietf.org/html/rfc3986#section-4.4 it does. The problem with the former is that it's not clear when it applies, but we could make that clear by only doing it in certain contexts, as I suggested above. -- http://annevankesteren.nl/ From annevk at annevk.nl Wed Sep 11 04:03:00 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Wed, 11 Sep 2013 12:03:00 +0100 Subject: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use In-Reply-To: <alpine.DEB.2.00.1309101934520.12199@ps20323.dreamhostps.com> References: <514A7477.6040905@mit.edu> <alpine.DEB.2.00.1307121809430.15729@ps20323.dreamhostps.com> <51E04C76.30200@mit.edu> <CAJE5ia_WTqejajPZVxf=cxTipvPyE=g0FWQfj-kJaj1tK583kw@mail.gmail.com> <51E04FDD.2080702@mit.edu> <CADnb78iniuYkyc4cH+RECg1p=ANVQPMz_sod9_Q11C=YDN=ZXg@mail.gmail.com> <alpine.DEB.2.00.1309101934520.12199@ps20323.dreamhostps.com> Message-ID: <CADnb78j7UJe1rbCTuuvpXJhfHKkcib2Mqnc=iUoYS+Yh+p8itA@mail.gmail.com> On Tue, Sep 10, 2013 at 8:54 PM, Ian Hickson <ian at hixie.ch> wrote: > On Fri, 12 Jul 2013, Anne van Kesteren wrote: >> But then we shouldn't garble pathname either and we do because we have >> to. So I'm not sure that line of reasoning makes sense. I do think we >> should offer some kind of conversion utility between the two. > > It is unfortunate that resolving URLs does that, it's true. But just > because we're constrained here, why should we mess up domains also? Consistency. It means the entire URL is effectively a byte sequence. And it's very clear what the DNS lookup will be. And given that they keep insisting on changing what certain code points map to over in IETF-land (with limited support from browser vendors :/), it seems safer too. -- http://annevankesteren.nl/ From ian at hixie.ch Wed Sep 11 11:21:06 2013 From: ian at hixie.ch (Ian Hickson) Date: Wed, 11 Sep 2013 18:21:06 +0000 (UTC) Subject: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use In-Reply-To: <CADnb78j7UJe1rbCTuuvpXJhfHKkcib2Mqnc=iUoYS+Yh+p8itA@mail.gmail.com> References: <514A7477.6040905@mit.edu> <alpine.DEB.2.00.1307121809430.15729@ps20323.dreamhostps.com> <51E04C76.30200@mit.edu> <CAJE5ia_WTqejajPZVxf=cxTipvPyE=g0FWQfj-kJaj1tK583kw@mail.gmail.com> <51E04FDD.2080702@mit.edu> <CADnb78iniuYkyc4cH+RECg1p=ANVQPMz_sod9_Q11C=YDN=ZXg@mail.gmail.com> <alpine.DEB.2.00.1309101934520.12199@ps20323.dreamhostps.com> <CADnb78j7UJe1rbCTuuvpXJhfHKkcib2Mqnc=iUoYS+Yh+p8itA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309111819130.12210@ps20323.dreamhostps.com> On Wed, 11 Sep 2013, Anne van Kesteren wrote: > On Tue, Sep 10, 2013 at 8:54 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Fri, 12 Jul 2013, Anne van Kesteren wrote: > >> But then we shouldn't garble pathname either and we do because we > >> have to. So I'm not sure that line of reasoning makes sense. I do > >> think we should offer some kind of conversion utility between the > >> two. > > > > It is unfortunate that resolving URLs does that, it's true. But just > > because we're constrained here, why should we mess up domains also? > > Consistency. Surely the consistency of the API matching the input is more important than the consistency of the API _not_ matching the input... > It means the entire URL is effectively a byte sequence. I don't know what you mean here. > And it's very clear what the DNS lookup will be. Why do you think people care more about that than about the URL matching what they wrote in the markup? > And given that they keep insisting on changing what certain code points > map to over in IETF-land (with limited support from browser vendors :/), > it seems safer too. I don't understand what is safer. Surely if the punycoding step keeps changing, it's less safe, since it'll mean that the results will change without the author expecting it. If we don't punycode in the API, then the result will be the same regardless of the punycode step. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Sep 11 11:22:09 2013 From: ian at hixie.ch (Ian Hickson) Date: Wed, 11 Sep 2013 18:22:09 +0000 (UTC) Subject: [whatwg] URL resolution of fragment urls in html5 webapps In-Reply-To: <CADnb78iS2LsMporp8qKxFmmBy-rHH7q++_-osP94oaWAtjzdcw@mail.gmail.com> References: <CAO9zZYMo79Dqn-EK8S0j-M9sNJeFEGQg_XgP6+fsszDmq5oDMQ@mail.gmail.com> <CANr5HFXkxQuiy+n1jDkd=jP92Wz=E0_BrGbo40A0xxjpbAw2dQ@mail.gmail.com> <CAO9zZYOuSfkkGbqFWeeJ-gu1k0mZLFfnjrgkiweL+EN9aGGoiw@mail.gmail.com> <alpine.DEB.2.00.1309100013320.12199@ps20323.dreamhostps.com> <CADnb78iS2LsMporp8qKxFmmBy-rHH7q++_-osP94oaWAtjzdcw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309111821360.12210@ps20323.dreamhostps.com> On Wed, 11 Sep 2013, Anne van Kesteren wrote: > On Tue, Sep 10, 2013 at 8:34 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Wed, 10 Jul 2013, Rafael Weinstein wrote: > >> I'm curious: Is it useful to have fragment URL resolve against > >> anything other than the "display" url? I.e. when is the current > >> behavior wrt fragments appropriate. > > > > It's a good question. I thought the old IETF specs for URLs said you > > had to do otherwise, but nobody seems to have implemented that. > > Browsers have been inconsistent on this actually, not sure if they still > are. I think if we want to do this differently, then after trimming > whitespace to obtain the URL, the <a> element should have a special case > for # and pick a different base URL at that point. > > https://tools.ietf.org/html/rfc2396#section-4.2 has the vague wording > that does not take the base URL into account. In > https://tools.ietf.org/html/rfc3986#section-4.4 it does. The problem > with the former is that it's not clear when it applies, but we could > make that clear by only doing it in certain contexts, as I suggested > above. Well presumably we wouldn't want to only do it for <a>, since then links would work but SVG wouldn't (the exact opposite of the situation in Chrome now, for what it's worth). -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Sep 11 11:24:29 2013 From: ian at hixie.ch (Ian Hickson) Date: Wed, 11 Sep 2013 18:24:29 +0000 (UTC) Subject: [whatwg] High-density canvases In-Reply-To: <CAOp6jLZFD_HVKgEfEUB0myCdvz60i_=1NASVQ-YKyzcHxkDxVw@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> <CAGN7qDCC=8EZUpEmN=10tcWGU=8TPQ7rej+sOGhbPaWqqAjWRA@mail.gmail.com> <CAOp6jLZFD_HVKgEfEUB0myCdvz60i_=1NASVQ-YKyzcHxkDxVw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309111823370.12210@ps20323.dreamhostps.com> On Wed, 11 Sep 2013, Robert O'Callahan wrote: > > Pinch-zoom is hard because we don't want to trigger reflows or other > expensive behavior on pinch-zoom. I'd leave pinch-zoom out of it for > now. Unless I'm missing something fundamental, changing the pixel density doesn't cause a layout, it's changing the width that causes a layout. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From cabanier at gmail.com Wed Sep 11 11:57:11 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Wed, 11 Sep 2013 11:57:11 -0700 Subject: [whatwg] High-density canvases In-Reply-To: <alpine.DEB.2.00.1309111823370.12210@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> <CAGN7qDCC=8EZUpEmN=10tcWGU=8TPQ7rej+sOGhbPaWqqAjWRA@mail.gmail.com> <CAOp6jLZFD_HVKgEfEUB0myCdvz60i_=1NASVQ-YKyzcHxkDxVw@mail.gmail.com> <alpine.DEB.2.00.1309111823370.12210@ps20323.dreamhostps.com> Message-ID: <CAGN7qDDuFbHLb=O3bORKT1QuS2mrWnc-5e=hhVL+kQQ8K135cg@mail.gmail.com> On Wed, Sep 11, 2013 at 11:24 AM, Ian Hickson <ian at hixie.ch> wrote: > On Wed, 11 Sep 2013, Robert O'Callahan wrote: > > > > Pinch-zoom is hard because we don't want to trigger reflows or other > > expensive behavior on pinch-zoom. I'd leave pinch-zoom out of it for > > now. > > Unless I'm missing something fundamental, changing the pixel density > doesn't cause a layout, it's changing the width that causes a layout. It will do a layout if the width is directly or indirectly dependent on the CSS pixelratio. For instance, notice how the text boxes reflow if you change the page zoom: http://jsfiddle.net/BtAK7/1/ From ian at hixie.ch Wed Sep 11 12:47:29 2013 From: ian at hixie.ch (Ian Hickson) Date: Wed, 11 Sep 2013 19:47:29 +0000 (UTC) Subject: [whatwg] Sortable Tables In-Reply-To: <CALWjOx+vrmxTn6FA1dv+yWToix2frcWVtH7pr3mEoqUH0gCWZw@mail.gmail.com> References: <F9859A39-E9E5-43AC-BFBA-0786EDC128BC@crissov.de> <Pine.LNX.4.64.1211061922450.2478@ps20323.dreamhostps.com> <CAPGwD7iWT4Z_Ea14W0zapA69B-HaG_ZixwkF3jkg0=w3Jw0NyQ@mail.gmail.com> <Pine.LNX.4.64.1212270141200.16292@ps20323.dreamhostps.com> <50DDA850.7080307@gmx.ch> <alpine.DEB.2.00.1307182217440.9685@ps20323.dreamhostps.com> <CALWjOx+vrmxTn6FA1dv+yWToix2frcWVtH7pr3mEoqUH0gCWZw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309111857000.12210@ps20323.dreamhostps.com> On Fri, 19 Jul 2013, Stuart Langridge wrote: > On Thu, Jul 18, 2013 at 11:48 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > > > but <time> is more of a problem if you have multiple things in one > > > cell. For example, one semi-common pattern is to put some data and > > > an input type=checkbox in a single cell, like <td>Wed 7th November, > > > 10.00am GMT <input type="checkbox" name="whatever"></td> > > > > Why can't the checkbox be in a separate cell? > > I'm not saying that this is the way I do it: I'm saying this is what > authors are currently doing. If the checkboxes need to be in a separate > cell, then OK, but we'd need to explain that that's the case: that is, > the answer to "how do I sort a table by a column containing both data > and a checkbox" is "you can't. Put the checkboxes in a separate column." Yeah, fair enough. Hmm. So what should we do? Allow there to be multiple elements in the cell, but if we see a <time>/<meter>/<progress>/<data>, ignore all the others for sorting? Just look at the first element and if it's one of those, ignore all the others for sorting? I fear situations where people have two <time> elements and want them sorting by one then the other, or something. We could also have a way to say that certain elements are ignored... ignore all <input> and <img> elements? Ignore all elements with a new ignore-me- when-sorting="" attribute? I agree we should support the case you give. > Indeed, the objection to wrapping the whole cell content in <time> > applies to any cell which contains a time *and something else*: for > example, <td>Wed 7th November, 10.00am GMT <img src="morning.png"></td> > where the image displays a nice picture of the sun so you can see that > it's morning, but is only debatably part of the actual time itself. I'd feel much more comfortable saying the sun was part of the time than about the checkbox being part of the time. :-) > (And if you put it in a separate column, then there'll be a cell border > between the time and the icon.) That can be fixed with CSS, of course. > > > Using <data> to wrap the whole cell is OK, but using <time> to wrap > > > a bunch of non-time content isn't, really. In this situation would > > > you recommend <td><data value="2012-11-07T10:00Z"><time > > > datetime="2012-11-07T10:00Z">Wed 7th November, 10.00am > > > GMT</time></data></td> which seems rather redundant to me? > > > > I would recommend using two cells, but you could do that too. It would > > mean the keys were compared as strings, though, rather than as > > datetimes. Things wouldn't work if you mixed <data> and <time> > > elements with those values (e.g. if some cells didn't have checkboxes > > and so you used just <time> in some cases), since strings sort after > > times. > > erm. Why is the sort clever about datetimes? Time zones, knowing that "1:01" comes before "01:02", knowing that "P1D" comes before "25h", knowing that "1000-01-01" comes before "01010-10-10", knowing that "-01:00" comes before "Z" comes before "+01:00", knowing that 2013-W37 comes before 2013-10-11 but after 2013-10-09, etc. > Specifically, in order to specify a datetime attribute on a time > element, you have to specify it as a string, and those strings sort > correctly in order with other datetime strings. Not necessarily. Leading zeros are a problem for times, local-dates- and-times, and yearless dates, and all the other time formats have crazy stuff like time zones, multiple valid formats, etc. Also, the spec supports mixing different formats like week dates and years with date-and- time formats. > > > Maybe pass a cloneNode of each TD? > > > > Too expensive (what if one of the nodes is a 24 MB image, or a > > plugin?). > > But the cloned node isn't inserted into the document, right? Surely no > rendering engine is going to fully instantiate a 24MB image that's not > even in the document? An <img> element is instantiated when created, regardless of whether it's in a document or not. That's how you can do preloading of images for rollovers, if you're stuck in the 90s. :-) > > > Or have the sorter work out the sortable *value* of the field (from > > > the content, or the <data value> wrapper) and then pass the values, > > > not the actual cells? Then the comparator can't destroy anything. > > > > It seems to me like that doesn't give you anything that you couldn't > > do by just setting the keys manually on the table before the sort > > happens (which you can do easily onsort="" in the current model). > > Big difference: setting the keys manually onsort is indeed something > that the author can do. But calculating the sortable value of the cell > (either from an explicitly set key, or from the cell content) is > something that the *browser* can do: that is, it can be part of the > spec. So then you're never in danger from dangerous comparators, because > the sort engine algorithm is: (1) for each cell in the column, calculate > its sortable value and make a list of [sortable value, reference to > cell], (2) sort that list, and for each comparison during sorting pass > the two sortable values you want to compare, but *not* the cell > references, to the comparator, (3) now you have a sorted list; shuffle > the actual table rows into the order of the list. This is what my > sorttable script does, and for exactly the reasons that you outline; > that a sort comparator function doesn't get passed the actual TDs, just > their content. If you call script at all, it can mess up the table, whether or not you hand it a reference to the table. But my point above was: what's the difference between allowing authors to set the comparator function, and letting authors assign the sortable value when there's a known comparator function? Both get you the same effect, surely. The advantage is one doesn't need to involve calling script while the table is being sorted. > > > Left-hand header columns (although as noted this is sorta-kinda > > > presentational and should be done with tr::before, but authors will > > > do it in the HTML for backwards-compatiblity if nothing else). > > > > Not sure I follow that one. > > I, Mr Author, have a table on my page, and that table has row numbers, > explicitly in the HTML as the first column. (<tr><td>1</td><td>...</tr>) > I wrote the page 5 years ago, and half my users are still, depressingly, > on IE6. The other half are all running Chrome Canary, usefully. So this > sorting stuff arrives and I think: I'd like this table to be sortable. > So I bang the sort stuff in, knowing full well that the IE6 people don't > get to sort the table, and that's fine (progressive enhancement, wot?), > and the Chrome people say "oh, man, the row numbers get jumbled!" and I > say "ah, you're quite right", and remove them from the HTML to be > replaced with CSS tr::before { content: index(row) } or something. And > then the IE6 people say: we don't have any row numbers any more! I am > not sure how this is reconcilable. Either older browsers don't get row > numbers, or newer ones get them jumbled... I don't know how to fix this in a world where we're sorting groups of rows. I mean, if group #1 is a single row, and group #2 has two rows, and group #3 has three rows but its first cell spans all three, what do you do when the order is changed to #3-#1-#2, if the first column is one of these "keep the numbers consistent" columns? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Sep 11 13:04:40 2013 From: ian at hixie.ch (Ian Hickson) Date: Wed, 11 Sep 2013 20:04:40 +0000 (UTC) Subject: [whatwg] High-density canvases In-Reply-To: <CAGN7qDDuFbHLb=O3bORKT1QuS2mrWnc-5e=hhVL+kQQ8K135cg@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> <CAGN7qDCC=8EZUpEmN=10tcWGU=8TPQ7rej+sOGhbPaWqqAjWRA@mail.gmail.com> <CAOp6jLZFD_HVKgEfEUB0myCdvz60i_=1NASVQ-YKyzcHxkDxVw@mail.gmail.com> <alpine.DEB.2.00.1309111823370.12210@ps20323.dreamhostps.com> <CAGN7qDDuFbHLb=O3bORKT1QuS2mrWnc-5e=hhVL+kQQ8K135cg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309112004080.12199@ps20323.dreamhostps.com> On Wed, 11 Sep 2013, Rik Cabanier wrote: > On Wed, Sep 11, 2013 at 11:24 AM, Ian Hickson <ian at hixie.ch> wrote: > > On Wed, 11 Sep 2013, Robert O'Callahan wrote: > > > > > > Pinch-zoom is hard because we don't want to trigger reflows or other > > > expensive behavior on pinch-zoom. I'd leave pinch-zoom out of it for > > > now. > > > > Unless I'm missing something fundamental, changing the pixel density > > doesn't cause a layout, it's changing the width that causes a layout. > > It will do a layout if the width is directly or indirectly dependent on > the CSS pixelratio. For instance, notice how the text boxes reflow if > you change the page zoom: http://jsfiddle.net/BtAK7/1/ Sure. But pinch-zoom doesn't change the width. (Page zoom does.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From barraclough at apple.com Wed Sep 11 15:05:06 2013 From: barraclough at apple.com (Gavin Barraclough) Date: Wed, 11 Sep 2013 15:05:06 -0700 Subject: [whatwg] [[GetOwnProperty]] for named properties of the Window object In-Reply-To: <52293AC6.5020108@mit.edu> References: <52600B08-E2BB-4AA3-877E-797E1CF687BC@apple.com> <52293AC6.5020108@mit.edu> Message-ID: <C9BAE4B7-C54B-451A-872D-40D6CEAED23C@apple.com> Hi Boris, Thanks, this is really helpful. On Sep 5, 2013, at 7:15 PM, Boris Zbarsky <bzbarsky at MIT.EDU> wrote: > Ccing public-script-coord, since that's the right place for this discussion (because WebIDL is the relevant specification). > > On 9/5/13 6:45 PM, Gavin Barraclough wrote: >> Firefox and Chrome both return descriptors from an object on the prototype chain per the spec > > Chrome doesn't quite follow the spec here, for what it's worth: it returns them from Window.prototype as far as I can tell, not from an actual named properties object. Interesting, I had just assumed this was okay ? is it not spec-compliant for Window.prototype to be a named properties object? >> attributes of the value are configured differently, with enumerable set to false, writable and configurable set to true. > > Current tip Firefox returns {"configurable":true,"enumerable":true,"writable":true} and enumerates the properties. Probably a change from https://bugzilla.mozilla.org/show_bug.cgi?id=895758 to align better with the spec in terms of the enumeration behavior. > >> There seem to be some compelling reasons to follow Firefox / Chrome (writable true seems more congruent with ECMA262 specified [[Put]] > > Indeed. I think the current setup in the spec would make window.foo not settable if <img id="foo"> exists.... That seems bad. I believe these properties are implemented as shadowable in the same way as [Replaceable] properties, so I was somewhat expecting the spec to define properties returned by named property objects to implicitly have the [Replaceable] extended attribute specified in WebIDL (and then assume a modified behaviour of ES [Put] for properties with this attribute, to permit overwrite even if readonly). But I?m not yet familiar enough with the spec to know if this is a reasonable line of thought. :-) Thanks, Gavin >> unless there is another mechanism I?m missing here, enumerable is odd since I don?t think the spec says anything about [[GetOwnPropertyNames]]) > > It doesn't, but it does talk about enumeration; see http://dev.w3.org/2006/webapi/WebIDL/#property-enumeration (whether that's applicable to the Named Properties Object is an interesting question). > > Granted, I would rather that were defined in terms of [[GetOwnPropertyNames]] on the relevant objects instead; that's what actually needs to happen under the hood anyway. > >> ,so I was hoping to better understand why the spec requires the behaviour it does (or whether I?m just following it incorrectly!) > > I think you're following it correctly; it's just buggy. ;) > > -Boris From ian at hixie.ch Wed Sep 11 17:24:24 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 12 Sep 2013 00:24:24 +0000 (UTC) Subject: [whatwg] img loading events - can load & error fire for the same image? In-Reply-To: <CAJ5xic9oYSJZEYQ49qiPTEkAibxJmKF76PK++CZQqjQh2krrjg@mail.gmail.com> References: <CAJ5xic_1LJES_oEk5HZ3hQgDJd5dVqs_mxFk3xT9c1XO-ijE_Q@mail.gmail.com> <alpine.DEB.2.00.1307121911080.15729@ps20323.dreamhostps.com> <CAJ5xic9oYSJZEYQ49qiPTEkAibxJmKF76PK++CZQqjQh2krrjg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309112252030.12199@ps20323.dreamhostps.com> On Mon, 22 Jul 2013, Jake Archibald wrote: > > Take http://jsbin.com/ifihex/1/edit - the image on this page receives a > valid & full HTTP request, but the received data isn't valid image data > (it's html). > > Starting from > http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#update-the-image-data, > here's how I see the image loading according to the spec > > (everything seems fine until step 14) > [...] > * this is the point where I start to get lost, I'm not sure which > else-like statements (as in "On the other hand" and "Otherwise") are > linked to which if-like statements Oh, yeah, this is very confusing. My bad. I've tried to fix it. Let me know how it is now. > >> "load" is fired once the width & height can be determined, which > >> suggests that an un-decodable image, but with intact headers (which > >> give the width & height) will fire "load" but not "error". I agree > >> with this, as it means the browser can defer decoding to render time, > >> but do we need a way in JS to confirm an image is decodable? > > > > What's the use case? (Surely the server should check this on the > > server.) > > The use-case would be image loading that happened without a server. Eg, > an in-browser Photoshop that operated without user interaction. User > selects file on their machine, it has correct headers so fires a load > event, but cannot be painted onto the canvas (or paints incorrectly) due > to corrupt data. The in-browser app is unable to detect the image is > corrupt without building a decoder/validator in JS. Well... there is one way to tell right now. You can try to draw it to a <canvas> and see if anything got drawn by examining all the pixels; if no pixels got drown, then it has some data integrity issues. But really if you're implementing a Photoshop equivalent, you really _should_ implement your own decoder, so you can do things like EXIF manipulation, handle other image formats, do "pngcrush"-like work, etc. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Sep 11 17:54:10 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 12 Sep 2013 00:54:10 +0000 (UTC) Subject: [whatwg] Outline style to use for drawSystemFocusRing In-Reply-To: <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> References: <CAFz-FYxS-sLLOMA2=5bj-aJ1bmsBq8w_4Rminw_JLCMnYaMfPw@mail.gmail.com> <alpine.DEB.2.00.1307242308540.27623@ps20323.dreamhostps.com> <CAGN7qDCdCR1F-D9PtEKUcHkh5KdwKhum4vEAyUQ0VkLeeC+PCA@mail.gmail.com> <alpine.DEB.2.00.1307292147040.27623@ps20323.dreamhostps.com> <CAGN7qDAaq8XnX1z_BbpLVhgE5m4j--b720ZuHSEzq_iN1es0=Q@mail.gmail.com> <alpine.DEB.2.00.1307300020510.27623@ps20323.dreamhostps.com> <CAGN7qDAjRPOQ25gQT+BY+sp8Y503_9KxTa1j2aZSGYU-9BmBVA@mail.gmail.com> <CAFz-FYzzPFU3g+fM+QGbEDAJ-3DSU2qGHY9R+heZRbAWVAN2rw@mail.gmail.com> <CAGN7qDDu3PNxK9PTVr09sqUc0FrOnXgRaQDwLXQ13BhH_=85Bw@mail.gmail.com> <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309120051240.12199@ps20323.dreamhostps.com> On Tue, 10 Sep 2013, Dominic Mazzoni wrote: > > We've finished implementing drawSystemFocusRing and drawCustomFocusRing > in Chrome. Try it in Chrome 31 or higher (either canary or dev channel > should work today). You'll need to go to chrome://flags and enable > *experimental canvas features*, then restart the browser. > > Here's a demo I built that uses drawSystemFocusRing: > http://dmazzoni-google.github.io/canvas-focus-ring-demo/ Looks good. Was your conclusion that the spec was ok as is, or did you deviate from the spec in some way that needs a spec change? (Apologies if you've already reported some feedback that I've lost track of; I didn't see any when I looked just now.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From bzbarsky at MIT.EDU Wed Sep 11 18:07:54 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Wed, 11 Sep 2013 21:07:54 -0400 Subject: [whatwg] [[GetOwnProperty]] for named properties of the Window object In-Reply-To: <C9BAE4B7-C54B-451A-872D-40D6CEAED23C@apple.com> References: <52600B08-E2BB-4AA3-877E-797E1CF687BC@apple.com> <52293AC6.5020108@mit.edu> <C9BAE4B7-C54B-451A-872D-40D6CEAED23C@apple.com> Message-ID: <523113EA.4030908@mit.edu> On 9/11/13 6:05 PM, Gavin Barraclough wrote: > Interesting, I had just assumed this was okay ? is it not spec-compliant for Window.prototype to be a named properties object? No, it's not. The spec defines exactly what the prototype chain looks like here. See the definitions of [[Prototype]] at http://dev.w3.org/2006/webapi/WebIDL/#named-properties-object and http://dev.w3.org/2006/webapi/WebIDL/#interface-prototype-object (item 1 at the latter). So the chain by default is window -> Window.prototype -> named properties object -> EventTarget.prototype -> Object.prototype. This allows specification of the named properties object without having to worry about weird interactions with name collisions on Window.prototype, whether with properties it has by default or properties someone wants to add to it. Note that the named properties object does not allow [[DefineOwnProperty]], so if it were Window.prototype then you wouldn't be able to add any properties to Window.prototype! > I believe these properties are implemented as shadowable in the same way as [Replaceable] properties [Replaceable] properties need the magic they have because they're accessor properties, which normally can't be shadowed via assignment. But named properties on the named properties object are value properties, so simply making them writable allows them to be shadowed. In fact, that's the only way to make them shadowable. > (and then assume a modified behaviour of ES [Put] for properties with this attribute, to permit overwrite even if readonly). I don't think a special [Put] is needed if the properties aren't readonly. -Boris From ian at hixie.ch Wed Sep 11 18:08:10 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 12 Sep 2013 01:08:10 +0000 (UTC) Subject: [whatwg] remove resetClip from the Canvas 2D spec In-Reply-To: <CAA5isUZ4pX3gzMvDfHXVqyOJvHVWdcyGzEBYURxNdgFrAHYgUQ@mail.gmail.com> References: <CAGN7qDC_ox_31kaFzutQn__sRdGe2kmCBQJkDQtKB9NRi+8ztQ@mail.gmail.com> <alpine.DEB.2.00.1307181720430.9685@ps20323.dreamhostps.com> <CAPeKFTjBh08ihwtwKPo54LTr14JbbiwYequMsPZD-Oq2EGk8QA@mail.gmail.com> <alpine.DEB.2.00.1308092019440.27623@ps20323.dreamhostps.com> <CABpaAqThhmOZEGDJ4P2A21xwszF=R+X9H5Ah3ZNjC+htmQpGkw@mail.gmail.com> <CAGN7qDBiQOdTSYfj7T0ek--UW+aQU1q=fV=imQZv_E2s1Nc38w@mail.gmail.com> <CABpaAqQYM4-pCfyB-Sap4yC2Uera_Us+viPKF8Q0BYgLdZ47xg@mail.gmail.com> <CAGN7qDDqVb7OQxH-R+pyQL0ZrnPKxzpVTT-oDzgT+JyuY7MMPg@mail.gmail.com> <CABpaAqSDq_wDL7J5gTJGuUrUApYdm5rbWu8QcNg6ozA0ASwF4w@mail.gmail.com> <CAA5isUaqWcDhRLj3MVa1Jef_LCgpkohLZo-QHibAK3Cd3d_Pcw@mail.gmail.com> <CABpaAqRX6mc5zvATrE31q+F7z6Pm-wNy2MEE4749SLW0k5_3VA@mail.gmail.com> <CAGN7qDCF7YjtbXNv=VkxAx1hhEaLSCCTZEk2SJXMzCbcOiFhuA@mail.gmail.com> <CAPeKFTi+WfPqK1E8SfxrW3+qwBHDeYkZk2JbWtDFB3mSAs98=g@mail.gmail.com> <CAA5isUZ4pX3gzMvDfHXVqyOJvHVWdcyGzEBYURxNdgFrAHYgUQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309120056550.12199@ps20323.dreamhostps.com> On Fri, 9 Aug 2013, Simon Sarris wrote: > > As an alternative [to resetClip()] I would propose something like > setClip() or setClip(path) (with the former working on the current path, > just like clip()/fill()/stroke() does). Seems like this would have the same problems as resetClip(), since it's essentially the same as a call to resetClip() followed by a call to clip(). On Fri, 9 Aug 2013, Justin Novosad wrote: > > What if resetClip restored the clip to what it was at the save call that > created the current state stack level? In other words, restore the clip, > but without popping it off the save/restore stack. > > Also, resetMatrix could be defined to do the same. Wouldn't that be the same as just save()/clip()/restore() ? On Mon, 12 Aug 2013, Rik Cabanier wrote: > > It would be good to hear specific use cases for 'resetClip' so we can make > that call. The main use case would be something like: c.save(); c.resetTransform(); c.resetClip(); // draw something at the top right... c.restore(); ...deep inside some draw code. > > Also, resetMatrix could be defined to do the same. > > Is that API defined somewhere? I think Justin meant resetTransform(). On Mon, 12 Aug 2013, Simon Sarris wrote: > > I think most performance-minded use cases will be fine with junov's idea > since they will not want to touch the stack in the first place. > > Here's a simple use case: Suppose there are nested objects to be drawn, > Panels, TextBlocks, and other visual elements. Panels are containers that > draw a background and all of their children - and they contain any number > of Panels or TextBlocks or other elements, and TextBlocks set the context > font (to their font) and draw some text. > > The drawing structure is hierarchical, and drawn elements may be offset > from their immediate parent. So a drawing hierarchy might look like this: > > Panel(A) > Panel(B) > TextBlock > TextBlock > > That is, Panel(A) contains Panel(B) and a TextBlock. And Panel(B) contains > another TextBlock. In practice, nesting could be much deeper and more > complicated. > > Now suppose also that Panels have some settings, such as a maximum width, > that might cause their visual elements to be clipped. So a panel might need > to save(), clip(), draw all of its children, and then restore(). Nesting > means multiple levels of clipping, for instance with the above hierarchy it > might look like: > > Panel(A) > clip (save) > drawChildren: > Panel(B) > clip (save) > drawChildren: > TextBlock > sets font X > fillText > restore > TextBlock > sets font X > fillText > restore > > This is problematic, because it means: > > 1. I must use save() and restore(), which are slow in their own right I'm pretty sure save() and restore() are the right solution here. If those don't work, we should fix those, not add more features that might have their own issues. > 2. The usage of save() and restore() means that, even if all (or most) of > my fonts are set to the same value, I have to keep setting them over and > over. Setting the font is slow in practice, even if it is set to the same > value as before, and so it should be cached if at all possible. Again, if settings fonts is slow, that should be fixed independently of resetClip(). On Mon, 12 Aug 2013, Justin Novosad wrote: > > Good point, I think part of the problem has to do with the fact that save > is non-selective (saves all of the state). > Might be worthwhile to have a selective save that pushes only a > user-specified subset of the current state onto the stack. There's no reason save() and restore() need be slow just because they save a lot. It's relatively easy to have a stack that only saves the things that have changed (e.g. by setting a bit when you change things, so you know what has changed, and then only pushing onto the stack the instructions to change the stuff that has changed). On Mon, 12 Aug 2013, Simon Sarris wrote: > > Yes, since save() and restore() save and restore everything, it creates > the side effect of needing to set ctx.font/fillStyle/strokeStyle more > often than otherwise, which are slow to set, probably because of some > CSS parser activity, but I'm not wise enough to know. save() and restore() should have no reason to go through the CSS parser. On Mon, 12 Aug 2013, Justin Novosad wrote: > > Ok, so here is a simple proposal: > > IDL: > enum CanvasSaveMode { "all", "transform", "clip", "transform-and-clip" }; > save(optional CanvasSaveMode mode); > > Modes: > all: save the entire rendering context state > transform: save only the current transform > clip: save only the current clip > > if mode is not specified, the entire context state is saved (for backward > compatibility) > > The restore method's interface does not change. It restores whatever state > was saved by the matching save call. I don't understand what problem this is solving. On Tue, 13 Aug 2013, Simon Sarris wrote: > > I'd argue its not strictly a performance issue. More generally its > awkward that you can reset any piece of the canvas context state except > the clipping region. The clipping region alone requires you to clobber > all state in order to reset it. > > You can set the fillStyle back to black, you can set the transformation > matrix back to identity, etc. But you can't set the clipping region back > to the entire canvas area without save()/restore() or > can.width=can.width. It's the only thing like that. > > That ought to be considered bad on principle I think. It makes clipping > a really odd operation compared to anything else, and at the least it > makes the one part of the API unintuitive. This is the argument for resetClip(), though the only use case seems to be the one I mentioned (drawing something at the top right, or whatever, deep inside some code that has clipped and transformed). I've marked the resetClip() feature in the spec as being considered form removal. If no browser implement it in due course, I'll remove it. Despite being relatively commonly requested, it must be admitted that the use cases for this feature aren't that compelling. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From robert at ocallahan.org Thu Sep 12 00:17:31 2013 From: robert at ocallahan.org (Robert O'Callahan) Date: Thu, 12 Sep 2013 00:17:31 -0700 Subject: [whatwg] High-density canvases In-Reply-To: <alpine.DEB.2.00.1309111823370.12210@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> <CAGN7qDCC=8EZUpEmN=10tcWGU=8TPQ7rej+sOGhbPaWqqAjWRA@mail.gmail.com> <CAOp6jLZFD_HVKgEfEUB0myCdvz60i_=1NASVQ-YKyzcHxkDxVw@mail.gmail.com> <alpine.DEB.2.00.1309111823370.12210@ps20323.dreamhostps.com> Message-ID: <CAOp6jLaxkdDE5qKaZmUxHs5Jic8h3yCnE+j7dCUgAHQWLQBiEg@mail.gmail.com> On Wed, Sep 11, 2013 at 11:24 AM, Ian Hickson <ian at hixie.ch> wrote: > On Wed, 11 Sep 2013, Robert O'Callahan wrote: > > Pinch-zoom is hard because we don't want to trigger reflows or other > > expensive behavior on pinch-zoom. I'd leave pinch-zoom out of it for > > now. > > Unless I'm missing something fundamental, changing the pixel density > doesn't cause a layout, it's changing the width that causes a layout. > Changing pixel density does cause a layout in Gecko. For example we round CSS border widths to a whole number of device pixels. (This ensures that when page zoom is applied, all borders with the same specified width are rendered with the same visual width.) On some platforms (Windows), changing pixel density affects text hinting which affects text layout. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * From annevk at annevk.nl Thu Sep 12 02:24:32 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Thu, 12 Sep 2013 10:24:32 +0100 Subject: [whatwg] URL resolution of fragment urls in html5 webapps In-Reply-To: <alpine.DEB.2.00.1309111821360.12210@ps20323.dreamhostps.com> References: <CAO9zZYMo79Dqn-EK8S0j-M9sNJeFEGQg_XgP6+fsszDmq5oDMQ@mail.gmail.com> <CANr5HFXkxQuiy+n1jDkd=jP92Wz=E0_BrGbo40A0xxjpbAw2dQ@mail.gmail.com> <CAO9zZYOuSfkkGbqFWeeJ-gu1k0mZLFfnjrgkiweL+EN9aGGoiw@mail.gmail.com> <alpine.DEB.2.00.1309100013320.12199@ps20323.dreamhostps.com> <CADnb78iS2LsMporp8qKxFmmBy-rHH7q++_-osP94oaWAtjzdcw@mail.gmail.com> <alpine.DEB.2.00.1309111821360.12210@ps20323.dreamhostps.com> Message-ID: <CADnb78iHZEKdX8F_76vezghkXNiXcq64Edmr2-ofHKhZ17hJcQ@mail.gmail.com> On Wed, Sep 11, 2013 at 7:22 PM, Ian Hickson <ian at hixie.ch> wrote: > Well presumably we wouldn't want to only do it for <a>, since then links > would work but SVG wouldn't (the exact opposite of the situation in Chrome > now, for what it's worth). Yeah, we should have to do it for everything we classify as "hyperlink". <a>, <svg:a>, <area>, and <link> I suppose. I'm not sure what in MathML would need covering. -- http://annevankesteren.nl/ From annevk at annevk.nl Thu Sep 12 02:56:32 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Thu, 12 Sep 2013 10:56:32 +0100 Subject: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use In-Reply-To: <alpine.DEB.2.00.1309111819130.12210@ps20323.dreamhostps.com> References: <514A7477.6040905@mit.edu> <alpine.DEB.2.00.1307121809430.15729@ps20323.dreamhostps.com> <51E04C76.30200@mit.edu> <CAJE5ia_WTqejajPZVxf=cxTipvPyE=g0FWQfj-kJaj1tK583kw@mail.gmail.com> <51E04FDD.2080702@mit.edu> <CADnb78iniuYkyc4cH+RECg1p=ANVQPMz_sod9_Q11C=YDN=ZXg@mail.gmail.com> <alpine.DEB.2.00.1309101934520.12199@ps20323.dreamhostps.com> <CADnb78j7UJe1rbCTuuvpXJhfHKkcib2Mqnc=iUoYS+Yh+p8itA@mail.gmail.com> <alpine.DEB.2.00.1309111819130.12210@ps20323.dreamhostps.com> Message-ID: <CADnb78iQ6TnDD+p=WPs8=xFDKYG=QiiBSaxOVj9gqrWYAxzbAA@mail.gmail.com> On Wed, Sep 11, 2013 at 7:21 PM, Ian Hickson <ian at hixie.ch> wrote: > Surely the consistency of the API matching the input is more important > than the consistency of the API _not_ matching the input... The input will be mangled anyway. E.g. domain label separators are normalized to ".". And all kinds of other parts of the URL undergo normalization. >> It means the entire URL is effectively a byte sequence. > > I don't know what you mean here. No code point is higher than 7F. And given the way HTTP operates on URLs, and we extract data from data URLs, making it a byte sequence might not be a such a bad idea... >> And it's very clear what the DNS lookup will be. > > Why do you think people care more about that than about the URL matching > what they wrote in the markup? It won't match that anyway. >> And given that they keep insisting on changing what certain code points >> map to over in IETF-land (with limited support from browser vendors :/), >> it seems safer too. > > I don't understand what is safer. Surely if the punycoding step keeps > changing, it's less safe, since it'll mean that the results will change > without the author expecting it. If we don't punycode in the API, then the > result will be the same regardless of the punycode step. It depends on what you do with the result I suppose. https://groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/blink-dev/fBsVRcEOTWM seems relevant. http://url.spec.whatwg.org/ defines ASCII at the moment. The other reason that is I just remembered is because ToASCII can fail and at that point we want to return failure for the URL. I suppose we could run ToASCII and then ToUnicode... -- http://annevankesteren.nl/ From rashmi.shyam at gmail.com Thu Sep 12 03:48:54 2013 From: rashmi.shyam at gmail.com (Rashmi Shyamasundar) Date: Thu, 12 Sep 2013 16:18:54 +0530 Subject: [whatwg] whatwg Digest, Vol 114, Issue 19 In-Reply-To: <mailman.23942.1378977874.52932.whatwg-whatwg.org@lists.whatwg.org> References: <mailman.23942.1378977874.52932.whatwg-whatwg.org@lists.whatwg.org> Message-ID: <CAEiriRZCPSb_F55Heh-KyNAVj5LjhOpZ-_oxXGOr9KRV8bYKZg@mail.gmail.com> Hi All, This is regarding the resetClip() API for canvas. Please take a look at my patches to the bug https://bugs.webkit.org/show_bug.cgi?id=82801. resetClip() can be implemented in Cairo, without any overhead, since Cairo supports resetClip. I tried to implement the API in CG, using the below approach :- (Please check https://bugs.webkit.org/show_bug.cgi?id=82801#c9 ) Steps :- When resetClip() is called, 1. Save the imageData from canvas imageBuffer 2. Save the GraphicsContextState 3. Clear the canvas buffer. This will delete the buffer and GraphicsContextStateSaver. 4. Copy the saved imageData to a new imageBuffer 5. Set the graphicsContextState to the saved state. GraphicsContextState does not have information about any clip. The drawback with the above approach is that clipping-region cannot be restored since it is not part of the GraphicsContextState or CanvasRenderingContext2D::State. Currently clipping-region is not saved in GraphicsContextState or CanvasRenderingContext2D::State. If clipping-region is somehow saved in GraphicsContextState and CanvasRenderingContext2D::State then, through step#5, clipping region can also be restored. Below is an example which will not work in CG (But, Works perfectly in Cairo), if clipping-region is not saved in GraphicsContextState and CanvasRenderingContext2D::State :- ctx.clip(); ctx.save(); ctx.resetClip(); ...; // draw with no clip ctx.restore(); ...; // draw with a clip (This draw does not contain any clip) Thanks, Rashmi > > Message: 7 > Date: Thu, 12 Sep 2013 01:08:10 +0000 (UTC) > From: Ian Hickson <ian at hixie.ch> > To: WHATWG List <whatwg at whatwg.org> > Subject: Re: [whatwg] remove resetClip from the Canvas 2D spec > Message-ID: > <alpine.DEB.2.00.1309120056550.12199 at ps20323.dreamhostps.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Fri, 9 Aug 2013, Simon Sarris wrote: > > > > As an alternative [to resetClip()] I would propose something like > > setClip() or setClip(path) (with the former working on the current path, > > just like clip()/fill()/stroke() does). > > Seems like this would have the same problems as resetClip(), since it's > essentially the same as a call to resetClip() followed by a call to clip(). > > > On Fri, 9 Aug 2013, Justin Novosad wrote: > > > > What if resetClip restored the clip to what it was at the save call that > > created the current state stack level? In other words, restore the clip, > > but without popping it off the save/restore stack. > > > > Also, resetMatrix could be defined to do the same. > > Wouldn't that be the same as just save()/clip()/restore() ? > > > On Mon, 12 Aug 2013, Rik Cabanier wrote: > > > > It would be good to hear specific use cases for 'resetClip' so we can > make > > that call. > > The main use case would be something like: > > c.save(); > c.resetTransform(); > c.resetClip(); > // draw something at the top right... > c.restore(); > > ...deep inside some draw code. > > > > > Also, resetMatrix could be defined to do the same. > > > > Is that API defined somewhere? > > I think Justin meant resetTransform(). > > > On Mon, 12 Aug 2013, Simon Sarris wrote: > > > > I think most performance-minded use cases will be fine with junov's idea > > since they will not want to touch the stack in the first place. > > > > Here's a simple use case: Suppose there are nested objects to be drawn, > > Panels, TextBlocks, and other visual elements. Panels are containers that > > draw a background and all of their children - and they contain any number > > of Panels or TextBlocks or other elements, and TextBlocks set the context > > font (to their font) and draw some text. > > > > The drawing structure is hierarchical, and drawn elements may be offset > > from their immediate parent. So a drawing hierarchy might look like this: > > > > Panel(A) > > Panel(B) > > TextBlock > > TextBlock > > > > That is, Panel(A) contains Panel(B) and a TextBlock. And Panel(B) > contains > > another TextBlock. In practice, nesting could be much deeper and more > > complicated. > > > > Now suppose also that Panels have some settings, such as a maximum width, > > that might cause their visual elements to be clipped. So a panel might > need > > to save(), clip(), draw all of its children, and then restore(). Nesting > > means multiple levels of clipping, for instance with the above hierarchy > it > > might look like: > > > > Panel(A) > > clip (save) > > drawChildren: > > Panel(B) > > clip (save) > > drawChildren: > > TextBlock > > sets font X > > fillText > > restore > > TextBlock > > sets font X > > fillText > > restore > > > > This is problematic, because it means: > > > > 1. I must use save() and restore(), which are slow in their own right > > I'm pretty sure save() and restore() are the right solution here. If those > don't work, we should fix those, not add more features that might have > their own issues. > > > > 2. The usage of save() and restore() means that, even if all (or most) of > > my fonts are set to the same value, I have to keep setting them over and > > over. Setting the font is slow in practice, even if it is set to the same > > value as before, and so it should be cached if at all possible. > > Again, if settings fonts is slow, that should be fixed independently of > resetClip(). > > > On Mon, 12 Aug 2013, Justin Novosad wrote: > > > > Good point, I think part of the problem has to do with the fact that save > > is non-selective (saves all of the state). > > Might be worthwhile to have a selective save that pushes only a > > user-specified subset of the current state onto the stack. > > There's no reason save() and restore() need be slow just because they save > a lot. It's relatively easy to have a stack that only saves the things > that have changed (e.g. by setting a bit when you change things, so you > know what has changed, and then only pushing onto the stack the > instructions to change the stuff that has changed). > > > On Mon, 12 Aug 2013, Simon Sarris wrote: > > > > Yes, since save() and restore() save and restore everything, it creates > > the side effect of needing to set ctx.font/fillStyle/strokeStyle more > > often than otherwise, which are slow to set, probably because of some > > CSS parser activity, but I'm not wise enough to know. > > save() and restore() should have no reason to go through the CSS parser. > > > On Mon, 12 Aug 2013, Justin Novosad wrote: > > > > Ok, so here is a simple proposal: > > > > IDL: > > enum CanvasSaveMode { "all", "transform", "clip", "transform-and-clip" }; > > save(optional CanvasSaveMode mode); > > > > Modes: > > all: save the entire rendering context state > > transform: save only the current transform > > clip: save only the current clip > > > > if mode is not specified, the entire context state is saved (for backward > > compatibility) > > > > The restore method's interface does not change. It restores whatever > state > > was saved by the matching save call. > > I don't understand what problem this is solving. > > > On Tue, 13 Aug 2013, Simon Sarris wrote: > > > > I'd argue its not strictly a performance issue. More generally its > > awkward that you can reset any piece of the canvas context state except > > the clipping region. The clipping region alone requires you to clobber > > all state in order to reset it. > > > > You can set the fillStyle back to black, you can set the transformation > > matrix back to identity, etc. But you can't set the clipping region back > > to the entire canvas area without save()/restore() or > > can.width=can.width. It's the only thing like that. > > > > That ought to be considered bad on principle I think. It makes clipping > > a really odd operation compared to anything else, and at the least it > > makes the one part of the API unintuitive. > > This is the argument for resetClip(), though the only use case seems to be > the one I mentioned (drawing something at the top right, or whatever, deep > inside some code that has clipped and transformed). > > I've marked the resetClip() feature in the spec as being considered form > removal. If no browser implement it in due course, I'll remove it. Despite > being relatively commonly requested, it must be admitted that the use > cases for this feature aren't that compelling. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > > > ------------------------------ > > From dino at apple.com Thu Sep 12 07:11:56 2013 From: dino at apple.com (Dean Jackson) Date: Thu, 12 Sep 2013 09:11:56 -0500 Subject: [whatwg] High-density canvases In-Reply-To: <CAOp6jLZFD_HVKgEfEUB0myCdvz60i_=1NASVQ-YKyzcHxkDxVw@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> <CAGN7qDCC=8EZUpEmN=10tcWGU=8TPQ7rej+sOGhbPaWqqAjWRA@mail.gmail.com> <CAOp6jLZFD_HVKgEfEUB0myCdvz60i_=1NASVQ-YKyzcHxkDxVw@mail.gmail.com> Message-ID: <BCF6563F-D903-409E-9DE4-BCC76ADF3111@apple.com> On 11 Sep 2013, at 3:20 am, Robert O'Callahan <robert at ocallahan.org> wrote: > On Tue, Sep 10, 2013 at 1:26 PM, Rik Cabanier <cabanier at gmail.com> wrote: > There's a thread on www-style: > http://lists.w3.org/Archives/Public/www-style/2012Nov/0144.html > It's been in firefox for a while and blink is going to ship it soon: > https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/RyUSi3zdumQ > > devicePixelRatio has reflected page zoom in Firefox ever since we first exposed it (because the thing it maps to internally has always been affected by page zoom). OK. I can accept that it makes sense for page zoom (I was only thinking about pinch zoom... which is a bad name). Still, we've (Apple) been telling developers for a long time that devicePixelRatio is (basically) constant. I guess we'll have to either change or be non-conformant. > > > > Actually what I really think we should do is also change the > > > window.devicePixelRatio for pinch zoom. Combined with the suggestions for > > > canvas, that would allow (as Rik pointed out on IRC) for high-quality > > > canvas all the way zoomed in, and for cheap canvases when zoomed out > > I believe pinch zoom should not change devicePixelRatio. It would be nice > if there was a standard way to determine pinch zoom though and if the > canvas could automatically resize. > > Pinch-zoom is hard because we don't want to trigger reflows or other expensive behavior on pinch-zoom. I'd leave pinch-zoom out of it for now. Agreed. Dean From bzbarsky at MIT.EDU Thu Sep 12 08:51:56 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Thu, 12 Sep 2013 11:51:56 -0400 Subject: [whatwg] URL resolution of fragment urls in html5 webapps In-Reply-To: <CADnb78iHZEKdX8F_76vezghkXNiXcq64Edmr2-ofHKhZ17hJcQ@mail.gmail.com> References: <CAO9zZYMo79Dqn-EK8S0j-M9sNJeFEGQg_XgP6+fsszDmq5oDMQ@mail.gmail.com> <CANr5HFXkxQuiy+n1jDkd=jP92Wz=E0_BrGbo40A0xxjpbAw2dQ@mail.gmail.com> <CAO9zZYOuSfkkGbqFWeeJ-gu1k0mZLFfnjrgkiweL+EN9aGGoiw@mail.gmail.com> <alpine.DEB.2.00.1309100013320.12199@ps20323.dreamhostps.com> <CADnb78iS2LsMporp8qKxFmmBy-rHH7q++_-osP94oaWAtjzdcw@mail.gmail.com> <alpine.DEB.2.00.1309111821360.12210@ps20323.dreamhostps.com> <CADnb78iHZEKdX8F_76vezghkXNiXcq64Edmr2-ofHKhZ17hJcQ@mail.gmail.com> Message-ID: <5231E31C.5090309@mit.edu> On 9/12/13 5:24 AM, Anne van Kesteren wrote: > On Wed, Sep 11, 2013 at 7:22 PM, Ian Hickson <ian at hixie.ch> wrote: >> Well presumably we wouldn't want to only do it for <a>, since then links >> would work but SVG wouldn't (the exact opposite of the situation in Chrome >> now, for what it's worth). > > Yeah, we should have to do it for everything we classify as > "hyperlink". <a>, <svg:a>, <area>, and <link> I suppose. Why only "hyperlinks", if you're doing this? Last I checked, WebKit doesn't do it for hyperlinks, but does do it ad-hoc for CSS url() stuff and a few other things, depending on how it's used. -Boris From annevk at annevk.nl Thu Sep 12 08:55:04 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Thu, 12 Sep 2013 16:55:04 +0100 Subject: [whatwg] URL resolution of fragment urls in html5 webapps In-Reply-To: <5231E31C.5090309@mit.edu> References: <CAO9zZYMo79Dqn-EK8S0j-M9sNJeFEGQg_XgP6+fsszDmq5oDMQ@mail.gmail.com> <CANr5HFXkxQuiy+n1jDkd=jP92Wz=E0_BrGbo40A0xxjpbAw2dQ@mail.gmail.com> <CAO9zZYOuSfkkGbqFWeeJ-gu1k0mZLFfnjrgkiweL+EN9aGGoiw@mail.gmail.com> <alpine.DEB.2.00.1309100013320.12199@ps20323.dreamhostps.com> <CADnb78iS2LsMporp8qKxFmmBy-rHH7q++_-osP94oaWAtjzdcw@mail.gmail.com> <alpine.DEB.2.00.1309111821360.12210@ps20323.dreamhostps.com> <CADnb78iHZEKdX8F_76vezghkXNiXcq64Edmr2-ofHKhZ17hJcQ@mail.gmail.com> <5231E31C.5090309@mit.edu> Message-ID: <CADnb78jN9qbEdTgch_XgVjSGQ-FLFsmVVbvgFe8p27+NbU-5eQ@mail.gmail.com> On Thu, Sep 12, 2013 at 4:51 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote: > On 9/12/13 5:24 AM, Anne van Kesteren wrote: >> On Wed, Sep 11, 2013 at 7:22 PM, Ian Hickson <ian at hixie.ch> wrote: >>> Well presumably we wouldn't want to only do it for <a>, since then links >>> would work but SVG wouldn't (the exact opposite of the situation in >>> Chrome now, for what it's worth). >> >> Yeah, we should have to do it for everything we classify as >> "hyperlink". <a>, <svg:a>, <area>, and <link> I suppose. > > Why only "hyperlinks", if you're doing this? I thought it would be incompatible to do it for <form> and maybe <iframe> and others. > Last I checked, WebKit doesn't do it for hyperlinks, but does do it ad-hoc > for CSS url() stuff and a few other things, depending on how it's used. Is this for SVG thingies referenced from CSS? -- http://annevankesteren.nl/ From bzbarsky at MIT.EDU Thu Sep 12 09:28:08 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Thu, 12 Sep 2013 12:28:08 -0400 Subject: [whatwg] URL resolution of fragment urls in html5 webapps In-Reply-To: <CADnb78jN9qbEdTgch_XgVjSGQ-FLFsmVVbvgFe8p27+NbU-5eQ@mail.gmail.com> References: <CAO9zZYMo79Dqn-EK8S0j-M9sNJeFEGQg_XgP6+fsszDmq5oDMQ@mail.gmail.com> <CANr5HFXkxQuiy+n1jDkd=jP92Wz=E0_BrGbo40A0xxjpbAw2dQ@mail.gmail.com> <CAO9zZYOuSfkkGbqFWeeJ-gu1k0mZLFfnjrgkiweL+EN9aGGoiw@mail.gmail.com> <alpine.DEB.2.00.1309100013320.12199@ps20323.dreamhostps.com> <CADnb78iS2LsMporp8qKxFmmBy-rHH7q++_-osP94oaWAtjzdcw@mail.gmail.com> <alpine.DEB.2.00.1309111821360.12210@ps20323.dreamhostps.com> <CADnb78iHZEKdX8F_76vezghkXNiXcq64Edmr2-ofHKhZ17hJcQ@mail.gmail.com> <5231E31C.5090309@mit.edu> <CADnb78jN9qbEdTgch_XgVjSGQ-FLFsmVVbvgFe8p27+NbU-5eQ@mail.gmail.com> Message-ID: <5231EB98.9010803@mit.edu> On 9/12/13 11:55 AM, Anne van Kesteren wrote: >> Last I checked, WebKit doesn't do it for hyperlinks, but does do it ad-hoc >> for CSS url() stuff and a few other things, depending on how it's used. > > Is this for SVG thingies referenced from CSS? Or from SVG presentation attributes. Fill, filters, masks, etc, etc, etc. But again, it's not clear that anything needs to be done here. If something _does_ need to be done, then it needs to be done at a low level (e.g. url() needs to store the original string, not just the resolved url as it does now per CSS specs). -Boris From dmazzoni at google.com Thu Sep 12 09:32:00 2013 From: dmazzoni at google.com (Dominic Mazzoni) Date: Thu, 12 Sep 2013 09:32:00 -0700 Subject: [whatwg] Outline style to use for drawSystemFocusRing In-Reply-To: <alpine.DEB.2.00.1309120051240.12199@ps20323.dreamhostps.com> References: <CAFz-FYxS-sLLOMA2=5bj-aJ1bmsBq8w_4Rminw_JLCMnYaMfPw@mail.gmail.com> <alpine.DEB.2.00.1307242308540.27623@ps20323.dreamhostps.com> <CAGN7qDCdCR1F-D9PtEKUcHkh5KdwKhum4vEAyUQ0VkLeeC+PCA@mail.gmail.com> <alpine.DEB.2.00.1307292147040.27623@ps20323.dreamhostps.com> <CAGN7qDAaq8XnX1z_BbpLVhgE5m4j--b720ZuHSEzq_iN1es0=Q@mail.gmail.com> <alpine.DEB.2.00.1307300020510.27623@ps20323.dreamhostps.com> <CAGN7qDAjRPOQ25gQT+BY+sp8Y503_9KxTa1j2aZSGYU-9BmBVA@mail.gmail.com> <CAFz-FYzzPFU3g+fM+QGbEDAJ-3DSU2qGHY9R+heZRbAWVAN2rw@mail.gmail.com> <CAGN7qDDu3PNxK9PTVr09sqUc0FrOnXgRaQDwLXQ13BhH_=85Bw@mail.gmail.com> <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> <alpine.DEB.2.00.1309120051240.12199@ps20323.dreamhostps.com> Message-ID: <CAFz-FYwi6tQ7WcODc3MBC=6pM_=G5ZONe=nVSHLs5EGTiUjE=w@mail.gmail.com> On Wed, Sep 11, 2013 at 5:54 PM, Ian Hickson <ian at hixie.ch> wrote: > On Tue, 10 Sep 2013, Dominic Mazzoni wrote: > > > > We've finished implementing drawSystemFocusRing and drawCustomFocusRing > > in Chrome. Try it in Chrome 31 or higher (either canary or dev channel > > should work today). You'll need to go to chrome://flags and enable > > *experimental canvas features*, then restart the browser. > > > > Here's a demo I built that uses drawSystemFocusRing: > > http://dmazzoni-google.github.io/canvas-focus-ring-demo/ > > Looks good. Was your conclusion that the spec was ok as is, or did you > deviate from the spec in some way that needs a spec change > I think drawSystemFocusRing is good to go. If you want, you can update the spec to reflect that an implementation is available (behind a flag). Only one minor issue for clarification: if the current path is a line or unclosed polygon, should it be closed (or otherwise outlined) when drawing the focus ring? Currently we're not doing so in Chrome, but it might help to clarify. For example, if the path is a line, what's drawn is just an additional stroke on that line, not a "ring". I'm not as sure about drawCustomFocusRing. The spec says "If the user has requested the use of particular focus rings", but I'm not aware of any platform API we could use to query that. To the best of my knowledge, assistive technology that draws its own focus rings, like ZoomText, normally draws an additional focus ring with extra padding, rather than replacing the system one. (Example: http://www.aisquared.com/zoomtext/tour/enhancements#focus_enhancements) So, I'm not sure how I'd implement that part of the spec. Chrome definitely has no plans to give users an additional preference for focus rings as a browser setting. So, what we implemented in Chrome for drawCustomFocusRing is basically just a function that notifies assistive technology of the bounding rect of the focused region within the canvas. It's still useful, but if that's all it does, then drawCustomFocusRing is a poor name. Perhaps it should be called something like notifyFocusLocation or something like that. - Dominic From annevk at annevk.nl Thu Sep 12 09:51:14 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Thu, 12 Sep 2013 17:51:14 +0100 Subject: [whatwg] URL resolution of fragment urls in html5 webapps In-Reply-To: <5231EB98.9010803@mit.edu> References: <CAO9zZYMo79Dqn-EK8S0j-M9sNJeFEGQg_XgP6+fsszDmq5oDMQ@mail.gmail.com> <CANr5HFXkxQuiy+n1jDkd=jP92Wz=E0_BrGbo40A0xxjpbAw2dQ@mail.gmail.com> <CAO9zZYOuSfkkGbqFWeeJ-gu1k0mZLFfnjrgkiweL+EN9aGGoiw@mail.gmail.com> <alpine.DEB.2.00.1309100013320.12199@ps20323.dreamhostps.com> <CADnb78iS2LsMporp8qKxFmmBy-rHH7q++_-osP94oaWAtjzdcw@mail.gmail.com> <alpine.DEB.2.00.1309111821360.12210@ps20323.dreamhostps.com> <CADnb78iHZEKdX8F_76vezghkXNiXcq64Edmr2-ofHKhZ17hJcQ@mail.gmail.com> <5231E31C.5090309@mit.edu> <CADnb78jN9qbEdTgch_XgVjSGQ-FLFsmVVbvgFe8p27+NbU-5eQ@mail.gmail.com> <5231EB98.9010803@mit.edu> Message-ID: <CADnb78i0VwYzN4YWPYVoMpXZgYgoiSfw0-dBGNGeBbNReZM5=Q@mail.gmail.com> On Thu, Sep 12, 2013 at 5:28 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote: > Or from SVG presentation attributes. Fill, filters, masks, etc, etc, etc. > > But again, it's not clear that anything needs to be done here. If something > _does_ need to be done, then it needs to be done at a low level (e.g. url() > needs to store the original string, not just the resolved url as it does now > per CSS specs). Currently parseURL(input, base) returns either URL or failure. We could make it return URL, URLFragment, or failure too... Anyway, yeah, things are possible, but it's unclear whether everyone is interested in moving all these pieces. -- http://annevankesteren.nl/ From ian at hixie.ch Thu Sep 12 10:42:50 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 12 Sep 2013 17:42:50 +0000 (UTC) Subject: [whatwg] High-density canvases In-Reply-To: <CAOp6jLaxkdDE5qKaZmUxHs5Jic8h3yCnE+j7dCUgAHQWLQBiEg@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> <CAGN7qDCC=8EZUpEmN=10tcWGU=8TPQ7rej+sOGhbPaWqqAjWRA@mail.gmail.com> <CAOp6jLZFD_HVKgEfEUB0myCdvz60i_=1NASVQ-YKyzcHxkDxVw@mail.gmail.com> <alpine.DEB.2.00.1309111823370.12210@ps20323.dreamhostps.com> <CAOp6jLaxkdDE5qKaZmUxHs5Jic8h3yCnE+j7dCUgAHQWLQBiEg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309121742300.12210@ps20323.dreamhostps.com> On Thu, 12 Sep 2013, Robert O'Callahan wrote: > On Wed, Sep 11, 2013 at 11:24 AM, Ian Hickson <ian at hixie.ch> wrote: > > On Wed, 11 Sep 2013, Robert O'Callahan wrote: > > > Pinch-zoom is hard because we don't want to trigger reflows or other > > > expensive behavior on pinch-zoom. I'd leave pinch-zoom out of it for > > > now. > > > > Unless I'm missing something fundamental, changing the pixel density > > doesn't cause a layout, it's changing the width that causes a layout. > > Changing pixel density does cause a layout in Gecko. For example we > round CSS border widths to a whole number of device pixels. (This > ensures that when page zoom is applied, all borders with the same > specified width are rendered with the same visual width.) On some > platforms (Windows), changing pixel density affects text hinting which > affects text layout. So how do you do pinch-zoom under the hood on mobile devices? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Thu Sep 12 11:30:23 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 12 Sep 2013 18:30:23 +0000 (UTC) Subject: [whatwg] web messaging - postMessage In-Reply-To: <CAKRyGxt=-yegxR2G05XyT-sYFdudGOYp0EKysD8cURgYXr5ZEw@mail.gmail.com> References: <CAKRyGxsef-O-dtx1FbK_AiqngHr4Ob5d7sezYyxmswsog3VxZA@mail.gmail.com> <CAKRyGxvogWmMXxmChcZJ9Hi57k6bG+SituDs7pNRfTzdLao3DQ@mail.gmail.com> <9768D477C67135458BF978A45BCF9B3853BB8A58@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> <CAKRyGxuhAXadQeNvZQRdriW-yKmXSHDykrAf_A2Xy0w2gJ6m-w@mail.gmail.com> <CABirCh-397NkFxc8vO-bjaETyz72W7oy7jC+q5BM2+_O86ef6w@mail.gmail.com> <CAKRyGxsJP0bohFJ2SWAWr+H3AWsGYmUOcRZsuN3_uOfVJ1Jmgg@mail.gmail.com> <CABirCh-Ar58nYA_KGWOGjiahj9cq1fjTsmnPwjSRnE9EaWWCiA@mail.gmail.com> <alpine.DEB.2.00.1308052102150.9685@ps20323.dreamhostps.com> <CAKRyGxt=-yegxR2G05XyT-sYFdudGOYp0EKysD8cURgYXr5ZEw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309121818310.12199@ps20323.dreamhostps.com> On Mon, 5 Aug 2013, Jack (Zhan, Hua Ping) wrote: > > The "origin" in this context means the msg destination. The term "origin" in Web standards means a security token, essentially: http://tools.ietf.org/html/rfc6454 In the case of window.postMessage(), there's two places that an origin is used. The first is in the method call: destinationWindow.postMessage(message, targetOrigin); Here, targetOrigin is the origin that the destinationWindow object's active Document is required to have for the message to be delivered. We have this feature so that if the target page gets navigated away unexpectedly, you don't end up sending secrets to evil pages. The second is in the received MessageEvent object: // window is the destinationWindow of the script above // but here we're on the receiving end window.onmessage = function (event) { // event.data is the message from the call above // event.origin is the origin of the Window that sent the message // event.source is the Window that sent the message } Note that event.origin is _not_ targetOrigin. > Think it over, it seems to be "polling", but in your design, seems there > is no polling. in fact, there is. In your design, the receiver has to > check "origin". It has to check that it is receiving messages from a trusted source, right. > This means the receivers have to check the destination of the message. No, they're checking the source of the message. > > If you need to communicate between two otherwise unrelated tabs, there > > are basically two solutions: a shared worker, or a broadcast > > mechanism. The latter isn't currently specced, but discussion on how > > to do it is here: > > > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=22628 > > > > You can also currently fake this using the 'onstorage' event. > > Yes. I know these two solutions since someone told me before. but shared > worker is much more complicated than needed, isn't it? broadcast will > lose privacy, won't it? How would broadcast lose privacy? > >> My better proposal ..... > > This is basically a broadcast mechanism, right. > Yes. you are right, but message dispatch is done by the user agent, only > the intended receiver will receive the msg, so no communication > information would be leaked. And when broadcast is really needed, just > use wildcard for destination. As far as I can tell, what you are describing is consistent with the proposal in the bug above. > > One things that would be useful in making progress on this would be > > more use cases, in particular use cases where it's important to be > > able to respond after a broadcast. > > > > There's basically only one use case in the bug above, namely informing > > other windows of a state change (e.g. user logged in). This can > > currently be done using "onstorage" and that could arguably in fact be > > a sufficient solution (since for a "change" notification, there's no > > need to respond, and it's typically stored state that has changed). > > You are thinking in such a way. I really do not understand. There's an infinite number of features we could add, but we could not implement them all -- there's limited resources to implement stuff, and the more we implement, the more buggy stuff is since the resources get spread thinner and thinner. We have therefore to prioritise and only implement the most important things. To determine if something is important, we look at how people want to use it, and what problems they are trying to solve (use cases). Currently for this feature we lack many use cases. > I think this interface is really nice. Compare the original design and > this design, it is easy to see the difference. > >>>o.contentWindow.postMessage('Hello world', 'http://b.example.org/'); > window.postMessage(msgdata, targetDomain optional,targetWindowIDs optional); > > window is the general js object. the destination can be specified by > domain and/or window/tab ID, both of them can be omitted which means a > broadcast. window IDs aren't a good thing to use for naming windows, since they are trivially spoofed. > the major difference is the "o.contentWindow", this is really weird. > Once you specify the target receiver, you do not have to care its > window handle. The user agent should take care of it. There's an important difference between the Window object of the target, and the origin of the Document currently loaded in the target. It's easy for an attacker to renavigate an iframe or window to their site, so it's important to say the origin of where you're sending the data, so that an evil site can't intercept it. > For security reason, the interface at the receiver side, will be bound > to a specific msg name "msgpost". This msg name is added by the user > agent. The msg name is some kind of identifying the msg channel, so the > receiver will have an idea where this message comes from. Of course, msg > source will also be available for the receiver to check. But as a > receiver, checking msg destination is not needed since this should be > done by the user agent. I don't understand how this improves security. What's the attack model you have in mind that this mitigates? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Thu Sep 12 11:34:39 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 12 Sep 2013 18:34:39 +0000 (UTC) Subject: [whatwg] Request for updating the srcset-specification? In-Reply-To: <436355E7-26B7-4315-8BA0-8248AE76D58E@anselm-hannemann.com> References: <DBFA329F-462B-46E3-9BF5-533A0835C88C@anselm-hannemann.com> <m24nati9ew.fsf@eoconnor.apple.com> <436355E7-26B7-4315-8BA0-8248AE76D58E@anselm-hannemann.com> Message-ID: <alpine.DEB.2.00.1309121833060.12199@ps20323.dreamhostps.com> On Tue, 13 Aug 2013, Anselm Hannemann wrote: > > what do you think of updating [srcset] regarding the implementation(s)? The spec generally speaking intends to always be a little ahead of where the browsers are, so that the browsers can have something to implement next. So it's ok for the spec to be an aspirational superset. (What's not ok would be for the spec to be incompatible with what the browsers do -- neither a subset or a superset, but a different set.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From barraclough at apple.com Thu Sep 12 11:36:53 2013 From: barraclough at apple.com (Gavin Barraclough) Date: Thu, 12 Sep 2013 11:36:53 -0700 Subject: [whatwg] [[GetOwnProperty]] for named properties of the Window object In-Reply-To: <523113EA.4030908@mit.edu> References: <52600B08-E2BB-4AA3-877E-797E1CF687BC@apple.com> <52293AC6.5020108@mit.edu> <C9BAE4B7-C54B-451A-872D-40D6CEAED23C@apple.com> <523113EA.4030908@mit.edu> Message-ID: <DED137DB-3BD8-4298-A427-FBF2BC33EEE5@apple.com> On Sep 11, 2013, at 6:07 PM, Boris Zbarsky <bzbarsky at MIT.EDU> wrote: > On 9/11/13 6:05 PM, Gavin Barraclough wrote: >> Interesting, I had just assumed this was okay ? is it not spec-compliant for Window.prototype to be a named properties object? > > No, it's not. The spec defines exactly what the prototype chain looks like here. See the definitions of [[Prototype]] athttp://dev.w3.org/2006/webapi/WebIDL/#named-properties-object and http://dev.w3.org/2006/webapi/WebIDL/#interface-prototype-object (item 1 at the latter). Ah, got it, thanks. I?d only spotted the partial description in http://dev.w3.org/2006/webapi/WebIDL/#Global > So the chain by default is window -> Window.prototype -> named properties object -> EventTarget.prototype -> Object.prototype. > > This allows specification of the named properties object without having to worry about weird interactions with name collisions on Window.prototype, whether with properties it has by default or properties someone wants to add to it. Note that the named properties object does not allow [[DefineOwnProperty]], so if it were Window.prototype then you wouldn't be able to add any properties to Window.prototype! > >> I believe these properties are implemented as shadowable in the same way as [Replaceable] properties > > [Replaceable] properties need the magic they have because they're accessor properties, which normally can't be shadowed via assignment. > > But named properties on the named properties object are value properties, so simply making them writable allows them to be shadowed. In fact, that's the only way to make them shadowable. Got it. >> (and then assume a modified behaviour of ES [Put] for properties with this attribute, to permit overwrite even if readonly). > > I don't think a special [Put] is needed if the properties aren't readonly. Hmmm, interesting. I was thinking that in the case that a shadowing property was put to the named property object itself, then deleted, this needed further description (as the old property reappears) ? but I guess that it just covered by the current spec [[GetOwnProperty]] implementation. Many thanks, Gavin From ian at hixie.ch Thu Sep 12 11:43:35 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 12 Sep 2013 18:43:35 +0000 (UTC) Subject: [whatwg] Why are we merging Document and HTMLDocument again? In-Reply-To: <0ED2DF0C-C0AC-496C-8B8B-37FF90D0B436@apple.com> References: <51361FA0.8070101@mit.edu> <CADnb78gB=pdOGZ4tY09V-oANt4+KB-WgoDaEuoR1ibjq+N861g@mail.gmail.com> <51362266.7010804@mit.edu> <CADnb78j_ELAmskAB41-K_DTVbNWuPYfn-fa-VC-n2f=OtA0mQg@mail.gmail.com> <51362671.1010302@mit.edu> <Pine.LNX.4.64.1303052029350.15713@ps20323.dreamhostps.com> <5136589D.4040800@mit.edu> <CADnb78hWVVU1qjKU=mK5AXwwNUmsKHeNfD7HmY1OD2Rj+EXmxw@mail.gmail.com> <alpine.DEB.2.00.1307121752451.15729@ps20323.dreamhostps.com> <51E04531.4070801@mit.edu> <0ED2DF0C-C0AC-496C-8B8B-37FF90D0B436@apple.com> Message-ID: <alpine.DEB.2.00.1309121836290.12199@ps20323.dreamhostps.com> On Tue, 13 Aug 2013, Ryosuke Niwa wrote: > On Jul 12, 2013, at 11:04 AM, Boris Zbarsky wrote: > > On 7/12/13 1:57 PM, Ian Hickson wrote: > > > On Thu, 14 Mar 2013, Anne van Kesteren wrote: > > > > On Tue, Mar 5, 2013 at 8:42 PM, Boris Zbarsky wrote: > > > > > On 3/5/13 3:30 PM, Ian Hickson wrote: > > > > > > On Tue, Mar 5, 2013 at 4:50 PM, Boris Zbarsky wrote: > > > > > > > > > > > > > > I don't want to merge the prototype objects for Document and > > > > > > > HTMLDocument, because I don't want to stick a named getter > > > > > > > on every document. > > > > > > > > > > > > I'd be fine with having a Document descendant that is used for > > > > > > Documents that have global scopes / browsing contexts / the > > > > > > works, and one that is used for Documents that don't (e.g. > > > > > > createDocument(), XHR); would that address this issue? > > > > > > > > > > It's one way to address it, yes... > > > > > > > > Just to be clear, this works for Mozilla, as long as it's clearly > > > > defined and other vendors are on board. Arv? > > > > > > Having not heard any interest from anyone else, I haven't done > > > anything. If there's movement here, let me know. > > > > That's because other UAs are just silently ignoring the spec as > > currently written, for the most part... > > I concur with Boris's concerns. So you also support having a Document descendant that is used for Documents that have global scopes / browsing contexts / the works, and one that is used for Documents that don't (e.g. createDocument(), XHR), where the former has the named getter and the latter doesn't? > Can we at least avoid having OverrideBuiltins on Document? Do you mean in general? Wouldn't that be non-backwards compatible? > Or can we keep HTMLDocument that just defines name getter? When would it be used? Are you agreeing with the proposal above? Or do you have something different in mind? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From bzbarsky at MIT.EDU Thu Sep 12 11:43:42 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Thu, 12 Sep 2013 14:43:42 -0400 Subject: [whatwg] [[GetOwnProperty]] for named properties of the Window object In-Reply-To: <DED137DB-3BD8-4298-A427-FBF2BC33EEE5@apple.com> References: <52600B08-E2BB-4AA3-877E-797E1CF687BC@apple.com> <52293AC6.5020108@mit.edu> <C9BAE4B7-C54B-451A-872D-40D6CEAED23C@apple.com> <523113EA.4030908@mit.edu> <DED137DB-3BD8-4298-A427-FBF2BC33EEE5@apple.com> Message-ID: <52320B5E.3090204@mit.edu> On 9/12/13 2:36 PM, Gavin Barraclough wrote: > Hmmm, interesting. I was thinking that in the case that a shadowing > property was put to the named property object itself Can't be done. Looking at the ES5 [[Put]], ownDesc is a data descriptor here, so we land in step 3b, which calls [[DefineOwnProperty]], which is defined at http://dev.w3.org/2006/webapi/WebIDL/#named-properties-object-defineownproperty and throws if "Throw" and silently does nothing otherwise. ES6 is similar. > then deleted Also can't be done. See http://dev.w3.org/2006/webapi/WebIDL/#named-properties-object-delete > Many thanks, No problem! -Boris From ian at hixie.ch Thu Sep 12 12:05:26 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 12 Sep 2013 19:05:26 +0000 (UTC) Subject: [whatwg] NoDatabase databases In-Reply-To: <5211A249.2020003@yahoo.com> References: <5181F231.2080505@yahoo.com> <alpine.DEB.2.00.1308052328281.9685@ps20323.dreamhostps.com> <5211A249.2020003@yahoo.com> Message-ID: <alpine.DEB.2.00.1309121845390.12199@ps20323.dreamhostps.com> On Mon, 19 Aug 2013, Brett Zamir wrote: > > As far as a user-facing application, for the first case, I have some very > preliminary (but usable) proof-of-concept work for a Firefox add-on (along > with not-yet-reusable Node.js and PHP implementations) at > https://github.com/brettz9/httpquery . Generally speaking, browser add-ons aren't use cases for Web features, they're use cases for browser features. I've ignored anything in your e-mail that wasn't a solution to a specific user problem (i.e. that wasn't a use case). That leaves: > The use case here is the same as why someone would want to use the find > bar Users want to use the find-in-page feature because they have loaded a page that contains some text, but they don't know where in the text it is, so they search for it. Doesn't the find bar already solve that problem pretty completely? > use Firebug Firebug is a feature for debugging sites during development. While certainly that can be made better, it doesn't require standard features to be implemented -- it's a browser feature, needing only hooks into the browser to provide all its features. > apply user scripts to a page A user would do this to change a page to do what the user wanted rather than what the author wanted. It seems like HTML already provides plenty of ways for a browser to implement such features. > use a Microdata-aware search engine A user would do this to find data on the Web. There's certainly plenty more work to be done in this area, but it's not clear how your proposal helps improve this. Can you elaborate on how exactly your proposal helps search engines help users find materials better? Fundamentally, I don't think you've described the problem you're trying to solve succintly enough for any proposal to be evaluated. I recommend putting aside the solution you have, and first trying to completely describe the problem. This should be something you can do in a few short sentences. > > I think that in practice we're going to reach practical limits in user > > agents rendering tables long before we're going to reach practical > > limits of document size. A multimegabyte table is going to cause > > layout problems before it takes appreciable time to download. > > How is that possible? Try it. Downloading a megabyte of succint HTML takes a few seconds. Try rendering it in a browser. Try manipulating it (e.g. changing font sizes): http://damowmow.com/playground/demos/tables/004.html Even today, the page loads in a few seconds, but hovering around that page drops the frame rate of the page to single digits. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From rniwa at apple.com Thu Sep 12 13:42:40 2013 From: rniwa at apple.com (Ryosuke Niwa) Date: Thu, 12 Sep 2013 13:42:40 -0700 Subject: [whatwg] Why are we merging Document and HTMLDocument again? In-Reply-To: <alpine.DEB.2.00.1309121836290.12199@ps20323.dreamhostps.com> References: <51361FA0.8070101@mit.edu> <CADnb78gB=pdOGZ4tY09V-oANt4+KB-WgoDaEuoR1ibjq+N861g@mail.gmail.com> <51362266.7010804@mit.edu> <CADnb78j_ELAmskAB41-K_DTVbNWuPYfn-fa-VC-n2f=OtA0mQg@mail.gmail.com> <51362671.1010302@mit.edu> <Pine.LNX.4.64.1303052029350.15713@ps20323.dreamhostps.com> <5136589D.4040800@mit.edu> <CADnb78hWVVU1qjKU=mK5AXwwNUmsKHeNfD7HmY1OD2Rj+EXmxw@mail.gmail.com> <alpine.DEB.2.00.1307121752451.15729@ps20323.dreamhostps.com> <51E04531.4070801@mit.edu> <0ED2DF0C-C0AC-496C-8B8B-37FF90D0B436@apple.com> <alpine.DEB.2.00.1309121836290.12199@ps20323.dreamhostps.com> Message-ID: <1D191C36-CE39-4A1F-AF45-A75673C35EA1@apple.com> On Sep 12, 2013, at 11:43 AM, Ian Hickson <ian at hixie.ch> wrote: > On Tue, 13 Aug 2013, Ryosuke Niwa wrote: >> On Jul 12, 2013, at 11:04 AM, Boris Zbarsky wrote: >>> On 7/12/13 1:57 PM, Ian Hickson wrote: >>>> On Thu, 14 Mar 2013, Anne van Kesteren wrote: >>>>> On Tue, Mar 5, 2013 at 8:42 PM, Boris Zbarsky wrote: >>>>>> On 3/5/13 3:30 PM, Ian Hickson wrote: >>>>>>> On Tue, Mar 5, 2013 at 4:50 PM, Boris Zbarsky wrote: >>>>>>>> >>>>>>>> I don't want to merge the prototype objects for Document and >>>>>>>> HTMLDocument, because I don't want to stick a named getter >>>>>>>> on every document. >>>>>>> >>>>>>> I'd be fine with having a Document descendant that is used for >>>>>>> Documents that have global scopes / browsing contexts / the >>>>>>> works, and one that is used for Documents that don't (e.g. >>>>>>> createDocument(), XHR); would that address this issue? >>>>>> >>>>>> It's one way to address it, yes... >>>>> >>>>> Just to be clear, this works for Mozilla, as long as it's clearly >>>>> defined and other vendors are on board. Arv? >>>> >>>> Having not heard any interest from anyone else, I haven't done >>>> anything. If there's movement here, let me know. >>> >>> That's because other UAs are just silently ignoring the spec as >>> currently written, for the most part... >> >> I concur with Boris's concerns. > > So you also support having a Document descendant that is used for > Documents that have global scopes / browsing contexts / the works, and one > that is used for Documents that don't (e.g. createDocument(), XHR), where > the former has the named getter and the latter doesn't? I think that's what I'm suggesting except that I'm suggesting to keep calling the former HTMLDocument. >> Can we at least avoid having OverrideBuiltins on Document? > > Do you mean in general? Wouldn't that be non-backwards compatible? I'm using the old terminology here. I meant on Document, not HTMLDocument as we do keep OverrideBuiltins for the latter. >> Or can we keep HTMLDocument that just defines name getter? > > When would it be used? Are you agreeing with the proposal above? Or do you > have something different in mind? As far as I checked, SVGDocument and alike don't have named getter either so I'd rather not introduce it any non-HTML document. - R. Niwa From barraclough at apple.com Thu Sep 12 13:50:06 2013 From: barraclough at apple.com (Gavin Barraclough) Date: Thu, 12 Sep 2013 13:50:06 -0700 Subject: [whatwg] [[GetOwnProperty]] for named properties of the Window object In-Reply-To: <52320B5E.3090204@mit.edu> References: <52600B08-E2BB-4AA3-877E-797E1CF687BC@apple.com> <52293AC6.5020108@mit.edu> <C9BAE4B7-C54B-451A-872D-40D6CEAED23C@apple.com> <523113EA.4030908@mit.edu> <DED137DB-3BD8-4298-A427-FBF2BC33EEE5@apple.com> <52320B5E.3090204@mit.edu> Message-ID: <0B70289A-3DA0-40FB-8E8B-3B1E9EAC736B@apple.com> On Sep 12, 2013, at 11:43 AM, Boris Zbarsky <bzbarsky at MIT.EDU> wrote: > On 9/12/13 2:36 PM, Gavin Barraclough wrote: >> Hmmm, interesting. I was thinking that in the case that a shadowing >> property was put to the named property object itself > > Can't be done. Looking at the ES5 [[Put]], ownDesc is a data descriptor here, so we land in step 3b, which calls [[DefineOwnProperty]], which is defined at http://dev.w3.org/2006/webapi/WebIDL/#named-properties-object-defineownpropertyand throws if "Throw" and silently does nothing otherwise. ES6 is similar. Ah, good point. Firefox, Safari, Chrome all currently all allow this, but seems reasonable to prohibit. cheers, G. >> then deleted > > Also can't be done. See http://dev.w3.org/2006/webapi/WebIDL/#named-properties-object-delete > >> Many thanks, > > No problem! > > -Boris From ian at hixie.ch Thu Sep 12 14:00:57 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 12 Sep 2013 21:00:57 +0000 (UTC) Subject: [whatwg] Why are we merging Document and HTMLDocument again? In-Reply-To: <1D191C36-CE39-4A1F-AF45-A75673C35EA1@apple.com> References: <51361FA0.8070101@mit.edu> <CADnb78gB=pdOGZ4tY09V-oANt4+KB-WgoDaEuoR1ibjq+N861g@mail.gmail.com> <51362266.7010804@mit.edu> <CADnb78j_ELAmskAB41-K_DTVbNWuPYfn-fa-VC-n2f=OtA0mQg@mail.gmail.com> <51362671.1010302@mit.edu> <Pine.LNX.4.64.1303052029350.15713@ps20323.dreamhostps.com> <5136589D.4040800@mit.edu> <CADnb78hWVVU1qjKU=mK5AXwwNUmsKHeNfD7HmY1OD2Rj+EXmxw@mail.gmail.com> <alpine.DEB.2.00.1307121752451.15729@ps20323.dreamhostps.com> <51E04531.4070801@mit.edu> <0ED2DF0C-C0AC-496C-8B8B-37FF90D0B436@apple.com> <alpine.DEB.2.00.1309121836290.12199@ps20323.dreamhostps.com> <1D191C36-CE39-4A1F-AF45-A75673C35EA1@apple.com> Message-ID: <alpine.DEB.2.00.1309122055280.12210@ps20323.dreamhostps.com> On Thu, 12 Sep 2013, Ryosuke Niwa wrote: > On Sep 12, 2013, at 11:43 AM, Ian Hickson <ian at hixie.ch> wrote: > > > > So you also support having a Document descendant that is used for > > Documents that have global scopes / browsing contexts / the works, and > > one that is used for Documents that don't (e.g. createDocument(), > > XHR), where the former has the named getter and the latter doesn't? > > I think that's what I'm suggesting except that I'm suggesting to keep > calling the former HTMLDocument. > > As far as I checked, SVGDocument and alike don't have named getter > either so I'd rather not introduce it any non-HTML document. What's an "HTML document" in this world? Something served using text/html? Something with a browsing context? Some combination thereof? SVGDocument is supposed to be merged into Document as well. The idea is to not have any descendants of Document. The reason is that you can have compound documents that need both the SVG and HTML (and MathML and FooML) methods. There's no such thing as "non-HTML documents" now. Documents can have SVG and HTML and mix it at will. I can see having a special descendant that does the name stuff, if we can determine exactly when it would apply. Note that what the DOM and HTML specs call "HTML Document" vs "XML Document" is not the same criteria as was being discussed here earlier (whether it has a browsing context). But I think it's unfortunate to be considering yet another mode switch. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From davidc at nag.co.uk Thu Sep 12 15:58:21 2013 From: davidc at nag.co.uk (David Carlisle) Date: Thu, 12 Sep 2013 23:58:21 +0100 Subject: [whatwg] URL resolution of fragment urls in html5 webapps In-Reply-To: <CADnb78iHZEKdX8F_76vezghkXNiXcq64Edmr2-ofHKhZ17hJcQ@mail.gmail.com> References: <CAO9zZYMo79Dqn-EK8S0j-M9sNJeFEGQg_XgP6+fsszDmq5oDMQ@mail.gmail.com> <CANr5HFXkxQuiy+n1jDkd=jP92Wz=E0_BrGbo40A0xxjpbAw2dQ@mail.gmail.com> <CAO9zZYOuSfkkGbqFWeeJ-gu1k0mZLFfnjrgkiweL+EN9aGGoiw@mail.gmail.com> <alpine.DEB.2.00.1309100013320.12199@ps20323.dreamhostps.com> <CADnb78iS2LsMporp8qKxFmmBy-rHH7q++_-osP94oaWAtjzdcw@mail.gmail.com> <alpine.DEB.2.00.1309111821360.12210@ps20323.dreamhostps.com> <CADnb78iHZEKdX8F_76vezghkXNiXcq64Edmr2-ofHKhZ17hJcQ@mail.gmail.com> Message-ID: <5232470D.5050107@nag.co.uk> On 12/09/2013 10:24, Anne van Kesteren wrote: > Yeah, we should have to do it for everything we classify as > "hyperlink". <a>, <svg:a>, <area>, and <link> I suppose. I'm not > sure what in MathML would need covering. more or less anything in MathML takes an href attribute (and then should act like <a href, whatever you decide that should do.) My reading of the RFCs that Ian referenced was always that #foo was a same-document reference irrespective of any explicit settings of the base URL, but whatever, links in MathML-in-HTML should just do whatever links in HTML do. David From cabanier at gmail.com Thu Sep 12 16:28:09 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Thu, 12 Sep 2013 16:28:09 -0700 Subject: [whatwg] Stroking algorithm in Canvas 2d In-Reply-To: <CAGN7qDDgfZmoZvj9JEwzM764LHWivn=nh_WyGfJOX7SdW31vvg@mail.gmail.com> References: <CAGN7qDA-iib4SULW-JDf4_vpsyuxpg1m8AkXq=qgDtY1OkXahA@mail.gmail.com> <alpine.DEB.2.00.1309091626010.12210@ps20323.dreamhostps.com> <CAGN7qDDgfZmoZvj9JEwzM764LHWivn=nh_WyGfJOX7SdW31vvg@mail.gmail.com> Message-ID: <CAGN7qDDfcvmrJciqPDhJ_YPT=n4caMRZTAQ_SgYwE1pjPx5iYA@mail.gmail.com> Maybe we can start by extracting dashing from the pseudo code. The process of dashing should break up every subpath in a bunch of new subpaths. This new collection of subpaths can then be stroked. Currently the spec says: 1 Let width be the aggregate length of all the lines of all the subpaths in path, in coordinate space units. 2 Let offset be the value of the styles lineDashOffset, in coordinate space units. 3 While offset is greater than width, decrement it by width. 4 While offset is less than width, increment it by width. For 1, dashing should be applied to each subpath. As the PDF reference manual says: When a path consisting of several subpaths is stroked, each subpath shall be treated independently?that is, the dash pattern shall be restarted and the dash phase shall be reapplied to it at the beginning of each subpath. 2 - 4 are not correct. From the PDF reference: Before beginning to stroke a path, the dash array shall be cycled through, adding up the lengths of dashes and gaps. When the accumulated length equals the value specified by the dash phase, stroking of the path shall begin, and the dash array shall be used cyclically from that point onward. So, this cycling should be done on the dash array and not the length of the path that it applies to. From bzbarsky at MIT.EDU Thu Sep 12 17:52:50 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Thu, 12 Sep 2013 20:52:50 -0400 Subject: [whatwg] [[GetOwnProperty]] for named properties of the Window object In-Reply-To: <0B70289A-3DA0-40FB-8E8B-3B1E9EAC736B@apple.com> References: <52600B08-E2BB-4AA3-877E-797E1CF687BC@apple.com> <52293AC6.5020108@mit.edu> <C9BAE4B7-C54B-451A-872D-40D6CEAED23C@apple.com> <523113EA.4030908@mit.edu> <DED137DB-3BD8-4298-A427-FBF2BC33EEE5@apple.com> <52320B5E.3090204@mit.edu> <0B70289A-3DA0-40FB-8E8B-3B1E9EAC736B@apple.com> Message-ID: <523261E2.30008@mit.edu> On 9/12/13 4:50 PM, Gavin Barraclough wrote: > Ah, good point. Firefox, Safari, Chrome all currently all allow this, > but seems reasonable to prohibit. For what it's worth, Firefox nightlies prohibit it, ever since https://bugzilla.mozilla.org/show_bug.cgi?id=895758 allowed us to actually do so. -Boris From rniwa at apple.com Thu Sep 12 18:52:38 2013 From: rniwa at apple.com (Ryosuke Niwa) Date: Thu, 12 Sep 2013 18:52:38 -0700 Subject: [whatwg] Why are we merging Document and HTMLDocument again? In-Reply-To: <alpine.DEB.2.00.1309122055280.12210@ps20323.dreamhostps.com> References: <51361FA0.8070101@mit.edu> <CADnb78gB=pdOGZ4tY09V-oANt4+KB-WgoDaEuoR1ibjq+N861g@mail.gmail.com> <51362266.7010804@mit.edu> <CADnb78j_ELAmskAB41-K_DTVbNWuPYfn-fa-VC-n2f=OtA0mQg@mail.gmail.com> <51362671.1010302@mit.edu> <Pine.LNX.4.64.1303052029350.15713@ps20323.dreamhostps.com> <5136589D.4040800@mit.edu> <CADnb78hWVVU1qjKU=mK5AXwwNUmsKHeNfD7HmY1OD2Rj+EXmxw@mail.gmail.com> <alpine.DEB.2.00.1307121752451.15729@ps20323.dreamhostps.com> <51E04531.4070801@mit.edu> <0ED2DF0C-C0AC-496C-8B8B-37FF90D0B436@apple.com> <alpine.DEB.2.00.1309121836290.12199@ps20323.dreamhostps.com> <1D191C36-CE39-4A1F-AF45-A75673C35EA1@apple.com> <alpine.DEB.2.00.1309122055280.12210@ps20323.dreamhostps.com> Message-ID: <3BD3DB4F-5409-4CC9-9310-2C7E90CBC37B@apple.com> On Sep 12, 2013, at 2:00 PM, Ian Hickson <ian at hixie.ch> wrote: > On Thu, 12 Sep 2013, Ryosuke Niwa wrote: >> On Sep 12, 2013, at 11:43 AM, Ian Hickson <ian at hixie.ch> wrote: >>> >>> So you also support having a Document descendant that is used for >>> Documents that have global scopes / browsing contexts / the works, and >>> one that is used for Documents that don't (e.g. createDocument(), >>> XHR), where the former has the named getter and the latter doesn't? >> >> I think that's what I'm suggesting except that I'm suggesting to keep >> calling the former HTMLDocument. >> >> As far as I checked, SVGDocument and alike don't have named getter >> either so I'd rather not introduce it any non-HTML document. > > What's an "HTML document" in this world? Something served using text/html? > Something with a browsing context? Some combination thereof? I'm not trying to invent anything new here. HTMLDocument as existed before the merge. > SVGDocument is supposed to be merged into Document as well. The idea is to > not have any descendants of Document. The reason is that you can have > compound documents that need both the SVG and HTML (and MathML and FooML) > methods. There's no such thing as "non-HTML documents" now. Documents can > have SVG and HTML and mix it at will. That's okay but there's no point in bringing in legacy features like named property in that new world. Named properties impos a significant runtime cost, and we'd like to get rid of them as much as possible. As such, I'm strongly opposed to supporting it in more places. - R. Niwa From ian at hixie.ch Thu Sep 12 21:15:05 2013 From: ian at hixie.ch (Ian Hickson) Date: Fri, 13 Sep 2013 04:15:05 +0000 (UTC) Subject: [whatwg] Why are we merging Document and HTMLDocument again? In-Reply-To: <3BD3DB4F-5409-4CC9-9310-2C7E90CBC37B@apple.com> References: <51361FA0.8070101@mit.edu> <CADnb78gB=pdOGZ4tY09V-oANt4+KB-WgoDaEuoR1ibjq+N861g@mail.gmail.com> <51362266.7010804@mit.edu> <CADnb78j_ELAmskAB41-K_DTVbNWuPYfn-fa-VC-n2f=OtA0mQg@mail.gmail.com> <51362671.1010302@mit.edu> <Pine.LNX.4.64.1303052029350.15713@ps20323.dreamhostps.com> <5136589D.4040800@mit.edu> <CADnb78hWVVU1qjKU=mK5AXwwNUmsKHeNfD7HmY1OD2Rj+EXmxw@mail.gmail.com> <alpine.DEB.2.00.1307121752451.15729@ps20323.dreamhostps.com> <51E04531.4070801@mit.edu> <0ED2DF0C-C0AC-496C-8B8B-37FF90D0B436@apple.com> <alpine.DEB.2.00.1309121836290.12199@ps20323.dreamhostps.com> <1D191C36-CE39-4A1F-AF45-A75673C35EA1@apple.com> <alpine.DEB.2.00.1309122055280.12210@ps20323.dreamhostps.com> <3BD3DB4F-5409-4CC9-9310-2C7E90CBC37B@apple.com> Message-ID: <alpine.DEB.2.00.1309130409200.12210@ps20323.dreamhostps.com> On Thu, 12 Sep 2013, Ryosuke Niwa wrote: > On Sep 12, 2013, at 2:00 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Thu, 12 Sep 2013, Ryosuke Niwa wrote: > >> On Sep 12, 2013, at 11:43 AM, Ian Hickson <ian at hixie.ch> wrote: > >>> > >>> So you also support having a Document descendant that is used for > >>> Documents that have global scopes / browsing contexts / the works, > >>> and one that is used for Documents that don't (e.g. > >>> createDocument(), XHR), where the former has the named getter and > >>> the latter doesn't? > >> > >> I think that's what I'm suggesting except that I'm suggesting to keep > >> calling the former HTMLDocument. > >> > >> As far as I checked, SVGDocument and alike don't have named getter > >> either so I'd rather not introduce it any non-HTML document. > > > > What's an "HTML document" in this world? Something served using > > text/html? Something with a browsing context? Some combination > > thereof? > > I'm not trying to invent anything new here. HTMLDocument as existed > before the merge. Ok, I guess I'm confused then, because earlier you said you agreed with the idea of removing this feature from non-browsing-context Documents, which is a different criteria. > > SVGDocument is supposed to be merged into Document as well. The idea > > is to not have any descendants of Document. The reason is that you can > > have compound documents that need both the SVG and HTML (and MathML > > and FooML) methods. There's no such thing as "non-HTML documents" now. > > Documents can have SVG and HTML and mix it at will. > > That's okay but there's no point in bringing in legacy features like > named property in that new world. What we did is bring SVG into the "old world", so that there's no distinction between these new kinds of documents and HTMLDocuments. So on the contrary, I don't see how else we could do it if we want it to be possible to have HTML and SVG in text/html. > Named properties impos a significant runtime cost, and we'd like to get > rid of them as much as possible. As such, I'm strongly opposed to > supporting it in more places. What are the places you see us as adding this in? Just XML documents? Those are so rare that it doesn't seem to me that it makes much difference one way or the other. (That's not saying I don't want to remove them there either. We could definitely say something like "the set of named properties is empty if the document is not marked as being an "HTML document" (in the DOM Core sense) "or if the document has no browsing context" -- but that seems orthogonal to the original issue of Document vs HTMLDocument vs SVGDocument.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jungkee.song at samsung.com Thu Sep 12 22:42:56 2013 From: jungkee.song at samsung.com (Jungkee Song) Date: Fri, 13 Sep 2013 14:42:56 +0900 Subject: [whatwg] [XHR] changes in abort() steps Message-ID: <03fd01ceb044$195dde90$4c199bb0$@samsung.com> Hi Anne, In the recent change in abort() steps [1], is it intended to NOT change the state to UNSENT for an ongoing (the send() flag set) request? It's observed that Chrome, Firefox, IE all set it to UNSENT. Also, a few test cases in W3C tests have assertions on it: request.send(); request.abort(); request.assert_true(client.readyState, 4); [1] https://github.com/whatwg/xhr/commit/9b57f112dba4d135986d956b41109607dd90827 3 -- Jungkee Song From jungkee.song at samsung.com Thu Sep 12 22:46:38 2013 From: jungkee.song at samsung.com (Jungkee Song) Date: Fri, 13 Sep 2013 14:46:38 +0900 Subject: [whatwg] [XHR] changes in abort() steps In-Reply-To: <03fd01ceb044$195dde90$4c199bb0$@samsung.com> References: <03fd01ceb044$195dde90$4c199bb0$@samsung.com> Message-ID: <03ff01ceb044$9db2f9a0$d918ece0$@samsung.com> Correction in the code snippet inline. > -----Original Message----- > From: whatwg-bounces at lists.whatwg.org [mailto:whatwg- > bounces at lists.whatwg.org] On Behalf Of Jungkee Song > Sent: Friday, September 13, 2013 2:43 PM > To: Anne van Kesteren; whatwg at lists.whatwg.org > Subject: [whatwg] [XHR] changes in abort() steps > > Hi Anne, > > In the recent change in abort() steps [1], is it intended to NOT change > the state to UNSENT for an ongoing (the send() flag set) request? It's > observed that Chrome, Firefox, IE all set it to UNSENT. Also, a few test > cases in W3C tests have assertions on it: > > request.send(); > request.abort(); > request.assert_true(client.readyState, 0); // UNSENT > > > [1] > https://github.com/whatwg/xhr/commit/9b57f112dba4d135986d956b41109607dd908 > 27 > 3 > > > -- > Jungkee Song From simonp at opera.com Fri Sep 13 00:42:26 2013 From: simonp at opera.com (Simon Pieters) Date: Fri, 13 Sep 2013 09:42:26 +0200 Subject: [whatwg] Why are we merging Document and HTMLDocument again? In-Reply-To: <alpine.DEB.2.00.1309130409200.12210@ps20323.dreamhostps.com> References: <51361FA0.8070101@mit.edu> <CADnb78gB=pdOGZ4tY09V-oANt4+KB-WgoDaEuoR1ibjq+N861g@mail.gmail.com> <51362266.7010804@mit.edu> <CADnb78j_ELAmskAB41-K_DTVbNWuPYfn-fa-VC-n2f=OtA0mQg@mail.gmail.com> <51362671.1010302@mit.edu> <Pine.LNX.4.64.1303052029350.15713@ps20323.dreamhostps.com> <5136589D.4040800@mit.edu> <CADnb78hWVVU1qjKU=mK5AXwwNUmsKHeNfD7HmY1OD2Rj+EXmxw@mail.gmail.com> <alpine.DEB.2.00.1307121752451.15729@ps20323.dreamhostps.com> <51E04531.4070801@mit.edu> <0ED2DF0C-C0AC-496C-8B8B-37FF90D0B436@apple.com> <alpine.DEB.2.00.1309121836290.12199@ps20323.dreamhostps.com> <1D191C36-CE39-4A1F-AF45-A75673C35EA1@apple.com> <alpine.DEB.2.00.1309122055280.12210@ps20323.dreamhostps.com> <3BD3DB4F-5409-4CC9-9310-2C7E90CBC37B@apple.com> <alpine.DEB.2.00.1309130409200.12210@ps20323.dreamhostps.com> Message-ID: <op.w3cac0spidj3kv@simons-macbook-pro.local> On Fri, 13 Sep 2013 06:15:05 +0200, Ian Hickson <ian at hixie.ch> wrote: > What are the places you see us as adding this in? So the concepts discussed here are probably a bit confusing if one doesn't know what the spec terms mean. Let's list concrete cases and see what we want to do with each one. In a browsing context: * text/html document (uses interface "Document" and is an "HTML document") * XML document (uses interface "Document" and is an "XML document") Not in a browsing context: * document.implementation.createDocument() (uses interface "XMLDocument" and is an "XML document") * document.implementation.createHTMLDocument() (uses interface "Document" and is an "HTML document") * new Document() (uses interface "Document" and is an "XML document") * XHR response (uses interface "Document" and is an "XML document", even for text/html if I read the spec correctly) For instance the createHTMLDocument() case currently supports named getter in Gecko but not in Blink. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2519 -- Simon Pieters Opera Software From dschulze at adobe.com Fri Sep 13 01:27:37 2013 From: dschulze at adobe.com (Dirk Schulze) Date: Fri, 13 Sep 2013 01:27:37 -0700 Subject: [whatwg] Fetch SVG images with No CORS tainted cross-origin Message-ID: <A8E761CD-7DB9-4692-BBB3-9C9572B6C833@adobe.com> Hi, If I understand HTML <img> fetching and the fetch spec right. The default behavior on image fetching is No CORS with the mode tainted cross-origin. For the example: <img src="image.svg"> and image.svg: <svg> <image xlink:href="http://otherdomain.com/image.svg"> </svg> In this case the image.svg would be fetched with basic fetch and tainted cross-origin. But the image inside this image would also be loaded as basic fetch tainted cross origin. Right? For various reasons (as described in Mozilla bug 628747[1]). We do not want to have image load further _external_ resources. WebKit, Blink and Gecko allow dataURLs and Gecko allows blobs as resources. I couldn't find a specification for that in the Fetch specification. WebKit and Blink call that "single security origin". If the SVG was fetched as an image resource, it is not allowed to fetch other resources with the described exception above. So, I wonder how that behavior could be described. Sadly it is not always the same behavior. If the SVG image is referenced by an <object>, <embed> or <iframe>, it does not count as "image" anymore but as a document and it can fetch resources again. For my use case of <mask> and <filter> the SVG WG resolved to have the same fetching mechanisms and restrictions as for SVG as "images". To summarize. We have two kind of possibilities of fetching in SVG: SVG with "single security origin": The SVG is not allowed to fetch any external resources. References in the same document and dataURLs, blobs are allowed. SVG "as document": Allowed to fetch resources with No CORS - But: possibly CORS enabled depending on the referencing element (<object>, <embed> or <iframe>). Would it be possible to define it that way? If the former named elements, then use the fetching mechanism defined by these elements. Otherwise use "single security origin"? Could Fetch define "single security origin"? Greetings, Dirk [1] https://bugzilla.mozilla.org/show_bug.cgi?id=628747 From annevk at annevk.nl Fri Sep 13 01:35:40 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Fri, 13 Sep 2013 09:35:40 +0100 Subject: [whatwg] [XHR] changes in abort() steps In-Reply-To: <03fd01ceb044$195dde90$4c199bb0$@samsung.com> References: <03fd01ceb044$195dde90$4c199bb0$@samsung.com> Message-ID: <CADnb78hUkfFHKrVo9DmToMPXp_tmGuj+qYOsJkiaE7C8vNia=A@mail.gmail.com> On Fri, Sep 13, 2013 at 6:42 AM, Jungkee Song <jungkee.song at samsung.com> wrote: > In the recent change in abort() steps, is it intended to NOT change the > state to UNSENT for an ongoing (the send() flag set) request? It's observed > that Chrome, Firefox, IE all set it to UNSENT. Also, a few test cases in W3C > tests have assertions on it: > > request.send(); > request.abort(); > request.assert_true(client.readyState, [0]); Good catch! I totally missed abort() would always end up in UNSENT. Tried to make that clearer by appending " first" to "Otherwise, run these substeps". -- http://annevankesteren.nl/ From annevk at annevk.nl Fri Sep 13 01:43:25 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Fri, 13 Sep 2013 09:43:25 +0100 Subject: [whatwg] Fetch SVG images with No CORS tainted cross-origin In-Reply-To: <A8E761CD-7DB9-4692-BBB3-9C9572B6C833@adobe.com> References: <A8E761CD-7DB9-4692-BBB3-9C9572B6C833@adobe.com> Message-ID: <CADnb78iGxPOhS+V0xB441s=mJmYbcq8-E8fLy=fgJy3STgfjMA@mail.gmail.com> On Fri, Sep 13, 2013 at 9:27 AM, Dirk Schulze <dschulze at adobe.com> wrote: > So, I wonder how that behavior could be described. I think you'd have a mode switch and maybe a wrapper for Fetch that only calls it for data and blob URLs. It seems like you don't really want to invoke Fetch at all for SVG as image. Do scripts even execute in that context? How do you get blob URLs? I suppose we could have a mode for that in Fetch too, but it seems really SVG specific so I'm not sure that's warranted. > SVG with "single security origin": The SVG is not allowed to fetch any external resources. References in the same document and dataURLs, blobs are allowed. > SVG "as document": Allowed to fetch resources with No CORS - But: possibly CORS enabled depending on the referencing element (<object>, <embed> or <iframe>). > > Would it be possible to define it that way? If the former named elements, then use the fetching mechanism defined by these elements. Otherwise use "single security origin"? Could Fetch define "single security origin"? This sentence doesn't make sense. At least the "otherwise" clause in it. I'm not sure "single security origin" makes sense either as I think you don't want to do any fetching whatsoever. If something does a fetch, you want to return network error immediately and don't even attempt to make a connection as that could leak information. So SVG resources should have a "locked down flag" and when it's set "SVG fetch" or whatever you end up calling the wrapper will return "network error" rather than invoking "fetch" unless the URL's scheme is about, blob, or data I suppose. -- http://annevankesteren.nl/ From annevk at annevk.nl Fri Sep 13 01:53:42 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Fri, 13 Sep 2013 09:53:42 +0100 Subject: [whatwg] Why are we merging Document and HTMLDocument again? In-Reply-To: <op.w3cac0spidj3kv@simons-macbook-pro.local> References: <51361FA0.8070101@mit.edu> <CADnb78gB=pdOGZ4tY09V-oANt4+KB-WgoDaEuoR1ibjq+N861g@mail.gmail.com> <51362266.7010804@mit.edu> <CADnb78j_ELAmskAB41-K_DTVbNWuPYfn-fa-VC-n2f=OtA0mQg@mail.gmail.com> <51362671.1010302@mit.edu> <Pine.LNX.4.64.1303052029350.15713@ps20323.dreamhostps.com> <5136589D.4040800@mit.edu> <CADnb78hWVVU1qjKU=mK5AXwwNUmsKHeNfD7HmY1OD2Rj+EXmxw@mail.gmail.com> <alpine.DEB.2.00.1307121752451.15729@ps20323.dreamhostps.com> <51E04531.4070801@mit.edu> <0ED2DF0C-C0AC-496C-8B8B-37FF90D0B436@apple.com> <alpine.DEB.2.00.1309121836290.12199@ps20323.dreamhostps.com> <1D191C36-CE39-4A1F-AF45-A75673C35EA1@apple.com> <alpine.DEB.2.00.1309122055280.12210@ps20323.dreamhostps.com> <3BD3DB4F-5409-4CC9-9310-2C7E90CBC37B@apple.com> <alpine.DEB.2.00.1309130409200.12210@ps20323.dreamhostps.com> <op.w3cac0spidj3kv@simons-macbook-pro.local> Message-ID: <CADnb78iH2J02uX7Winh=93BBNnovUXeo2T0Dfy_Q5aN0+x+o5w@mail.gmail.com> On Fri, Sep 13, 2013 at 8:42 AM, Simon Pieters <simonp at opera.com> wrote: > * XHR response (uses interface "Document" and is an "XML document", even for > text/html if I read the spec correctly) I assumed :/ that HTML would do the marking. Let's consider this a bug. It's not entirely clear to me what the suggestion from Ryosuke is. Is it to keep getters on HTMLDocument only and expose HTMLDocument only in browsing contexts created from text/html resources? And use Document everywhere else and have Document contain all the other members including (former) SVGDocument members? That setup would make sense to me anyway. -- http://annevankesteren.nl/ From dschulze at adobe.com Fri Sep 13 02:52:18 2013 From: dschulze at adobe.com (Dirk Schulze) Date: Fri, 13 Sep 2013 02:52:18 -0700 Subject: [whatwg] Fetch SVG images with No CORS tainted cross-origin In-Reply-To: <CADnb78iGxPOhS+V0xB441s=mJmYbcq8-E8fLy=fgJy3STgfjMA@mail.gmail.com> References: <A8E761CD-7DB9-4692-BBB3-9C9572B6C833@adobe.com> <CADnb78iGxPOhS+V0xB441s=mJmYbcq8-E8fLy=fgJy3STgfjMA@mail.gmail.com> Message-ID: <1B872A94-5E1E-4E5C-B42B-04B1D8AB9555@adobe.com> On Sep 13, 2013, at 10:43 AM, Anne van Kesteren <annevk at annevk.nl> wrote: > On Fri, Sep 13, 2013 at 9:27 AM, Dirk Schulze <dschulze at adobe.com> wrote: >> So, I wonder how that behavior could be described. > > I think you'd have a mode switch and maybe a wrapper for Fetch that > only calls it for data and blob URLs. It seems like you don't really > want to invoke Fetch at all for SVG as image. If Fetch is not just fetching external (as not in the current document) then we still need it for SVG. References within the same document must still work. > Do scripts even execute > in that context? How do you get blob URLs? In WebKit and Blink you can't execute any script anywhere in an SVG document. I am not sure about Gecko but this is the feedback I got. Maybe someone from Mozilla can answer this. > > I suppose we could have a mode for that in Fetch too, but it seems > really SVG specific so I'm not sure that's warranted. > Yes, it is quite SVG specific. I am fine with just dealing with it in SVG as long as possible. And I think it is not possible without changing the fetching on the requesters like <img>. (This is the case for CSS as well btw, which can reference SVG images - different topic.) > >> SVG with "single security origin": The SVG is not allowed to fetch any external resources. References in the same document and dataURLs, blobs are allowed. >> SVG "as document": Allowed to fetch resources with No CORS - But: possibly CORS enabled depending on the referencing element (<object>, <embed> or <iframe>). >> >> Would it be possible to define it that way? If the former named elements, then use the fetching mechanism defined by these elements. Otherwise use "single security origin"? Could Fetch define "single security origin"? > > This sentence doesn't make sense. At least the "otherwise" clause in > it. I'm not sure "single security origin" makes sense either as I > think you don't want to do any fetching whatsoever. If something does > a fetch, you want to return network error immediately and don't even > attempt to make a connection as that could leak information. So SVG > resources should have a "locked down flag" and when it's set "SVG > fetch" or whatever you end up calling the wrapper will return "network > error" rather than invoking "fetch" unless the URL's scheme is about, > blob, or data I suppose. So first, for the first case (before "otherwise") there is nothing that needs to be changed. Fetch and HTML already cover that. The second case would indeed need a flag like "locked down flag". This would just allow fetching of resources in the same document, dataURLs (with lock down for the content of dataURL) and possibly blob URLs. The requester needs to set this "lock down flag". So ideally it would be specified by the Fetch specification. Legacy fetching (used for image fetching) would set this flag by default. In this case no other specification but Fetch and CSS would need to change. Greetings, Dirk > > > -- > http://annevankesteren.nl/ From robin at w3.org Fri Sep 13 03:10:47 2013 From: robin at w3.org (Robin Berjon) Date: Fri, 13 Sep 2013 12:10:47 +0200 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: <CADnb78jQQC3hdRFYfd5n05+VucVhsr9hYUn8OYM=kBGbPcdDJA@mail.gmail.com> References: <CADnb78jksF5RdfPK4Brcib=N-jYcf0YrO=o=fFz4ZLUqTgLUMg@mail.gmail.com> <EE30D49E-FDB4-4BDA-AC0E-33B4E6B2C521@4d.com> <DE55B4C4-6983-44DD-8C44-5E552259D8A4@4d.com> <CADnb78jQQC3hdRFYfd5n05+VucVhsr9hYUn8OYM=kBGbPcdDJA@mail.gmail.com> Message-ID: <5232E4A7.5030203@w3.org> On 29/08/2013 14:48 , Anne van Kesteren wrote: > On Thu, Aug 29, 2013 at 1:15 PM, Alexandre Morgaut > <Alexandre.Morgaut at 4d.com> wrote: >> In the solution mentioned with <link> tag and a "pack:" like scheme >> >> <link id="pack1" rel="package" src="/pack1.zip" type="application/zip" title="My app global resources"> > > I don't think adding a level of indirection is a good idea. I think > the added complexity is the reason this proposal failed the last time > and I don't see a reason to revive it. Actually, the primary objection I recall from the last round of this was that it did not address the major use case that was being considered then, which was performance. It's a revisit of "Limi Packages" and it would seem that they can 1) be slower than individual files in a fair number of cases and 2) bring between nothing and very little compared to SPDY. Of course, that does not remove the value there is in making Zip first class for reasons other than performance. If we can do it without the above indirection then it clearly is better, but using <link> indirection it is possible to make this work without a new scheme, without changing the URL syntax, and while opening the door to graceful fallback. The basic idea is that you start with this: <link rel="package" href="/foo.zip"> and then every URL in the document (e.g. <img src="/foo.zip/meow.gif">) that's a prefix-match for the link's href gets loaded through the zip. Older browsers will fetch /foo.zip/meow.gif, which the server can trivially detect as an error and handle by sending the content from inside the zip. I would rather we figured this out without <link>, but apart from the indirection I reckon this approach has some nice properties and might work if more direct ones don't. -- Robin Berjon - http://berjon.com/ - @robinberjon From robin at w3.org Fri Sep 13 03:12:21 2013 From: robin at w3.org (Robin Berjon) Date: Fri, 13 Sep 2013 12:12:21 +0200 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: <521F4E87.6070202@mit.edu> References: <CADnb78jksF5RdfPK4Brcib=N-jYcf0YrO=o=fFz4ZLUqTgLUMg@mail.gmail.com> <CAJ5xic-npAJAhWV4sV7ut=5Vu3bTfuxfeXLtjtnvj9B6st8mAQ@mail.gmail.com> <CADnb78ieWieX_eZ44QB09tMW8_FP4YNFxCZNs4hgUrkd8drBGQ@mail.gmail.com> <521F4C0B.9020101@mit.edu> <CADnb78jiMvF5-w6249LyyjUSi7CgfRzVSHCoA0hmemRJsmEAFg@mail.gmail.com> <521F4E87.6070202@mit.edu> Message-ID: <5232E505.7040102@w3.org> On 29/08/2013 15:37 , Boris Zbarsky wrote: > On 8/29/13 9:32 AM, Anne van Kesteren wrote: >> Doing a mixture of sniffing and labeling has not served us very well. >> We cannot rely solely on sniffing because of CSS and SVG. We can rely >> solely on a standardized mapping table of extension to Content-Type. > > Ah, ok, the extension table is standardized, not gotten from the OS? OK, > that works. And shockingly enough, that's been done before: http://www.w3.org/TR/widgets/#rule-for-identifying-the-media-type-of-a-file-0 There could be a few things worth pilfering from that document in general. -- Robin Berjon - http://berjon.com/ - @robinberjon From robin at w3.org Fri Sep 13 03:32:43 2013 From: robin at w3.org (Robin Berjon) Date: Fri, 13 Sep 2013 12:32:43 +0200 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: <op.w2kzr1yiidj3kv@simons-macbook-pro.local> References: <CADnb78jksF5RdfPK4Brcib=N-jYcf0YrO=o=fFz4ZLUqTgLUMg@mail.gmail.com> <CAJ5xic-npAJAhWV4sV7ut=5Vu3bTfuxfeXLtjtnvj9B6st8mAQ@mail.gmail.com> <CADnb78ieWieX_eZ44QB09tMW8_FP4YNFxCZNs4hgUrkd8drBGQ@mail.gmail.com> <op.w2kzr1yiidj3kv@simons-macbook-pro.local> Message-ID: <5232E9CB.5010409@w3.org> On 29/08/2013 15:58 , Simon Pieters wrote: > On Thu, 29 Aug 2013 15:02:48 +0200, Anne van Kesteren <annevk at annevk.nl> > wrote: >> On Thu, Aug 29, 2013 at 1:19 PM, Jake Archibald >> <jaffathecake at gmail.com> wrote: >>> Causing a network error in existing browsers is a shame. > > It seems to fail to resolve in IE10. It works in > Gecko/WebKit/Blink/Presto: the %! is requested literally. However, both > Apache and IIS seems to return 400 Bad Request. That's not exactly promising. >> Picking something that could occur in paths seems problematic. > > I'm not sure why it's more problematic than something than could occur > in the fragment. > > For instance, the string "$zip=" is not present at all in > http://webdevdata.org/ data set 18/06/2013. So maybe we could use a > string like that in the path and have a graceful fallback path in legacy > browsers that work in existing servers. That's my preferred approach so far. However I wonder about the precise details. Assuming <img src="/foo.zip/$zip=dahut.png"> I'm guessing that the browser would actually just request "/foo.zip" from the server in the same manner that fragments are stripped, right? Somehow the stripping bothers me a bit; for instance, what would Navigation Controller see? I wonder if we couldn't just use the query part for this: <img src="/foo.zip?!zip/dahut.png">. No stripping is needed (as far as I know servers would normally just serve foo.zip in this case), which simplifies the model. -- Robin Berjon - http://berjon.com/ - @robinberjon From robert at ocallahan.org Fri Sep 13 04:07:25 2013 From: robert at ocallahan.org (Robert O'Callahan) Date: Fri, 13 Sep 2013 04:07:25 -0700 Subject: [whatwg] High-density canvases In-Reply-To: <alpine.DEB.2.00.1309121742300.12210@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> <CAGN7qDCC=8EZUpEmN=10tcWGU=8TPQ7rej+sOGhbPaWqqAjWRA@mail.gmail.com> <CAOp6jLZFD_HVKgEfEUB0myCdvz60i_=1NASVQ-YKyzcHxkDxVw@mail.gmail.com> <alpine.DEB.2.00.1309111823370.12210@ps20323.dreamhostps.com> <CAOp6jLaxkdDE5qKaZmUxHs5Jic8h3yCnE+j7dCUgAHQWLQBiEg@mail.gmail.com> <alpine.DEB.2.00.1309121742300.12210@ps20323.dreamhostps.com> Message-ID: <CAOp6jLZUq1CnZcxnJ0GgK3UtSDE9OOiTNnT6bzQOVN=koHXtmA@mail.gmail.com> On Thu, Sep 12, 2013 at 10:42 AM, Ian Hickson <ian at hixie.ch> wrote: > On Thu, 12 Sep 2013, Robert O'Callahan wrote: > > On Wed, Sep 11, 2013 at 11:24 AM, Ian Hickson <ian at hixie.ch> wrote: > > > On Wed, 11 Sep 2013, Robert O'Callahan wrote: > > > > Pinch-zoom is hard because we don't want to trigger reflows or other > > > > expensive behavior on pinch-zoom. I'd leave pinch-zoom out of it for > > > > now. > > > > > > Unless I'm missing something fundamental, changing the pixel density > > > doesn't cause a layout, it's changing the width that causes a layout. > > > > Changing pixel density does cause a layout in Gecko. For example we > > round CSS border widths to a whole number of device pixels. (This > > ensures that when page zoom is applied, all borders with the same > > specified width are rendered with the same visual width.) On some > > platforms (Windows), changing pixel density affects text hinting which > > affects text layout. > > So how do you do pinch-zoom under the hood on mobile devices? > We don't change layout, we just rerender with transformed coordinates. This means that pinch-zoom can break apparent border-widths and you can get ugly hinting on platforms that use pinch-zoom and have fonts with aggressive hinting. We could continue to not change layout, and still change the pixel density of canvases during or after pinch-zoom. We could even change the pixel density of canvases inside scaling CSS transforms. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * From annevk at annevk.nl Fri Sep 13 04:15:22 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Fri, 13 Sep 2013 12:15:22 +0100 Subject: [whatwg] Fetch SVG images with No CORS tainted cross-origin In-Reply-To: <1B872A94-5E1E-4E5C-B42B-04B1D8AB9555@adobe.com> References: <A8E761CD-7DB9-4692-BBB3-9C9572B6C833@adobe.com> <CADnb78iGxPOhS+V0xB441s=mJmYbcq8-E8fLy=fgJy3STgfjMA@mail.gmail.com> <1B872A94-5E1E-4E5C-B42B-04B1D8AB9555@adobe.com> Message-ID: <CADnb78j8vOsF4eU4kPm60Db2vjz268dnOEkHOo3wCrOdjc6EUA@mail.gmail.com> On Fri, Sep 13, 2013 at 10:52 AM, Dirk Schulze <dschulze at adobe.com> wrote: > If Fetch is not just fetching external (as not in the current document) then we still need it for SVG. References within the same document must still work. Fragment identifiers are to be handled by SVG. Again, your "SVG fetch" wrapper could let through certain URLs and not others, but I'm not sure if the only difference is a fragment identifier if that would even go through Fetch. I kinda doubt it since Fetch is async and fragment handling is generally sync. (Good question to answer for https://github.com/slightlyoff/EventWorker/ though as that would make this difference observable.) >> Do scripts even execute >> in that context? How do you get blob URLs? > > In WebKit and Blink you can't execute any script anywhere in an SVG document. I am not sure about Gecko but this is the feedback I got. Maybe someone from Mozilla can answer this. You mean SVG image right? So how do you get a blob URL? >> I suppose we could have a mode for that in Fetch too, but it seems >> really SVG specific so I'm not sure that's warranted. > > Yes, it is quite SVG specific. I am fine with just dealing with it in SVG as long as possible. And I think it is not possible without changing the fetching on the requesters like <img>. (This is the case for CSS as well btw, which can reference SVG images - different topic.) Well, for HTML <img> it's not about fetching. It just has to say that when it gets SVG back, it sets the "locked down flag" or the "image flag" or uses SVG in "image mode" or however SVG decides to name that. > The second case would indeed need a flag like "locked down flag". This would just allow fetching of resources in the same document, dataURLs (with lock down for the content of dataURL) and possibly blob URLs. There's no such thing as fetching resources in the same document. > The requester needs to set this "lock down flag". So ideally it would be specified by the Fetch specification. Legacy fetching (used for image fetching) would set this flag by default. In this case no other specification but Fetch and CSS would need to change. No that's not how this flag works. The flag is for an SVG resource and when you interpret that resource and do SVG fetching it would come into effect. -- http://annevankesteren.nl/ From jirka at kosek.cz Fri Sep 13 04:31:07 2013 From: jirka at kosek.cz (Jirka Kosek) Date: Fri, 13 Sep 2013 13:31:07 +0200 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: <5232E4A7.5030203@w3.org> References: <CADnb78jksF5RdfPK4Brcib=N-jYcf0YrO=o=fFz4ZLUqTgLUMg@mail.gmail.com> <EE30D49E-FDB4-4BDA-AC0E-33B4E6B2C521@4d.com> <DE55B4C4-6983-44DD-8C44-5E552259D8A4@4d.com> <CADnb78jQQC3hdRFYfd5n05+VucVhsr9hYUn8OYM=kBGbPcdDJA@mail.gmail.com> <5232E4A7.5030203@w3.org> Message-ID: <5232F77B.4050908@kosek.cz> On 13.9.2013 12:10, Robin Berjon wrote: > I would rather we figured this out without <link>, but apart from the > indirection I reckon this approach has some nice properties and might > work if more direct ones don't. Also don't forget that while linking is the hardest part of this ZIP circus there is another missing piece -- normative definition of portable and RF subset of ZIP. SC34 started some initial work on such ZIP profile recently: http://www.itscj.ipsj.or.jp/sc34/open/1855.pdf So if some sort of ZIP packaging spec should to appear then it should reference such subset of ZIP not the full definition of ZIP format from PKWare. Jirka -- ------------------------------------------------------------------ Jirka Kosek e-mail: jirka at kosek.cz http://xmlguru.cz ------------------------------------------------------------------ Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing ------------------------------------------------------------------ OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep. ------------------------------------------------------------------ Bringing you XML Prague conference http://xmlprague.cz ------------------------------------------------------------------ From robin at w3.org Fri Sep 13 05:24:26 2013 From: robin at w3.org (Robin Berjon) Date: Fri, 13 Sep 2013 14:24:26 +0200 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: <5232F77B.4050908@kosek.cz> References: <CADnb78jksF5RdfPK4Brcib=N-jYcf0YrO=o=fFz4ZLUqTgLUMg@mail.gmail.com> <EE30D49E-FDB4-4BDA-AC0E-33B4E6B2C521@4d.com> <DE55B4C4-6983-44DD-8C44-5E552259D8A4@4d.com> <CADnb78jQQC3hdRFYfd5n05+VucVhsr9hYUn8OYM=kBGbPcdDJA@mail.gmail.com> <5232E4A7.5030203@w3.org> <5232F77B.4050908@kosek.cz> Message-ID: <523303FA.1070502@w3.org> On 13/09/2013 13:31 , Jirka Kosek wrote: > On 13.9.2013 12:10, Robin Berjon wrote: >> I would rather we figured this out without <link>, but apart from the >> indirection I reckon this approach has some nice properties and might >> work if more direct ones don't. > > Also don't forget that while linking is the hardest part of this ZIP > circus there is another missing piece -- normative definition of > portable and RF subset of ZIP. SC34 started some initial work on such > ZIP profile recently: > > http://www.itscj.ipsj.or.jp/sc34/open/1855.pdf > > So if some sort of ZIP packaging spec should to appear then it should > reference such subset of ZIP not the full definition of ZIP format from > PKWare. This has also been done, perhaps not to a sufficient extent, in Widgets: http://www.w3.org/TR/widgets/#zip-archive -- Robin Berjon - http://berjon.com/ - @robinberjon From annevk at annevk.nl Fri Sep 13 05:48:27 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Fri, 13 Sep 2013 13:48:27 +0100 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: <523303FA.1070502@w3.org> References: <CADnb78jksF5RdfPK4Brcib=N-jYcf0YrO=o=fFz4ZLUqTgLUMg@mail.gmail.com> <EE30D49E-FDB4-4BDA-AC0E-33B4E6B2C521@4d.com> <DE55B4C4-6983-44DD-8C44-5E552259D8A4@4d.com> <CADnb78jQQC3hdRFYfd5n05+VucVhsr9hYUn8OYM=kBGbPcdDJA@mail.gmail.com> <5232E4A7.5030203@w3.org> <5232F77B.4050908@kosek.cz> <523303FA.1070502@w3.org> Message-ID: <CADnb78jT-7D5e5ahh3BkbeOV5n51cVS5Hi5aqn8EhPq2NFZQiA@mail.gmail.com> On Fri, Sep 13, 2013 at 1:24 PM, Robin Berjon <robin at w3.org> wrote: > This has also been done, perhaps not to a sufficient extent, in Widgets: > > http://www.w3.org/TR/widgets/#zip-archive That looks like a mess. To be fair, for the format I don't have much more than http://wiki.whatwg.org/wiki/Zip#Format at the moment though http://fetch.spec.whatwg.org/#zip-archives has a description of the data model, including the extension to Content-Type mapping. I started up drafting the various URL tactics here: http://wiki.whatwg.org/wiki/Zip#URLs Still needs a bit more work. -- http://annevankesteren.nl/ From ian at hixie.ch Fri Sep 13 12:20:57 2013 From: ian at hixie.ch (Ian Hickson) Date: Fri, 13 Sep 2013 19:20:57 +0000 (UTC) Subject: [whatwg] Namespaces and tag names in the HTML parser In-Reply-To: <5C18C3E26A4A43DF8B35BC43F882E29F@PeterPC> References: <bug-21292-2495@http.www.w3.org/Bugs/Public/> <Pine.LNX.4.64.1305292028010.2932@ps20323.dreamhostps.com> <CABMdHiQM=iTmpQgLW0VHbjvDOMU20NFPRO56tMjw95xB_PhcKQ@mail.gmail.com> <Pine.LNX.4.64.1307012230180.11139@ps20323.dreamhostps.com> <101F8E57FFCE4F44BBB459F1F176A217@PeterPC> <alpine.DEB.2.00.1307312259550.9685@ps20323.dreamhostps.com> <5C18C3E26A4A43DF8B35BC43F882E29F@PeterPC> Message-ID: <alpine.DEB.2.00.1309131903580.12199@ps20323.dreamhostps.com> On Thu, 1 Aug 2013, Peter Occil wrote: > > Many of these cases occur in the normative portion of the tree > construction stage. Most of them involve checking whether an element > (as opposed to a tag token) has a certain name: > > Accordingly, these cases are ambiguous: > > * If foster parenting is enabled and target is a table, tbody, tfoot, > thead, or tr element > > * Let last template be the last template element in the stack of open > elements, if any. > > [...] > > * Pop elements from the stack of open elements until a template element > has been popped from the stack. > > * If there is a template element on the stack of open elements, ignore > the token. > > * If the second element on the stack of open elements is not a body > element, [...] or if there is a template element on the stack of open > elements, then ignore the token. All of these hyperlink to the definition of the element and that definition is of an element in the HTML namespace, as the spec says: # Except where otherwise stated, all elements defined or mentioned in this # specification are in the HTML namespace ("http://www.w3.org/1999/xhtml") : For example, button elements are elements with the element type button, : meaning they have the local name "button" and (implicitly as defined : above) the HTML namespace. Why do you think the cases above are ambigious, but the following, for instance, are not? # The section element represents a generic section of a document or # application. # If the target of the click event is an img element [...] # A form control is disabled if its disabled attribute is set, or if it is # a descendant of a fieldset element whose disabled attribute is set and # is not a descendant of that fieldset element's first legend element # child, if any. > Moreover, where needed, a shortcut is to use "an HTML so-and-so element" > rather than "a so-and-so element in the HTML namespace". (This can > apply similarly to SVG and MathML.) I don't understand why this is necessary. I think it would be misleading because it would make authors question why other parts of the spec don't specify the namespace. I've added a redundant note to the parser intro about this, but it's redundant -- it just references the terminology section and repeats the same point again. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Fri Sep 13 14:18:55 2013 From: ian at hixie.ch (Ian Hickson) Date: Fri, 13 Sep 2013 21:18:55 +0000 (UTC) Subject: [whatwg] Parse errors for invalid characters In-Reply-To: <522900C4.2050409@googlemail.com> References: <522900C4.2050409@googlemail.com> Message-ID: <alpine.DEB.2.00.1309131921540.12199@ps20323.dreamhostps.com> On Thu, 5 Sep 2013, Geoffrey Sneddon wrote: > > The phrasing content section states: > > > Text nodes and attribute values must consist of Unicode characters, > > must not contain U+0000 characters, must not contain permanently > > undefined Unicode characters (noncharacters), and must not contain > > control characters other than space characters. > > And the pre-processing the input-stream section states: > > > Any occurrences of any characters in the ranges U+0001 to U+0008, > > U+000E to U+001F, U+007F to U+009F, U+FDD0 to U+FDEF, and characters > > U+000B, U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, U+2FFFE, U+2FFFF, U+3FFFE, > > U+3FFFF, U+4FFFE, U+4FFFF, U+5FFFE, U+5FFFF, U+6FFFE, U+6FFFF, > > U+7FFFE, U+7FFFF, U+8FFFE, U+8FFFF, U+9FFFE, U+9FFFF, U+AFFFE, > > U+AFFFF, U+BFFFE, U+BFFFF, U+CFFFE, U+CFFFF, U+DFFFE, U+DFFFF, > > U+EFFFE, U+EFFFF, U+FFFFE, U+FFFFF, U+10FFFE, and U+10FFFF are parse > > errors. These are all control characters or permanently undefined > > Unicode characters (noncharacters). > > Note the first uses "Unicode characters", the second "characters" ? the > former excludes surrogates as a conformance requirement. > > Note that every disallowed non-surrogate character is a parse error. > > Therefore, it would make sense to make surrogates parse errors. Done. > It should be noted that they can only occur in the input stream if they > come from script (as they cannot be decoded from the input byte stream > as the decoders will never emit a surrogate). Done. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From rniwa at apple.com Fri Sep 13 14:27:02 2013 From: rniwa at apple.com (Ryosuke Niwa) Date: Fri, 13 Sep 2013 14:27:02 -0700 Subject: [whatwg] Why are we merging Document and HTMLDocument again? In-Reply-To: <CADnb78iH2J02uX7Winh=93BBNnovUXeo2T0Dfy_Q5aN0+x+o5w@mail.gmail.com> References: <51361FA0.8070101@mit.edu> <CADnb78gB=pdOGZ4tY09V-oANt4+KB-WgoDaEuoR1ibjq+N861g@mail.gmail.com> <51362266.7010804@mit.edu> <CADnb78j_ELAmskAB41-K_DTVbNWuPYfn-fa-VC-n2f=OtA0mQg@mail.gmail.com> <51362671.1010302@mit.edu> <Pine.LNX.4.64.1303052029350.15713@ps20323.dreamhostps.com> <5136589D.4040800@mit.edu> <CADnb78hWVVU1qjKU=mK5AXwwNUmsKHeNfD7HmY1OD2Rj+EXmxw@mail.gmail.com> <alpine.DEB.2.00.1307121752451.15729@ps20323.dreamhostps.com> <51E04531.4070801@mit.edu> <0ED2DF0C-C0AC-496C-8B8B-37FF90D0B436@apple.com> <alpine.DEB.2.00.1309121836290.12199@ps20323.dreamhostps.com> <1D191C36-CE39-4A1F-AF45-A75673C35EA1@apple.com> <alpine.DEB.2.00.1309122055280.12210@ps20323.dreamhostps.com> <3BD3DB4F-5409-4CC9-9310-2C7E90CBC37B@apple.com> <alpine.DEB.2.00.1309130409200.12210@ps20323.dreamhostps.com> <op.w3cac0spidj3kv@simons-macbook-pro.local> <CADnb78iH2J02uX7Winh=93BBNnovUXeo2T0Dfy_Q5aN0+x+o5w@mail.gmail.com> Message-ID: <61829834-0787-4AEB-A3B3-7D552543C32A@apple.com> On Sep 13, 2013, at 1:53 AM, Anne van Kesteren <annevk at annevk.nl> wrote: > On Fri, Sep 13, 2013 at 8:42 AM, Simon Pieters <simonp at opera.com> wrote: >> * XHR response (uses interface "Document" and is an "XML document", even for >> text/html if I read the spec correctly) > > I assumed :/ that HTML would do the marking. Let's consider this a bug. > > It's not entirely clear to me what the suggestion from Ryosuke is. Is > it to keep getters on HTMLDocument only and expose HTMLDocument only > in browsing contexts created from text/html resources? And use > Document everywhere else and have Document contain all the other > members including (former) SVGDocument members? That setup would make > sense to me anyway. My proposal something along that line. But HTMLDocument also has a bunch of other junk properties like embeds, plugins, scripts, compatMode, bgColor, fgColor, alinkColor, linkColor, vlinkColor, etc? We even have write() and writeln() there! I don?t want to start adding all these legacy methods elsewhere. - R. Niwa From glenn at zewt.org Sat Sep 14 08:36:28 2013 From: glenn at zewt.org (Glenn Maynard) Date: Sat, 14 Sep 2013 10:36:28 -0500 Subject: [whatwg] Forcing orientation in content In-Reply-To: <alpine.DEB.2.00.1309102107450.12199@ps20323.dreamhostps.com> References: <516F27BF.4060508@gmail.com> <alpine.DEB.2.00.1307121944480.15729@ps20323.dreamhostps.com> <420FE1A33AB14ACB9667D659D8F415D5@gmail.com> <op.wz8k70f4te2ec8@aimac> <alpine.DEB.2.00.1309102107450.12199@ps20323.dreamhostps.com> Message-ID: <CABirCh-6OO9qb6Kh=wLQhfmmci8t-FE=6uWN51446LQu5w4mBg@mail.gmail.com> On Tue, Sep 10, 2013 at 4:22 PM, Ian Hickson <ian at hixie.ch> wrote: > > In practice, game developers are rarely willing to spend the time to > > make their games work well in both portrait and landscape. > > That's certainly true, but the reality is that on the Web a web browser > window might be any number of dimensions, so that's a problem you have to > deal with regardless. > (I'm a little confused by this, since my next sentence was explaining how games can deal with this even if they don't spend the time to make it work well.) > > > In Firefox we have implemented the screen orientation spec > > https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html > > That is unfortuate. I don't think that API puts the user first. > This is window.resizeTo all over again, and pages would use it for the same reason: "our page looks best in 640x480" becomes "our page looks best in portrait". The results will be far worse: the user's device will be flipping back and forth between orientations as he browses from page to page. Even if the user is simply tapping browser back a few times, the button will move around between each press as each page in history picks its preferred orientation. Unless implementations deal with these issues somehow, this API looks catastrophically broken. It seems like somebody just took a native mobile orientation API and translated it to JavaScript, without thinking about the differences between task switching on mobile and navigating between web pages. -- Glenn Maynard From simonp at opera.com Sat Sep 14 11:28:07 2013 From: simonp at opera.com (Simon Pieters) Date: Sat, 14 Sep 2013 20:28:07 +0200 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: <5232E9CB.5010409@w3.org> References: <CADnb78jksF5RdfPK4Brcib=N-jYcf0YrO=o=fFz4ZLUqTgLUMg@mail.gmail.com> <CAJ5xic-npAJAhWV4sV7ut=5Vu3bTfuxfeXLtjtnvj9B6st8mAQ@mail.gmail.com> <CADnb78ieWieX_eZ44QB09tMW8_FP4YNFxCZNs4hgUrkd8drBGQ@mail.gmail.com> <op.w2kzr1yiidj3kv@simons-macbook-pro.local> <5232E9CB.5010409@w3.org> Message-ID: <op.w3eyw5scidj3kv@simons-macbook-pro.local> On Fri, 13 Sep 2013 12:32:43 +0200, Robin Berjon <robin at w3.org> wrote: > On 29/08/2013 15:58 , Simon Pieters wrote: >> On Thu, 29 Aug 2013 15:02:48 +0200, Anne van Kesteren <annevk at annevk.nl> >> wrote: >>> On Thu, Aug 29, 2013 at 1:19 PM, Jake Archibald >>> <jaffathecake at gmail.com> wrote: >>>> Causing a network error in existing browsers is a shame. >> >> It seems to fail to resolve in IE10. It works in >> Gecko/WebKit/Blink/Presto: the %! is requested literally. However, both >> Apache and IIS seems to return 400 Bad Request. > > That's not exactly promising. > >>> Picking something that could occur in paths seems problematic. >> >> I'm not sure why it's more problematic than something than could occur >> in the fragment. >> >> For instance, the string "$zip=" is not present at all in >> http://webdevdata.org/ data set 18/06/2013. So maybe we could use a >> string like that in the path and have a graceful fallback path in legacy >> browsers that work in existing servers. > > That's my preferred approach so far. However I wonder about the precise > details. > > Assuming <img src="/foo.zip/$zip=dahut.png"> I'm guessing that the > browser would actually just request "/foo.zip" from the server in the > same manner that fragments are stripped, right? "/foo.zip/", but yeah. > Somehow the stripping bothers me a bit; for instance, what would > Navigation Controller see? I'm not familiar with that. > I wonder if we couldn't just use the query part for this: <img > src="/foo.zip?!zip/dahut.png">. No stripping is needed (as far as I know > servers would normally just serve foo.zip in this case), which > simplifies the model. The query is sent to the server. What the server does with it depends on the server. Making different requests for /foo.zip?!zip/dahut.png and /foo.zip?!zip/lol.png is bad because we want the same response for UAs that support the feature, but caches wouldn't know that they're the same when they have different queries. -- Simon Pieters Opera Software From jstpierre at mecheye.net Sun Sep 15 08:38:19 2013 From: jstpierre at mecheye.net (Jasper St. Pierre) Date: Sun, 15 Sep 2013 11:38:19 -0400 Subject: [whatwg] Clipping text in in canvas Message-ID: <CAA0H+QTT47mzfyzjiRTS+A2W96THOHpLd8rGHzUW8DDb5Z=QGA@mail.gmail.com> The canvas specification maintains: These shapes are painted without affecting the current path, and are subject to shadow effects, global alpha, the clipping region, and global composition operators. [0] But no browsers I tested actually implement the "clipping region" part. Should this be removed for backwards compatibility reasons? Should we introduce a new method of clipping text be introduced, or should we just require users who want to draw clipped text to draw to a scratch canvas and use drawImage to copy the pixels? [0] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#drawing-text-to-the-bitmap -- Jasper From ddailey at zoominternet.net Sun Sep 15 09:04:09 2013 From: ddailey at zoominternet.net (David Dailey) Date: Sun, 15 Sep 2013 12:04:09 -0400 Subject: [whatwg] Clipping text in in canvas In-Reply-To: <CAA0H+QTT47mzfyzjiRTS+A2W96THOHpLd8rGHzUW8DDb5Z=QGA@mail.gmail.com> References: <CAA0H+QTT47mzfyzjiRTS+A2W96THOHpLd8rGHzUW8DDb5Z=QGA@mail.gmail.com> Message-ID: <000601ceb22d$36ae0610$a40a1230$@net> Last I checked applying a clipPath to text in SVG works consistently across browsers, and there it remains accessible: to screen readers, indexing, searching, drag-to-select, etc. Why would one want a bunch of pixels that resemble text? Just saying, David -----Original Message----- From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Jasper St. Pierre Sent: Sunday, September 15, 2013 11:38 AM To: whatwg at whatwg.org Subject: [whatwg] Clipping text in in canvas The canvas specification maintains: These shapes are painted without affecting the current path, and are subject to shadow effects, global alpha, the clipping region, and global composition operators. [0] But no browsers I tested actually implement the "clipping region" part. Should this be removed for backwards compatibility reasons? Should we introduce a new method of clipping text be introduced, or should we just require users who want to draw clipped text to draw to a scratch canvas and use drawImage to copy the pixels? [0] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-eleme nt.html#drawing-text-to-the-bitmap -- Jasper From jstpierre at mecheye.net Sun Sep 15 09:09:08 2013 From: jstpierre at mecheye.net (Jasper St. Pierre) Date: Sun, 15 Sep 2013 12:09:08 -0400 Subject: [whatwg] Clipping text in in canvas In-Reply-To: <000601ceb22d$36ae0610$a40a1230$@net> References: <CAA0H+QTT47mzfyzjiRTS+A2W96THOHpLd8rGHzUW8DDb5Z=QGA@mail.gmail.com> <000601ceb22d$36ae0610$a40a1230$@net> Message-ID: <CAA0H+QQbAPv2Si4DBEePJAmscQQxVMguHE4sQjbR5jB8kUUW4g@mail.gmail.com> On Sun, Sep 15, 2013 at 12:04 PM, David Dailey <ddailey at zoominternet.net>wrote: > Last I checked applying a clipPath to text in SVG works consistently across > browsers, and there it remains accessible: to screen readers, indexing, > searching, drag-to-select, etc. Why would one want a bunch of pixels that > resemble text? > > Just saying, > David > I have an insane, complex use case, and you'd laugh at me if I told you what it was, but trust me when I say I need an immediate mode drawing API like <canvas> instead of a retained scene graph like SVG. -----Original Message----- > From: whatwg-bounces at lists.whatwg.org > [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Jasper St. Pierre > Sent: Sunday, September 15, 2013 11:38 AM > To: whatwg at whatwg.org > Subject: [whatwg] Clipping text in in canvas > > The canvas specification maintains: > > These shapes are painted without affecting the current path, and are > subject to shadow effects, global alpha, the clipping region, and global > composition operators. [0] > > But no browsers I tested actually implement the "clipping region" part. > Should this be removed for backwards compatibility reasons? Should we > introduce a new method of clipping text be introduced, or should we just > require users who want to draw clipped text to draw to a scratch canvas and > use drawImage to copy the pixels? > [0] > > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-eleme > nt.html#drawing-text-to-the-bitmap > > -- > Jasper > > > -- Jasper From ddailey at zoominternet.net Sun Sep 15 09:19:25 2013 From: ddailey at zoominternet.net (David Dailey) Date: Sun, 15 Sep 2013 12:19:25 -0400 Subject: [whatwg] Clipping text in in canvas In-Reply-To: <CAA0H+QQbAPv2Si4DBEePJAmscQQxVMguHE4sQjbR5jB8kUUW4g@mail.gmail.com> References: <CAA0H+QTT47mzfyzjiRTS+A2W96THOHpLd8rGHzUW8DDb5Z=QGA@mail.gmail.com> <000601ceb22d$36ae0610$a40a1230$@net> <CAA0H+QQbAPv2Si4DBEePJAmscQQxVMguHE4sQjbR5jB8kUUW4g@mail.gmail.com> Message-ID: <000a01ceb22f$58516760$08f43620$@net> I'm sure there are such uses and I'm assured that you have one. I was just sending out my canned reminder that alternatives to canvas exist (many folks seemed not to know that, only a few years ago). Cheers and regards D From: magcius at gmail.com [mailto:magcius at gmail.com] On Behalf Of Jasper St. Pierre Sent: Sunday, September 15, 2013 12:09 PM To: David Dailey Cc: whatwg at whatwg.org Subject: Re: [whatwg] Clipping text in in canvas On Sun, Sep 15, 2013 at 12:04 PM, David Dailey <ddailey at zoominternet.net> wrote: Last I checked applying a clipPath to text in SVG works consistently across browsers, and there it remains accessible: to screen readers, indexing, searching, drag-to-select, etc. Why would one want a bunch of pixels that resemble text? Just saying, David I have an insane, complex use case, and you'd laugh at me if I told you what it was, but trust me when I say I need an immediate mode drawing API like <canvas> instead of a retained scene graph like SVG. -----Original Message----- From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Jasper St. Pierre Sent: Sunday, September 15, 2013 11:38 AM To: whatwg at whatwg.org Subject: [whatwg] Clipping text in in canvas The canvas specification maintains: These shapes are painted without affecting the current path, and are subject to shadow effects, global alpha, the clipping region, and global composition operators. [0] But no browsers I tested actually implement the "clipping region" part. Should this be removed for backwards compatibility reasons? Should we introduce a new method of clipping text be introduced, or should we just require users who want to draw clipped text to draw to a scratch canvas and use drawImage to copy the pixels? [0] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-eleme <http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-elem ent.html#drawing-text-to-the-bitmap> nt.html#drawing-text-to-the-bitmap -- Jasper -- Jasper From cabanier at gmail.com Sun Sep 15 17:05:52 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Sun, 15 Sep 2013 17:05:52 -0700 Subject: [whatwg] Clipping text in in canvas In-Reply-To: <CAA0H+QTT47mzfyzjiRTS+A2W96THOHpLd8rGHzUW8DDb5Z=QGA@mail.gmail.com> References: <CAA0H+QTT47mzfyzjiRTS+A2W96THOHpLd8rGHzUW8DDb5Z=QGA@mail.gmail.com> Message-ID: <CAGN7qDAnndDR038gy0BmrRwdEy4BvYOti5AOBmMdmyoj7GG7aA@mail.gmail.com> I think that by 'clipping region', the spec means the 'region that is not clipped'. You can clip anything (including text) in canvas. ie http://jsfiddle.net/6eGxU/23/ On Sun, Sep 15, 2013 at 8:38 AM, Jasper St. Pierre <jstpierre at mecheye.net>wrote: > The canvas specification maintains: > > These shapes are painted without affecting the current path, and are > subject to shadow effects, global alpha, the clipping region, and global > composition operators. [0] > > But no browsers I tested actually implement the "clipping region" part. > Should this be removed for backwards compatibility reasons? Should we > introduce a new method of clipping text be introduced, or should we just > require users who want to draw clipped text to draw to a scratch canvas and > use drawImage to copy the pixels? > [0] > > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#drawing-text-to-the-bitmap > > -- > Jasper > From julian.reschke at gmx.de Mon Sep 16 00:09:35 2013 From: julian.reschke at gmx.de (Julian Reschke) Date: Mon, 16 Sep 2013 09:09:35 +0200 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: <5232E9CB.5010409@w3.org> References: <CADnb78jksF5RdfPK4Brcib=N-jYcf0YrO=o=fFz4ZLUqTgLUMg@mail.gmail.com> <CAJ5xic-npAJAhWV4sV7ut=5Vu3bTfuxfeXLtjtnvj9B6st8mAQ@mail.gmail.com> <CADnb78ieWieX_eZ44QB09tMW8_FP4YNFxCZNs4hgUrkd8drBGQ@mail.gmail.com> <op.w2kzr1yiidj3kv@simons-macbook-pro.local> <5232E9CB.5010409@w3.org> Message-ID: <5236AEAF.4040305@gmx.de> On 2013-09-13 12:32, Robin Berjon wrote: > On 29/08/2013 15:58 , Simon Pieters wrote: >> On Thu, 29 Aug 2013 15:02:48 +0200, Anne van Kesteren <annevk at annevk.nl> >> wrote: >>> On Thu, Aug 29, 2013 at 1:19 PM, Jake Archibald >>> <jaffathecake at gmail.com> wrote: >>>> Causing a network error in existing browsers is a shame. >> >> It seems to fail to resolve in IE10. It works in >> Gecko/WebKit/Blink/Presto: the %! is requested literally. However, both >> Apache and IIS seems to return 400 Bad Request. > > That's not exactly promising. > ... Because it's an invalid URI. "%" needs to be percent-escaped. Best regards, Julian From annevk at annevk.nl Mon Sep 16 00:26:01 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Mon, 16 Sep 2013 08:26:01 +0100 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: <5236AEAF.4040305@gmx.de> References: <CADnb78jksF5RdfPK4Brcib=N-jYcf0YrO=o=fFz4ZLUqTgLUMg@mail.gmail.com> <CAJ5xic-npAJAhWV4sV7ut=5Vu3bTfuxfeXLtjtnvj9B6st8mAQ@mail.gmail.com> <CADnb78ieWieX_eZ44QB09tMW8_FP4YNFxCZNs4hgUrkd8drBGQ@mail.gmail.com> <op.w2kzr1yiidj3kv@simons-macbook-pro.local> <5232E9CB.5010409@w3.org> <5236AEAF.4040305@gmx.de> Message-ID: <CADnb78gwtKakXPTcEwDd1sO_YtqN3hGsDqVq_nvH4OHjBeVA0A@mail.gmail.com> On Mon, Sep 16, 2013 at 8:09 AM, Julian Reschke <julian.reschke at gmx.de> wrote: > Because it's an invalid URI. "%" needs to be percent-escaped. That was the whole point of that particular proposal. It seems something like $zip= might be better though it wouldn't be fully backwards compatible with all valid data URLs to date... -- http://annevankesteren.nl/ From junov at google.com Mon Sep 16 08:25:45 2013 From: junov at google.com (Justin Novosad) Date: Mon, 16 Sep 2013 11:25:45 -0400 Subject: [whatwg] Clipping text in in canvas In-Reply-To: <CAA0H+QTT47mzfyzjiRTS+A2W96THOHpLd8rGHzUW8DDb5Z=QGA@mail.gmail.com> References: <CAA0H+QTT47mzfyzjiRTS+A2W96THOHpLd8rGHzUW8DDb5Z=QGA@mail.gmail.com> Message-ID: <CABpaAqSJkr6z_xZ2VQn6k7KCJox0+iSiq3tLz5S3F=m3jnnTQA@mail.gmail.com> On Sun, Sep 15, 2013 at 11:38 AM, Jasper St. Pierre <jstpierre at mecheye.net>wrote: > But no browsers I tested actually implement the "clipping region" part. > That is weird because all the browsers I tested do implement it. Perhaps something is unclear? What do *you* think that part of the spec means? As far as I am concerned, the fact that the term "clipping region" is a hyperlink to the definition of the 2d canvas clip() method makes it clear enough to me. But maybe my reading is biased because I am already familiar with the feature. Please let us know if you think any of it is ambiguous or confusing. Did you think this had something to do with CSS clipping? -Justin From ian at hixie.ch Mon Sep 16 10:35:28 2013 From: ian at hixie.ch (Ian Hickson) Date: Mon, 16 Sep 2013 17:35:28 +0000 (UTC) Subject: [whatwg] Form-associated elements and the parser In-Reply-To: <CAEvLGcKMnO3L2vnscVCYJppqtstQQx1B78cbDKAEZcXTMrSdog@mail.gmail.com> References: <CAEvLGcJMUTFVcjzfKRALvZYqt2HDAtznbWmOZQ_Ecs_kHkOc=g@mail.gmail.com> <CA+c2ei_GsNi=Mv-b8m8+5h1ggWNLdpB4eKCezyqFqkmkpB1iiQ@mail.gmail.com> <CAEvLGcJVS5CAp=DS6Q8cyN59vNLE0d2dcknLacv21LkRUrJiyA@mail.gmail.com> <CA+c2ei8M99CYRbXUdYDwk3TXR6JafZwb1JyoQEzqpbSzQ2RvjQ@mail.gmail.com> <CAEvLGcKMnO3L2vnscVCYJppqtstQQx1B78cbDKAEZcXTMrSdog@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309132241120.12199@ps20323.dreamhostps.com> On Tue, 6 Aug 2013, Adam Klein wrote: > > Hixie opened my eyes last week to parser-association behavior of the > sort found at > http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2428. > > In that case, an <input> in a detached tree is associated with a <form> > in the main document. This causes badness in WebKit and Blink because > the association between the <form> and the <input> (e.g., as exposed in > the HTMLFormElement.elements collection) is only weakly held to avoid > reference loops (and thus memory leaks). And that weakness occasionally > results in crashes when one of these objects is collected before the > other. > > While all modern HTML parser implementations I tested seemed to agree on > their treatment of the above example (they all return "1" as > elements.length), this feature doesn't strike me as terribly useful. And > for what it's worth, it doesn't seem to be present in legacy IE. > > I'm interested what others would think about changing the parser to only > associate a <form> with an <input> if both are in the same "home > subtree" Or is there some deep web-compat reason for this parsing > oddity? On Tue, 6 Aug 2013, Jonas Sicking wrote: > > Sure, as long as you come up with a formalized algorithm for when there > is an association and when there isn't. Keep in mind that by the time > that the input-element is inserted, the form-element might have been > moved elsewhere. We likely don't need the association in that case, but > detecting that that has happened sounds tricky. On Tue, 6 Aug 2013, Adam Klein wrote: > > My concrete proposal would be something like this: > > In step 4 of [create an element for the token], add a requirement that > "intended parent" and the "form element pointer" be part of the same > "home subtree" [...] I think this works... there's some dodginess around how elements are inserted in the AAA, but I think it works there as well. (The 'reset the form owner' algorithm can't associate cross-subtree; only the parser can do this. So it's just the parser that needs fixing.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Mon Sep 16 10:40:22 2013 From: ian at hixie.ch (Ian Hickson) Date: Mon, 16 Sep 2013 17:40:22 +0000 (UTC) Subject: [whatwg] Clipping text in in canvas In-Reply-To: <CAA0H+QTT47mzfyzjiRTS+A2W96THOHpLd8rGHzUW8DDb5Z=QGA@mail.gmail.com> References: <CAA0H+QTT47mzfyzjiRTS+A2W96THOHpLd8rGHzUW8DDb5Z=QGA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309161739360.12210@ps20323.dreamhostps.com> On Sun, 15 Sep 2013, Jasper St. Pierre wrote: > > The canvas specification maintains: > > These shapes are painted without affecting the current path, and are > subject to shadow effects, global alpha, the clipping region, and global > composition operators. [0] > > But no browsers I tested actually implement the "clipping region" part. > Should this be removed for backwards compatibility reasons? Should we > introduce a new method of clipping text be introduced, or should we just > require users who want to draw clipped text to draw to a scratch canvas > and use drawImage to copy the pixels? [0] > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#drawing-text-to-the-bitmap Do you have a test case demonstrating the problem you describe? (Note that browsers not following the spec is usually not resolved by adding another feature that does the same thing, since there's no reason to believe they're any more likely to follow that spec either.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jstpierre at mecheye.net Mon Sep 16 11:03:59 2013 From: jstpierre at mecheye.net (Jasper St. Pierre) Date: Mon, 16 Sep 2013 14:03:59 -0400 Subject: [whatwg] Clipping text in in canvas In-Reply-To: <alpine.DEB.2.00.1309161739360.12210@ps20323.dreamhostps.com> References: <CAA0H+QTT47mzfyzjiRTS+A2W96THOHpLd8rGHzUW8DDb5Z=QGA@mail.gmail.com> <alpine.DEB.2.00.1309161739360.12210@ps20323.dreamhostps.com> Message-ID: <CAA0H+QR4mLj3uoauifgKnELp0d-BDh9AWZP2B_fKGPno7R3ZOQ@mail.gmail.com> Sorry for the noise, my code just had a bug (surprise, surprise). It was significantly more complicated than this, but the core of the bug was: ctx.save(); ctx.rect(0, 0, 100, 100); ctx.fill(); ctx.restore(); ctx.save(); ctx.rect(30, 0, 100, 100); ctx.clip(); ctx.fillText(); ctx.restore(); But I forgot to reset the path before the clip(), meaning that the clip did nothing at all. A lack of standard test cases for <canvas> clipping behavior, a StackOverflow answer [0], and no way to reliably debug this sort of issue (I couldn't find any way to get or dump the current path on the context) made me think that the browser behavior was incompatible with the spec. As penance, I'll find some time today to contribute some tests to the <canvas> test suite. [0] http://stackoverflow.com/questions/7307430/html-canvas-clipping-and-text On Mon, Sep 16, 2013 at 1:40 PM, Ian Hickson <ian at hixie.ch> wrote: > On Sun, 15 Sep 2013, Jasper St. Pierre wrote: > > > > The canvas specification maintains: > > > > These shapes are painted without affecting the current path, and are > > subject to shadow effects, global alpha, the clipping region, and global > > composition operators. [0] > > > > But no browsers I tested actually implement the "clipping region" part. > > Should this be removed for backwards compatibility reasons? Should we > > introduce a new method of clipping text be introduced, or should we just > > require users who want to draw clipped text to draw to a scratch canvas > > and use drawImage to copy the pixels? [0] > > > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#drawing-text-to-the-bitmap > > Do you have a test case demonstrating the problem you describe? > > (Note that browsers not following the spec is usually not resolved by > adding another feature that does the same thing, since there's no reason > to believe they're any more likely to follow that spec either.) > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > -- Jasper From ian at hixie.ch Mon Sep 16 15:03:20 2013 From: ian at hixie.ch (Ian Hickson) Date: Mon, 16 Sep 2013 22:03:20 +0000 (UTC) Subject: [whatwg] HTML: A DOM attribute that returns the language of a node In-Reply-To: <907E9FE4-CD47-4C12-B563-3F0AB7EC2118@apple.com> References: <2316EE6495904AB79C77E28AC9B9ADC7@PeterPC> <alpine.DEB.2.00.1307121947450.15729@ps20323.dreamhostps.com> <771E4287303644F88F4C46B69DE613B8@PeterPC> <alpine.DEB.2.00.1307131538570.31051@ps20323.dreamhostps.com> <CADP2=hpPxR+tmbpuYPfNZLLucPY1Jmz1z2CepEPdzuWm+pzrpQ@mail.gmail.com> <alpine.DEB.2.00.1307161824330.31051@ps20323.dreamhostps.com> <56BE589E-9F87-4877-BA60-7410CD6B9FA6@apple.com> <alpine.DEB.2.00.1307261816520.27623@ps20323.dreamhostps.com> <907E9FE4-CD47-4C12-B563-3F0AB7EC2118@apple.com> Message-ID: <alpine.DEB.2.00.1309162159380.12199@ps20323.dreamhostps.com> On Thu, 1 Aug 2013, Ryosuke Niwa wrote: > > > > Are you saying that for HTML contenteditable-based editors that want > > to support drag-and-drop editing, they need to be able to annotate the > > outgoing HTML fragment with the effective language so that when it's > > embedded somewhere, the right fonts get used? > > Yes, but not just for drag and drop. Sure, also for copy-and-paste, etc. The point is that browsers need to provide this for at least some of the cases. > > This seems like something that browsers should just do automatically > > for copy-and-paste and drag-and-drop, I wouldn't want to require that > > every contenteditable-based editor have to reimplement this. That > > seems like a lot of redundant work, and in particular, seems to be > > work that most editor implementors would forget. If the browsers just > > did the annotation automatically, then this would work even in editors > > whose implementors didn't worry about i18n. > > How are browsers supposed to do this if the author was simply using > innerHTML? How would an author use innerHTML here? I agree that there's a use case for providing language information, my point is just that this use case seems to need more than just that: it also needs that browsers add language annotations during drag-and-drop and copy-and-paste, at least. Is there anything else that it needs? Will putting language information on drag-and-drop or copy/paste content have any Web compat impact? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Mon Sep 16 15:05:48 2013 From: ian at hixie.ch (Ian Hickson) Date: Mon, 16 Sep 2013 22:05:48 +0000 (UTC) Subject: [whatwg] HTML: A DOM attribute that returns the language of a node In-Reply-To: <51FBAFDE.3070102@cs.tut.fi> References: <2316EE6495904AB79C77E28AC9B9ADC7@PeterPC> <alpine.DEB.2.00.1307121947450.15729@ps20323.dreamhostps.com> <771E4287303644F88F4C46B69DE613B8@PeterPC> <alpine.DEB.2.00.1307131538570.31051@ps20323.dreamhostps.com> <CADP2=hpPxR+tmbpuYPfNZLLucPY1Jmz1z2CepEPdzuWm+pzrpQ@mail.gmail.com> <alpine.DEB.2.00.1307161824330.31051@ps20323.dreamhostps.com> <56BE589E-9F87-4877-BA60-7410CD6B9FA6@apple.com> <alpine.DEB.2.00.1307261816520.27623@ps20323.dreamhostps.com> <907E9FE4-CD47-4C12-B563-3F0AB7EC2118@apple.com> <51FBAFDE.3070102@cs.tut.fi> Message-ID: <alpine.DEB.2.00.1309162203330.12199@ps20323.dreamhostps.com> On Fri, 2 Aug 2013, Jukka K. Korpela wrote: > 2013-08-02 2:43, Ryosuke Niwa wrote: > > > > > > Are you saying that for HTML contenteditable-based editors that want > > > to support drag-and-drop editing, they need to be able to annotate > > > the outgoing HTML fragment with the effective language so that when > > > it's embedded somewhere, the right fonts get used? > > > > Yes, but not just for drag and drop. > > This would mean that the editor would have to guess the language from > the text or ask the user to specify it. Well presumably just getting the language out of the document would be a good first step. > This is not as unrealistic as it may first seem. Microsoft Word does > such things [...] Sure, there's plenty of examples of language identification. > But regarding the effect of language markup on fonts, the effect is > limited to situations where the font is not specified in a style sheet. Yes. That's a case we should probably make sure we handle. > So it could be added, well, just because there is no good reason not to. There's always reasons not to add something: http://wiki.whatwg.org/wiki/FAQ#Where.27s_the_harm_in_adding.E2.80.94 -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From poccil14 at gmail.com Mon Sep 16 17:38:47 2013 From: poccil14 at gmail.com (Peter Occil) Date: Mon, 16 Sep 2013 20:38:47 -0400 Subject: [whatwg] HTML: A DOM attribute that returns the language of a node In-Reply-To: <alpine.DEB.2.00.1309162203330.12199@ps20323.dreamhostps.com> References: <2316EE6495904AB79C77E28AC9B9ADC7@PeterPC><alpine.DEB.2.00.1307121947450.15729@ps20323.dreamhostps.com><771E4287303644F88F4C46B69DE613B8@PeterPC><alpine.DEB.2.00.1307131538570.31051@ps20323.dreamhostps.com><CADP2=hpPxR+tmbpuYPfNZLLucPY1Jmz1z2CepEPdzuWm+pzrpQ@mail.gmail.com><alpine.DEB.2.00.1307161824330.31051@ps20323.dreamhostps.com><56BE589E-9F87-4877-BA60-7410CD6B9FA6@apple.com><alpine.DEB.2.00.1307261816520.27623@ps20323.dreamhostps.com><907E9FE4-CD47-4C12-B563-3F0AB7EC2118@apple.com><51FBAFDE.3070102@cs.tut.fi> <alpine.DEB.2.00.1309162203330.12199@ps20323.dreamhostps.com> Message-ID: <85C7E940207C4AF192E032DB0C4EB48A@PeterPC> Apparently, the use cases I mentioned before have not been discussed yet: " - Localization of form controls in languages where browser support is lacking, such as some minor languages. - Localization of HTML elements, especially date formatting of span and div elements in the page's default language, see especially [1]. " You said these use cases were valid; how do you think so? --Peter [1]: http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#input-impl-notes -----Original Message----- From: Ian Hickson Sent: Monday, September 16, 2013 6:05 PM To: Jukka K. Korpela Cc: whatwg at lists.whatwg.org Subject: Re: [whatwg] HTML: A DOM attribute that returns the language of a node On Fri, 2 Aug 2013, Jukka K. Korpela wrote: > 2013-08-02 2:43, Ryosuke Niwa wrote: > > > > > > Are you saying that for HTML contenteditable-based editors that want > > > to support drag-and-drop editing, they need to be able to annotate > > > the outgoing HTML fragment with the effective language so that when > > > it's embedded somewhere, the right fonts get used? > > > > Yes, but not just for drag and drop. > > This would mean that the editor would have to guess the language from > the text or ask the user to specify it. Well presumably just getting the language out of the document would be a good first step. > This is not as unrealistic as it may first seem. Microsoft Word does > such things [...] Sure, there's plenty of examples of language identification. > But regarding the effect of language markup on fonts, the effect is > limited to situations where the font is not specified in a style sheet. Yes. That's a case we should probably make sure we handle. > So it could be added, well, just because there is no good reason not to. There's always reasons not to add something: http://wiki.whatwg.org/wiki/FAQ#Where.27s_the_harm_in_adding.E2.80.94 -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Mon Sep 16 17:43:20 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 17 Sep 2013 00:43:20 +0000 (UTC) Subject: [whatwg] inputmode feedback In-Reply-To: <83D6DB4D-DC3B-483D-9FD9-62D182D20F1A@apple.com> References: <511BE988.7070208@lamouri.fr> <5130C9A1.2020200@lamouri.fr> <Pine.LNX.4.64.1306062055150.2772@ps20323.dreamhostps.com> <CA+c2ei_fzXqAs1=mCpiwn+A0+yEvRjf5d9iLFFbVzFQgBaEQiw@mail.gmail.com> <CADP2=hrO1+5n9+M134n+GtAh=w32V0HpDM+wjrrGe=arzP+WDQ@mail.gmail.com> <CAAEV3pkY9CuVebq8HdqYWXB_qY=19RMoeXNfdw7Pv0NTmCYUog@mail.gmail.com> <83D6DB4D-DC3B-483D-9FD9-62D182D20F1A@apple.com> Message-ID: <alpine.DEB.2.00.1309170032060.12199@ps20323.dreamhostps.com> On Tue, 13 Aug 2013, Yoichi Osato wrote: > > I have questions about some inputmode attributes. > In the desktop case, full-width-latin, kana and katakana look to intend > user local IME. Right? I'm not sure what this means exactly. > I think whether IME is on or off is very important to user because some > IME have state and show some window to input character. It is much > different from alphabetic direct keyboard input. See > https://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html#composer-section > At least Chinese and Korean IME have state. inputmode="" isn't intended to directly decide how the UI works, e.g. whether an IME, or what kind of IME, is provided. However, it is intended to let browsers make the decision on what kind of IME to provide. > In this point we should add attributes corresponding to chinese and korean. > I don't know whether there are any other such a IME but I think many non > English native people input in alphabet or hir/her native language. I would be very happy to add such things, but I don't know what the needs are in those languages. I've been waiting for someone to elaborate on what exactly is needed. > So should we add "native" attribute? When would you use it? On Tue, 13 Aug 2013, Ryosuke Niwa wrote: > > I think we need to separate the use case for controlling IME mode and > hinting UA as to which type of text/script will be entered as Mounir > suggested in the original email. I don't understand what the difference is. > And I agree that we need to address Chinese and Korean IME use cases if > we're adding Japanese IME use cases. Also, IME behavior is very > different depending on whether you're using pinyin or zhuyin/bopomofo in > Chinese IME so we might need to differentiate those two as well. Ok. What are the kinds of input tha Chinese and Korean Web sites need? > On Mar 1, 2013, at 7:30 AM, Mounir Lamouri <mounir at lamouri.fr> wrote: > > On 15/02/13 08:28, Takayoshi Kochi (?? ??) wrote: > >> That said, even though authors of web apps may want to force the IME > >> mode or its script mode for user's sake, it may cause user's > >> confusion as they are so accustomed to change mode manually where > >> such mode is required. So if a web app sets some mode, the user may > >> toggle it back to unintended mode and get frustrated. > > > > I tend to agree. In one hand, I believe that users might get irritated > > if they can't control the inputmode but in another hand, forcing it > > might fulfil use cases where authors use Javascript to force a user to > > type in uppercase for example (that happens in a few forms). > > On the other hand, inputmode is supposedly only a hint, right? It > doesn't affect the validation state of input elements. Given that, how > does it address such a use case? I don't understand the concern here. The attribute is indeed a hint; it doesn't tell the browser what UI to show, only what the page thinks the user will want to enter. > > On 21/02/13 01:14, Ryosuke Niwa wrote: > >> On Wed, Feb 13, 2013 at 11:29 AM, Mounir Lamouri <mounir at lamouri.fr> > >> wrote: > >>> To conclude, Mozilla is interested in implementing this set of > >>> keywords: verbatim, text, name, prose and digit (or numeric). > >> > >> Why is name not an input type? > >> > >> How does one decide whether a given semantics should be introduced as > >> a type or a mode? > > > > I tend to prefer <input type='text' inputmode='name'> over <input > > type='name'> because <input type='name'>, for the moment would be > > nothing else but a text field with an address book autocompletion. I > > would prefer to have 'tel' that way instead of having it a type FWIW. > > But isn't type=email also a text field with autocompletion, no? I agree > that the UI might be similar on desktop browsers, but it could be > completely different on mobile operating systems where UA could show a > custom keyboard suitable to type in human names as opposed to arbitrary > text. > > How is that different from type=email where UA is supposed to assist > user type in an email address? Yeah, I don't really understand the suggestion above. > It's not like we do a rigorous pattern matching to validate email > addresses either. Actually, we do, or at least the spec does. -- Ian Hickson U+1047E )?._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. ? _? ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Mon Sep 16 17:50:33 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 17 Sep 2013 00:50:33 +0000 (UTC) Subject: [whatwg] HTML: A DOM attribute that returns the language of a node In-Reply-To: <85C7E940207C4AF192E032DB0C4EB48A@PeterPC> References: <2316EE6495904AB79C77E28AC9B9ADC7@PeterPC><alpine.DEB.2.00.1307121947450.15729@ps20323.dreamhostps.com><771E4287303644F88F4C46B69DE613B8@PeterPC><alpine.DEB.2.00.1307131538570.31051@ps20323.dreamhostps.com><CADP2=hpPxR+tmbpuYPfNZLLucPY1Jmz1z2CepEPdzuWm+pzrpQ@mail.gmail.com><alpine.DEB.2.00.1307161824330.31051@ps20323.dreamhostps.com><56BE589E-9F87-4877-BA60-7410CD6B9FA6@apple.com><alpine.DEB.2.00.1307261816520.27623@ps20323.dreamhostps.com><907E9FE4-CD47-4C12-B563-3F0AB7EC2118@apple.com><51FBAFDE.3070102@cs.tut.fi> <alpine.DEB.2.00.1309162203330.12199@ps20323.dreamhostps.com> <85C7E940207C4AF192E032DB0C4EB48A@PeterPC> Message-ID: <alpine.DEB.2.00.1309170046250.12210@ps20323.dreamhostps.com> On Mon, 16 Sep 2013, Peter Occil wrote: > > - Localization of form controls in languages where browser support is > lacking, such as some minor languages. > > - Localization of HTML elements, especially date formatting of span and > div elements in the page's default language [...] > > You said these use cases were valid; how do you think so? I mean these are things that users want and that authors have to do. Your e-mail is still on my list of e-mails to deal with. (Specifically, it's in the pile of e-mail relating to new features.) It hasn't been forgotten, don't worry. :-) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 17 10:06:32 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 17 Sep 2013 17:06:32 +0000 (UTC) Subject: [whatwg] Canvas - Should setLineDash be a nullable sequence? In-Reply-To: <CAA5isUZHQQ+zf2CzNOG6NL96c-RkiqF_z0aFjx82_Lh=Xb0hhg@mail.gmail.com> References: <CAA5isUZHQQ+zf2CzNOG6NL96c-RkiqF_z0aFjx82_Lh=Xb0hhg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309171657450.12199@ps20323.dreamhostps.com> On Tue, 20 Aug 2013, Simon Sarris wrote: > > This is minor, but it did recently break formerly-working functionality > in Google Chrome, so maybe its worth a discussion. > > The specification reads: > > void setLineDash(sequence<unrestricted double> segments); // default empty > sequence<unrestricted double> getLineDash(); > > This means we *cannot* use: > > ctx.setLineDash(null); > > In Chrome 28 and previous (for at least 6 months) null was an allowed > value, but in Chrome 30 (at least) it switched to throwing a TypeError. I couldn't find any currently-shipping browsers that supported this, so it seems unlikely that there'd be much legacy content that depends on it. (Not saying there's none, just that it's limited in scope.) Thus, the compatibility issue here is not the only thing we should consider. (It's still a factor, just not an automatic win, as it might otherwise be.) There's certainly an advantage to failing if the input is "null" here -- it's more likely to catch underlying errors quicker. Instead of just getting a solid line where you expected a dashed one, you get an error with a precise line number from which to start your search. > In any case, I think it would be better if setLineDash was defined in > the spec as a nullable sequence, so that when setting it back to nothing > to return to normal not-dashed path stroking (which could happen > thousands of times in a an animation frame) less stuff gets allocated in > the draw loop. A literal empty array can get optimised out by compilers, so it really shouldn't be that big a deal on the long run. > I think part of the issue is that setLineDash does two things. It sets > the dashing properties, but it also acts as the only way to > enable/disable dashing, I think that null seems appropriate. All lines are dashed, it's just that some have an infinitely long dash with no space. Don't look at it as enabling/disabling dashing. :-) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 17 10:20:38 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 17 Sep 2013 17:20:38 +0000 (UTC) Subject: [whatwg] Path API feedback In-Reply-To: <CAGN7qDDXqyZt2gkmttoUps3qgEUiesBdpGmhotUhk4Ay6S_PVQ@mail.gmail.com> References: <CAGN7qDATVtL08NLKvYsL+WVzGYn5fy3WxdQLQYqpB55NuhyL3g@mail.gmail.com> <Pine.LNX.4.64.1304260027360.3512@ps20323.dreamhostps.com> <CAGN7qDBcC7aPD1BcuDHbvMavfM3ez0CufFWgaLHcaPHBsuoNrA@mail.gmail.com> <alpine.DEB.2.00.1308202232540.27209@ps20323.dreamhostps.com> <CAGN7qDDXqyZt2gkmttoUps3qgEUiesBdpGmhotUhk4Ay6S_PVQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309171709350.12199@ps20323.dreamhostps.com> On Tue, 20 Aug 2013, Rik Cabanier wrote: > > On Sat, 23 Mar 2013, Rik Cabanier wrote: > > > > > > The current path APIs suffer from conflating path segments and > > > geometry. To fix this, I proposed to modify the API so path just > > > describe the path segments. > > > > > > http://blogs.adobe.com/webplatform/2013/01/31/revised-canvas-paths/ > > > > I disagree with the premise of this post -- it's not the case that you > > never want to add segments. It is in fact quite common to add segments > > to a path -- that's what constructing a path is. > > I disagree. How many times does an author want to add segments to an > existing path? Pretty much every time they create a path with more than one segment. > Let's say an application stores a circle in a path and now want to draw > a rectangle too. You propose that the application just appends the > rectangle. No, not necessarily. It depends on what they want to do. If they want a single path that is constructed of a circle and a rectangle in the same way that it would be if they did: x.beginPath(); x.arc(...); x.rect(...); x.fill(); ...then yeah, they should just append the rectangle. But if they want the same effect as: x.beginPath(); x.arc(); x.fill(); x.rect(...); x.fill(); ...then they should not just append them, since as you say, it won't work. > > Also, it's not at all clear to me that there's really a distinction > > between a "shape" and a "path". They're really the same thing -- sets > > of path segments. > > No. A shape is no longer a group of line segments. You *could* convert > it to such a thing but that requires a bunch of complex math (ie > http://www.youtube.com/watch?v=OmfliNQsk88) For now, I'm not proposing > to add that to the canvas API. Once the Path API is implemented, we can add any number of features, such as adding a path so as to form the union of both paths, adding a path so as to form the intersection of both paths, etc. > The resulting 'path' will once again have no winding. This is very > confusing and extremely hard to implement I don't understand why it's hard to implement. It's just the non-Path API, but stored away for future use. > > Right now we have two options (ignoring the text parts of the path > > API): concatenating path segments, and concatenating path segments > > after having first outlined one of them. > > FYI the outlining algorithm is also not correct. It suffers from the > same issue that strokes are segments. Can you elaborate? (I think I may have asked already, in which case, my apologies for asking again.) > > On the long run I think it would make sense to add other methods, e.g. > > one combining two or more paths together such that the resulting path > > would outline the union of the "insides" of the provided paths, or the > > intersections, or whatnot. > > I think that would be much more confusing and difficult to implement. I > didn't come up with this on my own :-). This is done by graphics > libraries that offers path manipulation support. For instance: skia: > http://skia-autogen.googlecode.com/svn/docs/html/classSkPathEffect.html > lib2geom: http://wiki.inkscape.org/wiki/index.php/WorkingWith2GeomFAQ > Direct2D: > http://msdn.microsoft.com/en-us/library/windows/desktop/dd756653(v=vs.85).aspx#path_geometries I'm confused. Are these examples of how to make confusing APIs, or examples of how the current API is confusing? Those look really, really complicated relative to what Canvas looks like today. On Thu, 5 Sep 2013, Rik Cabanier wrote: > > The problem happens when you call fill or stroke multiple times. > [...] > Now I want to create a region that covers what was drawn. > [...] > 'p' won't describe the same area as what was filled. Sure, for that you need a new API function, e.g. union, which as I've mentioned before, I think would be a logical addition to the API in due course. But I don't think we should add features too quickly, lest we get too far ahead of browsers. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 17 10:30:38 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 17 Sep 2013 17:30:38 +0000 (UTC) Subject: [whatwg] canvas 2d's ellipse In-Reply-To: <CAGN7qDBmpczx1j=hhzWdWXTwPCDj+Ek9+vja56Yi6KsKP5SAkw@mail.gmail.com> References: <3688893053903968472@unknownmsgid> <alpine.DEB.2.00.1308202236340.27209@ps20323.dreamhostps.com> <CAGN7qDBmpczx1j=hhzWdWXTwPCDj+Ek9+vja56Yi6KsKP5SAkw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309171721150.12199@ps20323.dreamhostps.com> On Tue, 20 Aug 2013, Tab Atkins Jr. wrote: > On Tue, Aug 20, 2013 at 3:46 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Tue, 30 Apr 2013, Rik Cabanier wrote: > >> I think the API should look like this: > >> > >> void ellipse(unrestricted double x, optional unrestricted double y, > >> unrestricted double radiusX, optional unrestricted double radiusY, > >> optional unrestricted double rotation, optional unrestricted double > >> startAngle, optional unrestricted double endAngle, optional boolean > >> anticlockwise); > >> > >> with the following behavior: > >> - if radiusY is omitted, it's the same as radiusX > >> - if rotation is omitted, it's equal to 0 > >> - if startAngle is omitted, it's equal to 0 > >> - if endAngle is omitted, it's equal to 0 > >> - if anticlockwise is omitted, it's equal to false > > > > We could do this, sure. How much do people want something like this? > > Does anyone else think it's a good idea? > > I can tell you that specifying all of the arguments in SVG's ellipse > path command is rather annoying. Having good defaults would be a good > thing. The problem here is since the arguments are positional, it doesn't let you just omit the ones you want to omit, only the last few that you don't need. If implementors want to do it, I'm happy to spec it, but it doesn't seem to be something many people feel strongly about... On Tue, 20 Aug 2013, Rik Cabanier wrote: > > > > > > So, if you want to draw a simple circle, you have to supply 8 > > > parameters, even though only 3 are needed. > > > > If you just want a circle, you can use arc(). > > OK. What if you want to draw a simple ellipse? What's a "simple" ellipse? > Here's an example of the issue: http://jsfiddle.net/2N85k/2/ > Because the stroke is using square caps, you can't draw a circle or an > ellipse unless you do a closePath. Yes? Why is this a problem? > Chrome is doing an implicit closePath if start and end angle meet, but > none of the other browsers do. Then Chrome is buggy. Nothing in the spec says to implicitly close the path. > However the spec should be clearer on what happens if the arc is 2 ? for > arc and ellipse. > Chrome believes that case should have a 'closePath' which seems reasonable. > Maybe someone on that team can tell us if this was intentional. I'm tracking this issue here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23050 I don't really understand what's ambiguous about the spec. Please do elaborate on this in the bug. > > On Tue, 30 Apr 2013, Rik Cabanier wrote: > > > > > > I think the exception on negative radius should also be removed. > > > > What would a negative radius mean? > > Either treat it as zero, or use the absolute value. Avoiding exceptions > will make web apps more robust. Or more buggy, because authors won't notice their errors. I'm not a fan of "sweep it under the carpet" bug handling, personally. It drives me crazy that JavaScript has no type checking, no argument checking, etc. So many bugs that should be caught at compile time, or at least at runtime when the code is reached, are instead caught only after careful testing. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jackalmage at gmail.com Tue Sep 17 11:16:20 2013 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Tue, 17 Sep 2013 11:16:20 -0700 Subject: [whatwg] canvas 2d's ellipse In-Reply-To: <alpine.DEB.2.00.1309171721150.12199@ps20323.dreamhostps.com> References: <3688893053903968472@unknownmsgid> <alpine.DEB.2.00.1308202236340.27209@ps20323.dreamhostps.com> <CAGN7qDBmpczx1j=hhzWdWXTwPCDj+Ek9+vja56Yi6KsKP5SAkw@mail.gmail.com> <alpine.DEB.2.00.1309171721150.12199@ps20323.dreamhostps.com> Message-ID: <CAAWBYDDUC8b7tWs4wVJPRorxTiSWN9Yi1-BS5k+RVnEXnGHKRw@mail.gmail.com> On Tue, Sep 17, 2013 at 10:30 AM, Ian Hickson <ian at hixie.ch> wrote: >> > On Tue, 30 Apr 2013, Rik Cabanier wrote: >> > > >> > > I think the exception on negative radius should also be removed. >> > >> > What would a negative radius mean? >> >> Either treat it as zero, or use the absolute value. Avoiding exceptions >> will make web apps more robust. > > Or more buggy, because authors won't notice their errors. > > I'm not a fan of "sweep it under the carpet" bug handling, personally. It > drives me crazy that JavaScript has no type checking, no argument > checking, etc. So many bugs that should be caught at compile time, or at > least at runtime when the code is reached, are instead caught only after > careful testing. "Runtime when the code is reached" often actually means "Whoops! Now the entire app's broken because I forgot to handle a silly edge-case.". When there's an easy and obvious recovery strategy, it's often much friendlier to authors to take it rather than force them to handle errors. This is fairly standard practice in DOM and ES design. ~TJ From ian at hixie.ch Tue Sep 17 11:31:58 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 17 Sep 2013 18:31:58 +0000 (UTC) Subject: [whatwg] canvas 2d's ellipse In-Reply-To: <CAAWBYDDUC8b7tWs4wVJPRorxTiSWN9Yi1-BS5k+RVnEXnGHKRw@mail.gmail.com> References: <3688893053903968472@unknownmsgid> <alpine.DEB.2.00.1308202236340.27209@ps20323.dreamhostps.com> <CAGN7qDBmpczx1j=hhzWdWXTwPCDj+Ek9+vja56Yi6KsKP5SAkw@mail.gmail.com> <alpine.DEB.2.00.1309171721150.12199@ps20323.dreamhostps.com> <CAAWBYDDUC8b7tWs4wVJPRorxTiSWN9Yi1-BS5k+RVnEXnGHKRw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309171829060.12210@ps20323.dreamhostps.com> On Tue, 17 Sep 2013, Tab Atkins Jr. wrote: > > > > I'm not a fan of "sweep it under the carpet" bug handling, personally. > > It drives me crazy that JavaScript has no type checking, no argument > > checking, etc. So many bugs that should be caught at compile time, or > > at least at runtime when the code is reached, are instead caught only > > after careful testing. > > "Runtime when the code is reached" often actually means "Whoops! Now the > entire app's broken because I forgot to handle a silly edge-case.". > When there's an easy and obvious recovery strategy, it's often much > friendlier to authors to take it rather than force them to handle > errors. Usually in these cases the entire app is probably still broken -- maybe with data corruption, even, or with confusingly bad behaviour. The only difference is that you have no idea where to begin looking. It wouldn't be so bad if we had a way to have errors that allowed the code to continue anyway, the way we do e.g. in HTML parsing, where you can easily run a validator to find out what you've done wrong, while still having the errors swept under the carpet on the user's end. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From cabanier at gmail.com Tue Sep 17 12:55:06 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 17 Sep 2013 12:55:06 -0700 Subject: [whatwg] canvas 2d's ellipse In-Reply-To: <alpine.DEB.2.00.1309171829060.12210@ps20323.dreamhostps.com> References: <3688893053903968472@unknownmsgid> <alpine.DEB.2.00.1308202236340.27209@ps20323.dreamhostps.com> <CAGN7qDBmpczx1j=hhzWdWXTwPCDj+Ek9+vja56Yi6KsKP5SAkw@mail.gmail.com> <alpine.DEB.2.00.1309171721150.12199@ps20323.dreamhostps.com> <CAAWBYDDUC8b7tWs4wVJPRorxTiSWN9Yi1-BS5k+RVnEXnGHKRw@mail.gmail.com> <alpine.DEB.2.00.1309171829060.12210@ps20323.dreamhostps.com> Message-ID: <CAGN7qDAvgag3GeqyNBm3xdR5cOcxQqn3C5pK_ng+r6HheDaFfA@mail.gmail.com> On Tue, Sep 17, 2013 at 11:31 AM, Ian Hickson <ian at hixie.ch> wrote: > On Tue, 17 Sep 2013, Tab Atkins Jr. wrote: > > > > > > I'm not a fan of "sweep it under the carpet" bug handling, personally. > > > It drives me crazy that JavaScript has no type checking, no argument > > > checking, etc. So many bugs that should be caught at compile time, or > > > at least at runtime when the code is reached, are instead caught only > > > after careful testing. > > > > "Runtime when the code is reached" often actually means "Whoops! Now the > > entire app's broken because I forgot to handle a silly edge-case.". > > When there's an easy and obvious recovery strategy, it's often much > > friendlier to authors to take it rather than force them to handle > > errors. > > Usually in these cases the entire app is probably still broken -- maybe > with data corruption, even, or with confusingly bad behaviour. The only > difference is that you have no idea where to begin looking. > Ok, so what if *some* applications would be horribly broken. *Others* will still stumble along or work perfectly fine. I'd rather have that, than a completely broken page. > > It wouldn't be so bad if we had a way to have errors that allowed the code > to continue anyway, the way we do e.g. in HTML parsing, where you can > easily run a validator to find out what you've done wrong, while still > having the errors swept under the carpet on the user's end. The browser could log something in the console output so the developer can debug it. Maybe the spec could say that the operation is in error but that processing will continue as if the bad call didn't happen. From ian at hixie.ch Tue Sep 17 13:27:24 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 17 Sep 2013 20:27:24 +0000 (UTC) Subject: [whatwg] canvas 2d's ellipse In-Reply-To: <CAGN7qDAvgag3GeqyNBm3xdR5cOcxQqn3C5pK_ng+r6HheDaFfA@mail.gmail.com> References: <3688893053903968472@unknownmsgid> <alpine.DEB.2.00.1308202236340.27209@ps20323.dreamhostps.com> <CAGN7qDBmpczx1j=hhzWdWXTwPCDj+Ek9+vja56Yi6KsKP5SAkw@mail.gmail.com> <alpine.DEB.2.00.1309171721150.12199@ps20323.dreamhostps.com> <CAAWBYDDUC8b7tWs4wVJPRorxTiSWN9Yi1-BS5k+RVnEXnGHKRw@mail.gmail.com> <alpine.DEB.2.00.1309171829060.12210@ps20323.dreamhostps.com> <CAGN7qDAvgag3GeqyNBm3xdR5cOcxQqn3C5pK_ng+r6HheDaFfA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309172020130.12210@ps20323.dreamhostps.com> On Tue, 17 Sep 2013, Rik Cabanier wrote: > On Tue, Sep 17, 2013 at 11:31 AM, Ian Hickson <ian at hixie.ch> wrote: > > On Tue, 17 Sep 2013, Tab Atkins Jr. wrote: > > > > > > > > I'm not a fan of "sweep it under the carpet" bug handling, > > > > personally. It drives me crazy that JavaScript has no type > > > > checking, no argument checking, etc. So many bugs that should be > > > > caught at compile time, or at least at runtime when the code is > > > > reached, are instead caught only after careful testing. > > > > > > "Runtime when the code is reached" often actually means "Whoops! Now > > > the entire app's broken because I forgot to handle a silly > > > edge-case.". When there's an easy and obvious recovery strategy, > > > it's often much friendlier to authors to take it rather than force > > > them to handle errors. > > > > Usually in these cases the entire app is probably still broken -- > > maybe with data corruption, even, or with confusingly bad behaviour. > > The only difference is that you have no idea where to begin looking. > > Ok, so what if *some* applications would be horribly broken. *Others* > will still stumble along or work perfectly fine. I'd rather have that, > than a completely broken page. Dramatically simplifying the situation here, we're saying that the available options are: A: All buggy applications fail to compile, because of static checking. Cost to fix the bugs is low. B: All buggy applications break entirely when edge cases are hit. Cost to fix the bugs is moderate. C: Some buggy applications break entirely when edge cases are hit. Some buggy applications have data corruption! Some buggy applications have merely graphical artefacts. Cost to fix the bugs is high. I think option A is vastly superior, but since that's not an option, option B is preferable to option C. In reality, I don't think it's true that the Web always goes with C. If it did, there'd never be exceptions thrown by APIs, and exceptions are thrown all the time by APIs. Indeed, if it were the case that we had a philosophy of going with "muddling along" where possible, JavaScript wouldn't have syntax errors, or, much like CSS, it would have rules for recovering from them and would simply ignore syntactically invalid constructs. We don't do that. Instead, we chose the middle ground B most of the time. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From cabanier at gmail.com Tue Sep 17 14:32:03 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 17 Sep 2013 14:32:03 -0700 Subject: [whatwg] canvas 2d's ellipse In-Reply-To: <alpine.DEB.2.00.1309172020130.12210@ps20323.dreamhostps.com> References: <3688893053903968472@unknownmsgid> <alpine.DEB.2.00.1308202236340.27209@ps20323.dreamhostps.com> <CAGN7qDBmpczx1j=hhzWdWXTwPCDj+Ek9+vja56Yi6KsKP5SAkw@mail.gmail.com> <alpine.DEB.2.00.1309171721150.12199@ps20323.dreamhostps.com> <CAAWBYDDUC8b7tWs4wVJPRorxTiSWN9Yi1-BS5k+RVnEXnGHKRw@mail.gmail.com> <alpine.DEB.2.00.1309171829060.12210@ps20323.dreamhostps.com> <CAGN7qDAvgag3GeqyNBm3xdR5cOcxQqn3C5pK_ng+r6HheDaFfA@mail.gmail.com> <alpine.DEB.2.00.1309172020130.12210@ps20323.dreamhostps.com> Message-ID: <CAGN7qDCY5sCBY31fEOWYUT-ZX4CC2BRSC=HscXefYQk3Qhd1bg@mail.gmail.com> On Tue, Sep 17, 2013 at 1:27 PM, Ian Hickson <ian at hixie.ch> wrote: > On Tue, 17 Sep 2013, Rik Cabanier wrote: > > On Tue, Sep 17, 2013 at 11:31 AM, Ian Hickson <ian at hixie.ch> wrote: > > > On Tue, 17 Sep 2013, Tab Atkins Jr. wrote: > > > > > > > > > > I'm not a fan of "sweep it under the carpet" bug handling, > > > > > personally. It drives me crazy that JavaScript has no type > > > > > checking, no argument checking, etc. So many bugs that should be > > > > > caught at compile time, or at least at runtime when the code is > > > > > reached, are instead caught only after careful testing. > > > > > > > > "Runtime when the code is reached" often actually means "Whoops! Now > > > > the entire app's broken because I forgot to handle a silly > > > > edge-case.". When there's an easy and obvious recovery strategy, > > > > it's often much friendlier to authors to take it rather than force > > > > them to handle errors. > > > > > > Usually in these cases the entire app is probably still broken -- > > > maybe with data corruption, even, or with confusingly bad behaviour. > > > The only difference is that you have no idea where to begin looking. > > > > Ok, so what if *some* applications would be horribly broken. *Others* > > will still stumble along or work perfectly fine. I'd rather have that, > > than a completely broken page. > > Dramatically simplifying the situation here, we're saying that the > available options are: > > A: All buggy applications fail to compile, because of static checking. > Cost to fix the bugs is low. > > B: All buggy applications break entirely when edge cases are hit. > Cost to fix the bugs is moderate. > > C: Some buggy applications break entirely when edge cases are hit. > Some buggy applications have data corruption! > Some buggy applications have merely graphical artefacts. > Cost to fix the bugs is high. > > I think option A is vastly superior, but since that's not an option, > option B is preferable to option C. > You are speaking as a developer, not as a user of a web application. Browser could offer a 'debug' more where they break on bad calls or output messages to the console. Once it's 'released', the runtime should be permissive. > > In reality, I don't think it's true that the Web always goes with C. If it > did, there'd never be exceptions thrown by APIs, and exceptions are thrown > all the time by APIs. Indeed, if it were the case that we had a philosophy > of going with "muddling along" where possible, JavaScript wouldn't have > syntax errors, or, much like CSS, it would have rules for recovering from > them and would simply ignore syntactically invalid constructs. We don't do > that. Instead, we chose the middle ground B most of the time. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > From robert at ocallahan.org Tue Sep 17 14:37:59 2013 From: robert at ocallahan.org (Robert O'Callahan) Date: Wed, 18 Sep 2013 09:37:59 +1200 Subject: [whatwg] canvas 2d's ellipse In-Reply-To: <alpine.DEB.2.00.1309172020130.12210@ps20323.dreamhostps.com> References: <3688893053903968472@unknownmsgid> <alpine.DEB.2.00.1308202236340.27209@ps20323.dreamhostps.com> <CAGN7qDBmpczx1j=hhzWdWXTwPCDj+Ek9+vja56Yi6KsKP5SAkw@mail.gmail.com> <alpine.DEB.2.00.1309171721150.12199@ps20323.dreamhostps.com> <CAAWBYDDUC8b7tWs4wVJPRorxTiSWN9Yi1-BS5k+RVnEXnGHKRw@mail.gmail.com> <alpine.DEB.2.00.1309171829060.12210@ps20323.dreamhostps.com> <CAGN7qDAvgag3GeqyNBm3xdR5cOcxQqn3C5pK_ng+r6HheDaFfA@mail.gmail.com> <alpine.DEB.2.00.1309172020130.12210@ps20323.dreamhostps.com> Message-ID: <CAOp6jLYYMNjrK=TF80Gd6BR_YjRHxZzaULbi-GBSTCh0drefgA@mail.gmail.com> On Wed, Sep 18, 2013 at 8:27 AM, Ian Hickson <ian at hixie.ch> wrote: > A: All buggy applications fail to compile, because of static checking. > Cost to fix the bugs is low. > > B: All buggy applications break entirely when edge cases are hit. > Cost to fix the bugs is moderate. > > C: Some buggy applications break entirely when edge cases are hit. > Some buggy applications have data corruption! > Some buggy applications have merely graphical artefacts. > Cost to fix the bugs is high. > I think our decision to make 2D canvas methods [LenientFloat] (choosing C over B) was a good one because "muddling on through" in the case of a transient singularity that will likely only produce a transient rendering error seems like a good cost-benefit tradeoff. So we need to consider the likely impact of the bug; transient graphical artifacts are relatively low impact. Also I think we should consider whether the bad behavior is deterministic and hence likely to be detected during testing. When it isn't (and can't be made so!), it makes more sense for implementations to be lenient (choose B over C), since then it's more likely the impact of the bug will fall on users as much or more than developers and the cost of fixing the bug is high no matter what we do. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * From robert at ocallahan.org Tue Sep 17 14:38:52 2013 From: robert at ocallahan.org (Robert O'Callahan) Date: Wed, 18 Sep 2013 09:38:52 +1200 Subject: [whatwg] canvas 2d's ellipse In-Reply-To: <CAOp6jLYYMNjrK=TF80Gd6BR_YjRHxZzaULbi-GBSTCh0drefgA@mail.gmail.com> References: <3688893053903968472@unknownmsgid> <alpine.DEB.2.00.1308202236340.27209@ps20323.dreamhostps.com> <CAGN7qDBmpczx1j=hhzWdWXTwPCDj+Ek9+vja56Yi6KsKP5SAkw@mail.gmail.com> <alpine.DEB.2.00.1309171721150.12199@ps20323.dreamhostps.com> <CAAWBYDDUC8b7tWs4wVJPRorxTiSWN9Yi1-BS5k+RVnEXnGHKRw@mail.gmail.com> <alpine.DEB.2.00.1309171829060.12210@ps20323.dreamhostps.com> <CAGN7qDAvgag3GeqyNBm3xdR5cOcxQqn3C5pK_ng+r6HheDaFfA@mail.gmail.com> <alpine.DEB.2.00.1309172020130.12210@ps20323.dreamhostps.com> <CAOp6jLYYMNjrK=TF80Gd6BR_YjRHxZzaULbi-GBSTCh0drefgA@mail.gmail.com> Message-ID: <CAOp6jLb4LWPnUDa0unnhXj4Bo=D8w5yMS_SmyYaDOOVCG55Zdg@mail.gmail.com> On Wed, Sep 18, 2013 at 9:37 AM, Robert O'Callahan <robert at ocallahan.org>wrote: > > (choose B over C) > I meant C over B of course. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * From leon.gilyadov at gmail.com Wed Sep 18 01:14:06 2013 From: leon.gilyadov at gmail.com (Leon Gilyadov) Date: Wed, 18 Sep 2013 10:14:06 +0200 Subject: [whatwg] Proposal: q and qq for document.querySelector and document.querySelectorAll Message-ID: <CAAn7mYbM-f1cXJZEcDVRnxYppTDT+DJ78-cNdwVsA4qMpQ8=Vw@mail.gmail.com> *The problem:* document.querySelector and document.querySelectorAll are long and used a lot. Lines in the code are long. *Proposal:* q('.my-div') will be equal to: document.querySelector('.my-div) qq('.my-div') will be equal to: document.querySelectorAll('.my-div') --Leon Gilyadov. From scott.gonzalez at gmail.com Wed Sep 18 05:10:38 2013 From: scott.gonzalez at gmail.com (=?ISO-8859-1?Q?Scott_Gonz=E1lez?=) Date: Wed, 18 Sep 2013 08:10:38 -0400 Subject: [whatwg] Proposal: q and qq for document.querySelector and document.querySelectorAll In-Reply-To: <CAAn7mYbM-f1cXJZEcDVRnxYppTDT+DJ78-cNdwVsA4qMpQ8=Vw@mail.gmail.com> References: <CAAn7mYbM-f1cXJZEcDVRnxYppTDT+DJ78-cNdwVsA4qMpQ8=Vw@mail.gmail.com> Message-ID: <CAO8i3ifFtFCZTcJoPZgnQs=-82KBva3nz+KHAWE58i5Cor6Qqg@mail.gmail.com> So you're suggesting new globals that are bound to the document? That sounds really bad. Also, there's no reason to suggest an alias to querySelector() when it's much more likely that query() will be used by the majority of developers. On Wed, Sep 18, 2013 at 4:14 AM, Leon Gilyadov <leon.gilyadov at gmail.com>wrote: > *The problem:* > document.querySelector and document.querySelectorAll > are long and used a lot. > > Lines in the code are long. > > *Proposal:* > q('.my-div') > will be equal to: > document.querySelector('.my-div) > > qq('.my-div') > will be equal to: > document.querySelectorAll('.my-div') > > > --Leon Gilyadov. > From niels.keurentjes at omines.com Wed Sep 18 05:18:20 2013 From: niels.keurentjes at omines.com (Niels Keurentjes) Date: Wed, 18 Sep 2013 12:18:20 +0000 Subject: [whatwg] Proposal: q and qq for document.querySelector and document.querySelectorAll In-Reply-To: <CAO8i3ifFtFCZTcJoPZgnQs=-82KBva3nz+KHAWE58i5Cor6Qqg@mail.gmail.com> References: <CAAn7mYbM-f1cXJZEcDVRnxYppTDT+DJ78-cNdwVsA4qMpQ8=Vw@mail.gmail.com> <CAO8i3ifFtFCZTcJoPZgnQs=-82KBva3nz+KHAWE58i5Cor6Qqg@mail.gmail.com> Message-ID: <A212DA0831E8714BB0860F102E8E29DC856D350D@omines-srv-004.omines.corp> The spec should only concern itself with exposing functionality. Practical considerations such as length of code are the responsibility of the developer - if you like to have q and qq aliases you can add them yourself at runtime, that's the whole point of a prototyped language. Common libraries like jQuery, prototype and Mootools expose the behaviour as $ and $$ for exactly the reason given, no reason to impose that on every developer if they choose not to use a library. -----Original Message----- From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Scott Gonz?lez Sent: woensdag 18 september 2013 14:11 To: Leon Gilyadov Cc: whatwg at lists.whatwg.org Subject: Re: [whatwg] Proposal: q and qq for document.querySelector and document.querySelectorAll So you're suggesting new globals that are bound to the document? That sounds really bad. Also, there's no reason to suggest an alias to querySelector() when it's much more likely that query() will be used by the majority of developers. On Wed, Sep 18, 2013 at 4:14 AM, Leon Gilyadov <leon.gilyadov at gmail.com>wrote: > *The problem:* > document.querySelector and document.querySelectorAll are long and used > a lot. > > Lines in the code are long. > > *Proposal:* > q('.my-div') > will be equal to: > document.querySelector('.my-div) > > qq('.my-div') > will be equal to: > document.querySelectorAll('.my-div') > > > --Leon Gilyadov. > From james.m.greene at gmail.com Wed Sep 18 07:18:05 2013 From: james.m.greene at gmail.com (James Greene) Date: Wed, 18 Sep 2013 09:18:05 -0500 Subject: [whatwg] Proposal: q and qq for document.querySelector and document.querySelectorAll In-Reply-To: <CALrbKZgcSxwRLO93m5=UMCsh9zsF6ouauW3-awkvg80tzky6Rg@mail.gmail.com> References: <CAAn7mYbM-f1cXJZEcDVRnxYppTDT+DJ78-cNdwVsA4qMpQ8=Vw@mail.gmail.com> <CALrbKZgcSxwRLO93m5=UMCsh9zsF6ouauW3-awkvg80tzky6Rg@mail.gmail.com> Message-ID: <CALrbKZjPbMbdftEh0j2r1snPx5B5_JKR_zPADK-z=UWV+ooiCw@mail.gmail.com> Aww, accidentally did a direct reply instead of replying to the list. :( On Sep 18, 2013 7:01 AM, "James Greene" <james.m.greene at gmail.com> wrote: > var q = document.querySelector; > var qq = document.querySelectorAll; > On Sep 18, 2013 3:14 AM, "Leon Gilyadov" <leon.gilyadov at gmail.com> wrote: > >> *The problem:* >> document.querySelector and document.querySelectorAll >> are long and used a lot. >> >> Lines in the code are long. >> >> *Proposal:* >> q('.my-div') >> will be equal to: >> document.querySelector('.my-div) >> >> qq('.my-div') >> will be equal to: >> document.querySelectorAll('.my-div') >> >> >> --Leon Gilyadov. >> > From simonp at opera.com Wed Sep 18 07:26:35 2013 From: simonp at opera.com (Simon Pieters) Date: Wed, 18 Sep 2013 16:26:35 +0200 Subject: [whatwg] Proposal: q and qq for document.querySelector and document.querySelectorAll In-Reply-To: <CALrbKZjPbMbdftEh0j2r1snPx5B5_JKR_zPADK-z=UWV+ooiCw@mail.gmail.com> References: <CAAn7mYbM-f1cXJZEcDVRnxYppTDT+DJ78-cNdwVsA4qMpQ8=Vw@mail.gmail.com> <CALrbKZgcSxwRLO93m5=UMCsh9zsF6ouauW3-awkvg80tzky6Rg@mail.gmail.com> <CALrbKZjPbMbdftEh0j2r1snPx5B5_JKR_zPADK-z=UWV+ooiCw@mail.gmail.com> Message-ID: <op.w3l2elt3idj3kv@simons-macbook-pro.local> On Wed, 18 Sep 2013 16:18:05 +0200, James Greene <james.m.greene at gmail.com> wrote: > Aww, accidentally did a direct reply instead of replying to the list. :( > On Sep 18, 2013 7:01 AM, "James Greene" <james.m.greene at gmail.com> wrote: > >> var q = document.querySelector; >> var qq = document.querySelectorAll; That doesn't work because `this` will be wrong. But you can add .bind(document) to fix that. -- Simon Pieters Opera Software From dbaron at dbaron.org Wed Sep 18 08:10:01 2013 From: dbaron at dbaron.org (L. David Baron) Date: Wed, 18 Sep 2013 08:10:01 -0700 Subject: [whatwg] HTML: A DOM attribute that returns the language of a node In-Reply-To: <CAO9Q3i+V=_FAP9bj9BbO8e58DkQvZKxs8gNpD56qSua=LCUeVw@mail.gmail.com> References: <2316EE6495904AB79C77E28AC9B9ADC7@PeterPC> <CADnb78iBsk=iZRV5g9hBvowhg5AeDoqvMRmVqKqr-jMHStfCBw@mail.gmail.com> <B83F314F39FB4BC2A11F81CE09C5076F@PeterPC> <CAO9Q3i+V=_FAP9bj9BbO8e58DkQvZKxs8gNpD56qSua=LCUeVw@mail.gmail.com> Message-ID: <20130918151001.GA18458@crum.dbaron.org> On Wednesday 2013-05-01 01:01 -0700, Elliott Sprehn wrote: > On Wed, Apr 24, 2013 at 9:22 AM, Peter Occil <poccil14 at gmail.com> wrote: > > I have no objection to the name "baseLang" rather than "language" as the > > name of the DOM attribute. > > > > But if there isn't more interest or you decide not to add this DOM > > attribute, I encourage you to at least: > > > > > fwiw WebKit (and Blink) implement this through CSS inheritance since you > need to know the lang for all kinds of things and walking up the DOM > repeatedly would be expensive. > > -webkit-locale is inherited by default and contains the enclosing @lang > value. You can query it through getComputedStyle(node).webkitLocale. That > doesn't help your custom parser though. In Gecko it's also implemented through CSS inheritance, but it's not exposed to Web content as a CSS property. (Internally it's '-x-lang', but that name isn't exposed.) We use the language for: * font selection * language-specific text-transform behavior * hyphenation (which doesn't work unless it's explicitly specified, as required by http://dev.w3.org/csswg/css-text/#hyphens-property ) -David -- ? L. David Baron http://dbaron.org/ ? ? Mozilla https://www.mozilla.org/ ? Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) From glenn at zewt.org Wed Sep 18 08:27:51 2013 From: glenn at zewt.org (Glenn Maynard) Date: Wed, 18 Sep 2013 10:27:51 -0500 Subject: [whatwg] Proposal: q and qq for document.querySelector and document.querySelectorAll In-Reply-To: <A212DA0831E8714BB0860F102E8E29DC856D350D@omines-srv-004.omines.corp> References: <CAAn7mYbM-f1cXJZEcDVRnxYppTDT+DJ78-cNdwVsA4qMpQ8=Vw@mail.gmail.com> <CAO8i3ifFtFCZTcJoPZgnQs=-82KBva3nz+KHAWE58i5Cor6Qqg@mail.gmail.com> <A212DA0831E8714BB0860F102E8E29DC856D350D@omines-srv-004.omines.corp> Message-ID: <CABirCh_J1tg71RpbMOkVP5N_QfdR64oKcRDiTvY8e7UTrAxbVA@mail.gmail.com> On Wed, Sep 18, 2013 at 7:18 AM, Niels Keurentjes < niels.keurentjes at omines.com> wrote: > The spec should only concern itself with exposing functionality. Practical > considerations such as length of code are the responsibility of the > developer - if you like to have q and qq aliases you can add them yourself > at runtime, that's the whole point of a prototyped language. Common > libraries like jQuery, prototype and Mootools expose the behaviour as $ and > $$ for exactly the reason given, no reason to impose that on every > developer if they choose not to use a library. > This is nonsense. Usability and practicality are absolutely concerns of the spec. If libraries like jQuery need to be used for it to be convenient to develop for the platform, and everyone has different and incompatible convenience wrappers for everything, then that's a failure of the platform. (I don't think this proposal is a good idea, though.) -- Glenn Maynard From annevk at annevk.nl Wed Sep 18 08:34:23 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Wed, 18 Sep 2013 11:34:23 -0400 Subject: [whatwg] HTML: A DOM attribute that returns the language of a node In-Reply-To: <20130918151001.GA18458@crum.dbaron.org> References: <2316EE6495904AB79C77E28AC9B9ADC7@PeterPC> <CADnb78iBsk=iZRV5g9hBvowhg5AeDoqvMRmVqKqr-jMHStfCBw@mail.gmail.com> <B83F314F39FB4BC2A11F81CE09C5076F@PeterPC> <CAO9Q3i+V=_FAP9bj9BbO8e58DkQvZKxs8gNpD56qSua=LCUeVw@mail.gmail.com> <20130918151001.GA18458@crum.dbaron.org> Message-ID: <CADnb78hO6t+WAEKc8-bE4Lnk45HxnduSgFqhGZ9NQPNPfhOj+g@mail.gmail.com> On Wed, Sep 18, 2013 at 11:10 AM, L. David Baron <dbaron at dbaron.org> wrote: > In Gecko it's also implemented through CSS inheritance, but it's not > exposed to Web content as a CSS property. (Internally it's > '-x-lang', but that name isn't exposed.) > > We use the language for: > * font selection > * language-specific text-transform behavior > * hyphenation (which doesn't work unless it's explicitly specified, > as required by http://dev.w3.org/csswg/css-text/#hyphens-property ) It seems my earlier point about inheritance of text direction remains. Base URLs however are obsolete as only Gecko implements xml:base. If this is implemented through CSS, does it make sense to expose it through the DOM? -- http://annevankesteren.nl/ From tobie.langel at gmail.com Wed Sep 18 09:16:02 2013 From: tobie.langel at gmail.com (Tobie Langel) Date: Wed, 18 Sep 2013 18:16:02 +0200 Subject: [whatwg] Proposal: q and qq for document.querySelector and document.querySelectorAll In-Reply-To: <CABirCh_J1tg71RpbMOkVP5N_QfdR64oKcRDiTvY8e7UTrAxbVA@mail.gmail.com> References: <CAAn7mYbM-f1cXJZEcDVRnxYppTDT+DJ78-cNdwVsA4qMpQ8=Vw@mail.gmail.com> <CAO8i3ifFtFCZTcJoPZgnQs=-82KBva3nz+KHAWE58i5Cor6Qqg@mail.gmail.com> <A212DA0831E8714BB0860F102E8E29DC856D350D@omines-srv-004.omines.corp> <CABirCh_J1tg71RpbMOkVP5N_QfdR64oKcRDiTvY8e7UTrAxbVA@mail.gmail.com> Message-ID: <160A4461446F497FBD1140A0F0BF59C2@gmail.com> On Wednesday, September 18, 2013 at 5:27 PM, Glenn Maynard wrote: > On Wed, Sep 18, 2013 at 7:18 AM, Niels Keurentjes < > niels.keurentjes at omines.com (mailto:niels.keurentjes at omines.com)> wrote: > > The spec should only concern itself with exposing functionality. Practical > > considerations such as length of code are the responsibility of the > > developer - if you like to have q and qq aliases you can add them yourself > > at runtime, that's the whole point of a prototyped language. Common > > libraries like jQuery, prototype and Mootools expose the behaviour as $ and > > $$ for exactly the reason given, no reason to impose that on every > > developer if they choose not to use a library. > > This is nonsense. Usability and practicality are absolutely concerns of > the spec. If libraries like jQuery need to be used for it to be convenient > to develop for the platform, and everyone has different and incompatible > convenience wrappers for everything, then that's a failure of the platform. > > (I don't think this proposal is a good idea, though.) ^ this. --tobie From cabanier at gmail.com Wed Sep 18 11:14:32 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Wed, 18 Sep 2013 11:14:32 -0700 Subject: [whatwg] Canvas - Should setLineDash be a nullable sequence? In-Reply-To: <alpine.DEB.2.00.1309171657450.12199@ps20323.dreamhostps.com> References: <CAA5isUZHQQ+zf2CzNOG6NL96c-RkiqF_z0aFjx82_Lh=Xb0hhg@mail.gmail.com> <alpine.DEB.2.00.1309171657450.12199@ps20323.dreamhostps.com> Message-ID: <CAGN7qDB5UsS9UETt8FHaLW=m4nn6BfDYqLZzaa4DogqNnegSOA@mail.gmail.com> On Tue, Sep 17, 2013 at 10:06 AM, Ian Hickson <ian at hixie.ch> wrote: > On Tue, 20 Aug 2013, Simon Sarris wrote: > > > > This is minor, but it did recently break formerly-working functionality > > in Google Chrome, so maybe its worth a discussion. > > > > The specification reads: > > > > void setLineDash(sequence<unrestricted double> segments); // default > empty > > sequence<unrestricted double> getLineDash(); > > > > This means we *cannot* use: > > > > ctx.setLineDash(null); > > > > In Chrome 28 and previous (for at least 6 months) null was an allowed > > value, but in Chrome 30 (at least) it switched to throwing a TypeError. > > I couldn't find any currently-shipping browsers that supported this, so it > seems unlikely that there'd be much legacy content that depends on it. > (Not saying there's none, just that it's limited in scope.) Thus, the > compatibility issue here is not the only thing we should consider. (It's > still a factor, just not an automatic win, as it might otherwise be.) > > There's certainly an advantage to failing if the input is "null" here -- > it's more likely to catch underlying errors quicker. Instead of just > getting a solid line where you expected a dashed one, you get an error > with a precise line number from which to start your search. > > > > In any case, I think it would be better if setLineDash was defined in > > the spec as a nullable sequence, so that when setting it back to nothing > > to return to normal not-dashed path stroking (which could happen > > thousands of times in a an animation frame) less stuff gets allocated in > > the draw loop. > > A literal empty array can get optimised out by compilers, so it really > shouldn't be that big a deal on the long run. > > > > I think part of the issue is that setLineDash does two things. It sets > > the dashing properties, but it also acts as the only way to > > enable/disable dashing, I think that null seems appropriate. > > All lines are dashed, it's just that some have an infinitely long dash > with no space. Don't look at it as enabling/disabling dashing. :-) > That's correct. If we ever allow a 'null', we should equate it to '[]' From cabanier at gmail.com Wed Sep 18 17:03:47 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Wed, 18 Sep 2013 17:03:47 -0700 Subject: [whatwg] Path API feedback In-Reply-To: <alpine.DEB.2.00.1309171709350.12199@ps20323.dreamhostps.com> References: <CAGN7qDATVtL08NLKvYsL+WVzGYn5fy3WxdQLQYqpB55NuhyL3g@mail.gmail.com> <Pine.LNX.4.64.1304260027360.3512@ps20323.dreamhostps.com> <CAGN7qDBcC7aPD1BcuDHbvMavfM3ez0CufFWgaLHcaPHBsuoNrA@mail.gmail.com> <alpine.DEB.2.00.1308202232540.27209@ps20323.dreamhostps.com> <CAGN7qDDXqyZt2gkmttoUps3qgEUiesBdpGmhotUhk4Ay6S_PVQ@mail.gmail.com> <alpine.DEB.2.00.1309171709350.12199@ps20323.dreamhostps.com> Message-ID: <CAGN7qDCUNfxGvc7isRhYL8WLuxP_gk4PfvrrsOTV5VEMTL1COA@mail.gmail.com> On Tue, Sep 17, 2013 at 10:20 AM, Ian Hickson <ian at hixie.ch> wrote: > On Tue, 20 Aug 2013, Rik Cabanier wrote: > > > On Sat, 23 Mar 2013, Rik Cabanier wrote: > > > > > > > > The current path APIs suffer from conflating path segments and > > > > geometry. To fix this, I proposed to modify the API so path just > > > > describe the path segments. > > > > > > > > http://blogs.adobe.com/webplatform/2013/01/31/revised-canvas-paths/ > > > > > > I disagree with the premise of this post -- it's not the case that you > > > never want to add segments. It is in fact quite common to add segments > > > to a path -- that's what constructing a path is. > > > > I disagree. How many times does an author want to add segments to an > > existing path? > > Pretty much every time they create a path with more than one segment. > Maybe I phrased that wrong. The existing path is a path that was created earlier (and could have already been used to draw). It's not often that you would want to append to such a path. > Let's say an application stores a circle in a path and now want to draw > > a rectangle too. You propose that the application just appends the > > rectangle. > > No, not necessarily. It depends on what they want to do. If they want a > single path that is constructed of a circle and a rectangle in the same > way that it would be if they did: > > x.beginPath(); > x.arc(...); > x.rect(...); > x.fill(); > > ...then yeah, they should just append the rectangle. But if they want the > same effect as: > > x.beginPath(); > x.arc(); > x.fill(); > x.rect(...); > x.fill(); > > ...then they should not just append them, since as you say, it won't work. > Yes, but for hit regions, you would have to calculate the area that these 2 fill operations covered. This is why we need the extra 'union' API. > > > > > Also, it's not at all clear to me that there's really a distinction > > > between a "shape" and a "path". They're really the same thing -- sets > > > of path segments. > > > > No. A shape is no longer a group of line segments. You *could* convert > > it to such a thing but that requires a bunch of complex math (ie > > http://www.youtube.com/watch?v=OmfliNQsk88) For now, I'm not proposing > > to add that to the canvas API. > > Once the Path API is implemented, we can add any number of features, such > as adding a path so as to form the union of both paths, adding a path so > as to form the intersection of both paths, etc. > OK. In order to make that possible, 'addPath', 'addPathByStrokingPath', 'addText' and 'addTextByStrokingText' should be cut from the interface. > > > > The resulting 'path' will once again have no winding. This is very > > confusing and extremely hard to implement > > I don't understand why it's hard to implement. It's just the non-Path API, > but stored away for future use. > > > > > Right now we have two options (ignoring the text parts of the path > > > API): concatenating path segments, and concatenating path segments > > > after having first outlined one of them. > > > > FYI the outlining algorithm is also not correct. It suffers from the > > same issue that strokes are segments. > > Can you elaborate? (I think I may have asked already, in which case, my > apologies for asking again.) > I started it in http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-September/040810.html > > > > > On the long run I think it would make sense to add other methods, e.g. > > > one combining two or more paths together such that the resulting path > > > would outline the union of the "insides" of the provided paths, or the > > > intersections, or whatnot. > > > > I think that would be much more confusing and difficult to implement. I > > didn't come up with this on my own :-). This is done by graphics > > libraries that offers path manipulation support. For instance: skia: > > http://skia-autogen.googlecode.com/svn/docs/html/classSkPathEffect.html > > lib2geom: http://wiki.inkscape.org/wiki/index.php/WorkingWith2GeomFAQ > > Direct2D: > > > http://msdn.microsoft.com/en-us/library/windows/desktop/dd756653(v=vs.85).aspx#path_geometries > > I'm confused. Are these examples of how to make confusing APIs, or > examples of how the current API is confusing? Those look really, really > complicated relative to what Canvas looks like today. > Those are examples how path composition is defined in graphic libraries. I'm not proposing that we copy the APIs :-) None of the libraries I listed, is working on the path operations themselves (like you defined in canvas) > > > On Thu, 5 Sep 2013, Rik Cabanier wrote: > > > > The problem happens when you call fill or stroke multiple times. > > [...] > > Now I want to create a region that covers what was drawn. > > [...] > > 'p' won't describe the same area as what was filled. > > Sure, for that you need a new API function, e.g. union, which as I've > mentioned before, I think would be a logical addition to the API in due > course. But I don't think we should add features too quickly, lest we get > too far ahead of browsers. That sounds reasonable. So please remove the APIs such as AddPathByStrokingPath that rely on these difficult algorithms. From lists at scratchdisk.com Fri Sep 20 10:48:42 2013 From: lists at scratchdisk.com (=?iso-8859-1?Q?J=FCrg_Lehni?=) Date: Fri, 20 Sep 2013 10:48:42 -0700 Subject: [whatwg] Questions regarding Path object In-Reply-To: <alpine.DEB.2.00.1308201808080.27209@ps20323.dreamhostps.com> References: <0E6F0444-AB1B-4FFC-B62C-E14F3DB74BA1@scratchdisk.com> <CAGN7qDB_CM=KTaW5+cB9FoYSuCK93kNvNMru8FVUh4BLxLKezw@mail.gmail.com> <C702CEA4-0D06-4E2B-9EFF-DC93DEF58310@scratchdisk.com> <CAGN7qDABijW_nB=+n4AKNwc6BwKGDY99G9KC0KCJheQyCdDN2w@mail.gmail.com> <82C5F947-BDF4-45A1-9701-3857E2194C60@scratchdisk.com> <CAGN7qDAvnfCEqh7Cp8hgo0kWW11wpJE0UBwTaghwkPB7tya5iQ@mail.gmail.com> <18E5B2F8-5A03-4486-9EEE-CEC0FB3E80EE@scratchdisk.com> <51C0416D.2060905@opera.com> <alpine.DEB.2.00.1308201808080.27209@ps20323.dreamhostps.com> Message-ID: <7DE99F3A-5842-4A8B-9FA5-A1799091FE24@scratchdisk.com> Apologies for the slow reply on this, just seeing your answer now: On Aug 20, 2013, at 11:32 , Ian Hickson <ian at hixie.ch> wrote: > On Sat, 23 Mar 2013, J?rg Lehni wrote: >> >> - Paper.js has its own share of classes, and one of them is called Path. >> We normally run scoped but allow people to inject into the global scope. >> This would override the new Path constructor. > > This was last considered last October: > > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-October/037548.html > > My conclusion then was that we didn't have much evidence that Path was > going to work, but we also didn't have much evidence that it was going to > be an insurmountable problem. > > How much of a problem is the paper.js case? It is quite a problem for us really because many people choose to inject the scoped library into the global scope, for simpler code. That is also the way one writes code in PaperScript (which is executed in its own scope where these constructors appear global, but do not pollute the actual global scope), and thus how all our examples and tutorials are written. Path is the most important constructor in Paper.js, a lot is built on top of it. Changing it now would be a huge nuisance for us. > The name "Path" is generic, but that's kind of the point -- this interface > might get used by SVG and other contexts, which is why I didn't call it > CanvasPath, Path2D, or some variant of Shape. I would like to argue that Path2D is more precise and accurate than simply Path. It is about two dimensional vector graphics after all, and about performing geometric operations with / on it (hit testing, boolean operations, drawing). Path2D makes as much sense in a Canvas context as it does in SVG. >> - I see there are many ways to construct paths from different type of >> data, and perform manipulations on them. addPathByStrokingPath() and >> addPathByStrokingText() are both very welcome, for example. Will there >> be a way to access the resulting path description again, for example as >> SVG-style pathData? I have not seen a description of any such property >> on the object, but would strongly suggest that one is added, since >> having access to the result of such path manipulations would hugely >> increase the usefulness of the Path object. > > Manipulating paths is something I am punting on until browsers implement > what's in the spec already, but I imagine at some point we'll add that, > yeah. Maybe we can be of help there: We have put a lot of thought and work into how Paper.js allows users to directly draw and manipulate Path data, and tried to come up with solutions to make that as easy and convenient as possible. I believe we could contribute insight to that discussion. Also, thanks to Harikrishnan Gopalakrishnan, since a couple of months Paper.js has a working implementation of fat bezier clipping for very fast path intersections, and a very resourceful implementation of boolean operations (both in amount of code, and execution speed). Perhaps this could serve as an example implementation? We are currently working on implementing stroke expansion also. > On Sat, 23 Mar 2013, Rik Cabanier wrote: >> >> The current path APIs suffer from conflating path segments and geometry. >> To fix this, I proposed to modify the API so path just describe the path >> segments. >> >> http://blogs.adobe.com/webplatform/2013/01/31/revised-canvas-paths/ > > I disagree with the premise of this post -- it's not the case that you > never want to add segments. It is in fact quite common to add segments to > a path -- that's what constructing a path is. > > Also, it's not at all clear to me that there's really a distinction > between a "shape" and a "path". They're really the same thing -- sets of > path segments. What distinguishes them is not anything intrinsic to them, > it's the behaviour when you combine segments. > > Thus the clearer solution, IMHO, insofar as there's a problem, is to add > methods that describe the various ways to combine paths. > > Right now we have two options (ignoring the text parts of the path API): > concatenating path segments, and concatenating path segments after having > first outlined one of them. > > On the long run I think it would make sense to add other methods, e.g. one > combining two or more paths together such that the resulting path would > outline the union of the "insides" of the provided paths, or the > intersections, or whatnot. In Paper.js we make the distinction between CompoundPath and Path, which stems from working with Adobe Illustrator. Path describes one open or closed loop of Segments connected by Curves (each Segment having a point, handleIn and handleOut attribute, the Curve in between two Segments in fact just describe the same information in a different way). CompoundPath then are simply groups of Path items, which are rendered together with the same color and fill rule. It's very different to what SVG does, but this distinction has helped us reduce the complexity of what Path needs to do a lot, and it really helps when manipulating Path items directly. >> Path, Shape, Gradient, Matrix all seem way too generic, and will >> definitely clash with many libraries. > > It's not that clear that this is true. There really haven't been that many > reports of clashes, all things considered -- and it's not clear that > Path2D, GraphicsPath, CanvasPath, or any number of other variants, would > really be any more or less likely to clash. Shape, Matrix and Gradient are all constructors that we have in Paper.js as well. >> Well I know there will be problems: Paper.js has a Path class since >> 2011, and these will clash when using the library without scoping, which >> is what many people do. > > How many is many? How high-profile are they? Google, Foursquare and the NY Times have used Paper.js for interactive features, games and dynamic graphics on their websites, just to name a few. I'm not sure if they were used in a scope manner or not, though. >> I doubt we're the only library that clashes. > > Do we have any data on this? Do any libraries use Path2D? I've been looking for Path2D + JavaScript on Google Code search and Github, and have not found one single occurrence. The idea for the name comes from Java, where all 2D geometric classes have 2D behind their name. I'm pretty confident there would not be a single clash. Best, J?rg From simon.sarris at gmail.com Fri Sep 20 11:16:30 2013 From: simon.sarris at gmail.com (Simon Sarris) Date: Fri, 20 Sep 2013 14:16:30 -0400 Subject: [whatwg] Canvas - Somewhat inconsistent rules in the spec for drawImage Message-ID: <CAA5isUZnmG9BOL=oF8Xpunrw6DgF6no50WUTkvDH7ORK5ui5Sw@mail.gmail.com> Summary: You can draw zero-sized Images and objects with zero-sized source rects to the canvas context. You cannot draw zero-sized Canvases, you get an InvalidStateError. According to the spec this is right, but I think there should be more consistency in handling these cases. drawImage can be called with an Image, a Canvas, or a Video element, so you typically see calls like: ctx.drawImage(imageReference, 0, 0); ctx.drawImage(canvasReference, 0, 0); 99% of the time you can think of them as interchangeable. Let's talk about our 1%ers. I came across an interesting (and none-too-useful, but we can blame the browser for that) error when drawing a canvas with zero width and height: inMemoryCanvas.width = 0; // Uncaught InvalidStateError: An attempt was made to use an object that is not, or is no longer, usable. ctx.drawImage(inMemoryCanvas, 0, 0); According to the specification, this is the right error to throw: > If the image argument is an HTMLCanvasElement object with either a horizontal dimension or a vertical dimension equal to zero, then throw an InvalidStateError exception, return aborted, and abort these steps. The bothersome thing is that: 1. Zero-sized Images do not have any such error 2. calling drawImage with a source rectangle, using context.drawImage(image, sx, sy, sw, sh, dx, dy, dw, dh), when the source rectangle has zero width or height, does not give an error. Per the spec: > If one of the sw or sh arguments is zero, abort these steps. Nothing is painted. So zero-sized sources are fine if they are an HTMLImageElement or a source rectangle, but not fine if they are HTMLCanvasElement. This seems inconsistent, and the error given seems odd too. It's not very descriptive and not immediately clear what is wrong. This issue came to my attention because a friend asked for help, who was drawing randomly-sized canvases onto a main context. He suspected InvalidStateError was some bizarre closure bug where part of the canvas state was being lost, but of course the truth was more mundane - some but not all zero-sized objects cannot be drawn to the canvas context. Anywho, I recommend either considering all zero-sized sources as invalid, and perhaps giving a more descriptive error, or simply allowing a zero-sized canvas to be a valid drawImage argument so that it may run its natural course (draw nothing), just like Image and zero-sized source rect arguments. Simon Sarris ~~~ For reference, below is a simple example showing both a zero-sized img being drawn and a zero-sized canvas: // this <img>'s width/height/naturalWidth/naturalHeight are all zero: var img = document.createElement('img'); // Totally fine, no error: ctx.drawImage(img, 0, 0); var inMemoryCanvas = document.createElement('canvas'); inMemoryCanvas.width = 0; inMemoryCanvas.height = 0; // Uncaught InvalidStateError: An attempt was made to use an object that is not, or is no longer, usable. ctx.drawImage(inMemoryCanvas, 0, 0); From lists at scratchdisk.com Fri Sep 20 11:16:36 2013 From: lists at scratchdisk.com (=?iso-8859-1?Q?J=FCrg_Lehni?=) Date: Fri, 20 Sep 2013 11:16:36 -0700 Subject: [whatwg] Questions regarding Path object In-Reply-To: <7DE99F3A-5842-4A8B-9FA5-A1799091FE24@scratchdisk.com> References: <0E6F0444-AB1B-4FFC-B62C-E14F3DB74BA1@scratchdisk.com> <CAGN7qDB_CM=KTaW5+cB9FoYSuCK93kNvNMru8FVUh4BLxLKezw@mail.gmail.com> <C702CEA4-0D06-4E2B-9EFF-DC93DEF58310@scratchdisk.com> <CAGN7qDABijW_nB=+n4AKNwc6BwKGDY99G9KC0KCJheQyCdDN2w@mail.gmail.com> <82C5F947-BDF4-45A1-9701-3857E2194C60@scratchdisk.com> <CAGN7qDAvnfCEqh7Cp8hgo0kWW11wpJE0UBwTaghwkPB7tya5iQ@mail.gmail.com> <18E5B2F8-5A03-4486-9EEE-CEC0FB3E80EE@scratchdisk.com> <51C0416D.2060905@opera.com> <alpine.DEB.2.00.1308201808080.27209@ps20323.dreamhostps.com> <7DE99F3A-5842-4A8B-9FA5-A1799091FE24@scratchdisk.com> Message-ID: <FCC13E51-06A9-47EB-9DB3-B7E5097DACB8@scratchdisk.com> PS: iOS 7 is barely released, but the first bug reports are already coming in, because the new Mobile Safari now defines Path, and clashes: https://twitter.com/danetag/status/380636739251220480 From kangax at gmail.com Fri Sep 20 11:33:41 2013 From: kangax at gmail.com (Juriy Zaytsev) Date: Fri, 20 Sep 2013 20:33:41 +0200 Subject: [whatwg] Questions regarding Path object In-Reply-To: <FCC13E51-06A9-47EB-9DB3-B7E5097DACB8@scratchdisk.com> References: <0E6F0444-AB1B-4FFC-B62C-E14F3DB74BA1@scratchdisk.com> <CAGN7qDB_CM=KTaW5+cB9FoYSuCK93kNvNMru8FVUh4BLxLKezw@mail.gmail.com> <C702CEA4-0D06-4E2B-9EFF-DC93DEF58310@scratchdisk.com> <CAGN7qDABijW_nB=+n4AKNwc6BwKGDY99G9KC0KCJheQyCdDN2w@mail.gmail.com> <82C5F947-BDF4-45A1-9701-3857E2194C60@scratchdisk.com> <CAGN7qDAvnfCEqh7Cp8hgo0kWW11wpJE0UBwTaghwkPB7tya5iQ@mail.gmail.com> <18E5B2F8-5A03-4486-9EEE-CEC0FB3E80EE@scratchdisk.com> <51C0416D.2060905@opera.com> <alpine.DEB.2.00.1308201808080.27209@ps20323.dreamhostps.com> <7DE99F3A-5842-4A8B-9FA5-A1799091FE24@scratchdisk.com> <FCC13E51-06A9-47EB-9DB3-B7E5097DACB8@scratchdisk.com> Message-ID: <CAPdhPzkcXTwGd8XF1rKZ7u5RrRbB6P9eB1dEWu8ajCj6K7Z+Vg@mail.gmail.com> FWIW, in Fabric.js [1], everything is scoped under global `fabric` object. `fabric.Path`, `fabric.Circle`, `fabric.Color`, etc. For any third-party library in a cross-browser environment, this has been the only sane strategy of avoiding conflicts and keeping things scalable. We learned about "global everything" problems back in the Prototype.js [2] days :) After all, "injection" could always be done on a local level: (function() { var Path = fabric.Path, Circle = fabric.Circle, etc. ... new Path(); ... })(); I also don't see much simplicity in using global names. It's just irresponsible and asking for trouble. [1] http://fabricjs.com [2] http://prototypejs.org -- kangax On Fri, Sep 20, 2013 at 8:16 PM, J?rg Lehni <lists at scratchdisk.com> wrote: > PS: iOS 7 is barely released, but the first bug reports are already coming > in, because the new Mobile Safari now defines Path, and clashes: > > https://twitter.com/danetag/status/380636739251220480 > > From junov at google.com Fri Sep 20 11:40:24 2013 From: junov at google.com (Justin Novosad) Date: Fri, 20 Sep 2013 14:40:24 -0400 Subject: [whatwg] Canvas - Somewhat inconsistent rules in the spec for drawImage In-Reply-To: <CAA5isUZnmG9BOL=oF8Xpunrw6DgF6no50WUTkvDH7ORK5ui5Sw@mail.gmail.com> References: <CAA5isUZnmG9BOL=oF8Xpunrw6DgF6no50WUTkvDH7ORK5ui5Sw@mail.gmail.com> Message-ID: <CABpaAqTCJD-idcS9qYGgFxb4-7Bi7B84R-Pm1hNh-zyEUr9=sw@mail.gmail.com> On Fri, Sep 20, 2013 at 2:16 PM, Simon Sarris <simon.sarris at gmail.com>wrote: > > Anywho, I recommend either considering all zero-sized sources as invalid, > and perhaps giving a more descriptive error, or simply allowing a > zero-sized canvas to be a valid drawImage argument so that it may run its > natural course (draw nothing), just like Image and zero-sized source rect > arguments. > If we do anything, it should be the latter (draw nothing) to avoid breaking existing apps. From robert at ocallahan.org Fri Sep 20 15:13:43 2013 From: robert at ocallahan.org (Robert O'Callahan) Date: Sat, 21 Sep 2013 10:13:43 +1200 Subject: [whatwg] Canvas - Somewhat inconsistent rules in the spec for drawImage In-Reply-To: <CABpaAqTCJD-idcS9qYGgFxb4-7Bi7B84R-Pm1hNh-zyEUr9=sw@mail.gmail.com> References: <CAA5isUZnmG9BOL=oF8Xpunrw6DgF6no50WUTkvDH7ORK5ui5Sw@mail.gmail.com> <CABpaAqTCJD-idcS9qYGgFxb4-7Bi7B84R-Pm1hNh-zyEUr9=sw@mail.gmail.com> Message-ID: <CAOp6jLaE5v8pU+aJrwjk5rUVJJLZOrROnadmoP7EnVrFS+h+4w@mail.gmail.com> On Sat, Sep 21, 2013 at 6:40 AM, Justin Novosad <junov at google.com> wrote: > If we do anything, it should be the latter (draw nothing) to avoid breaking > existing apps. > I agree. I commented on this a while ago, and I still think it's simpler and more robust for drawing a zero-size "anything" to just draw nothing. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * From anewpage.media at gmail.com Fri Sep 20 15:36:53 2013 From: anewpage.media at gmail.com (Brian Blakely) Date: Fri, 20 Sep 2013 18:36:53 -0400 Subject: [whatwg] Add <input> "Switch" Type Message-ID: <CAJGQg4G0OphnZocf_HjdniDDgN4FZoTd3oBHQkDz0OcXDvR66A@mail.gmail.com> "iPhone OS" introduced the switch control (http://i.imgur.com/TA79fo2.png) in 2007. Since then, there have been many attempts to recreate this on the Web Platform by hacking existing control types and using a lot of meaningless markup, to varying degrees of success. The proposal is to add a "switch" <input> type. When it is active, the UA should render a switch control. It looks like this: <input type="switch" on /> The "on" attribute indicates whether the switch is in its "on" or "off" state. There is no "off" attribute, as switches are off by default. The values corresponding to each state are true and false, respectively. List of OSs that implement switch controls (likely incomplete): - Windows 8 - OS X - iOS - Android - Blackberry OS - Windows Phone The major advantage here, as with all controls in HTML, is that the behavior and default appearance of the control is guaranteed to be consistent for a user across the Web, and likely match their host OS as well. This is sure to be a very attractive and convenient solution for authors. From jackalmage at gmail.com Fri Sep 20 15:44:55 2013 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Fri, 20 Sep 2013 15:44:55 -0700 Subject: [whatwg] Add <input> "Switch" Type In-Reply-To: <CAJGQg4G0OphnZocf_HjdniDDgN4FZoTd3oBHQkDz0OcXDvR66A@mail.gmail.com> References: <CAJGQg4G0OphnZocf_HjdniDDgN4FZoTd3oBHQkDz0OcXDvR66A@mail.gmail.com> Message-ID: <CAAWBYDCScmVx46zSL0TZ0_L_AWWWfB_Oq2Ps3q7JfMJNTr4XAg@mail.gmail.com> On Fri, Sep 20, 2013 at 3:36 PM, Brian Blakely <anewpage.media at gmail.com> wrote: > "iPhone OS" introduced the switch control (http://i.imgur.com/TA79fo2.png) > in 2007. Since then, there have been many attempts to recreate this on the > Web Platform by hacking existing control types and using a lot of > meaningless markup, to varying degrees of success. > > The proposal is to add a "switch" <input> type. When it is active, the UA > should render a switch control. It looks like this: > > <input type="switch" on /> > > The "on" attribute indicates whether the switch is in its "on" or "off" > state. There is no "off" attribute, as switches are off by default. The > values corresponding to each state are true and false, respectively. > > List of OSs that implement switch controls (likely incomplete): > > - Windows 8 > - OS X > - iOS > - Android > - Blackberry OS > - Windows Phone > > The major advantage here, as with all controls in HTML, is that the > behavior and default appearance of the control is guaranteed to be > consistent for a user across the Web, and likely match their host OS as > well. This is sure to be a very attractive and convenient solution for > authors. This is just a "checkbox" input with different styling, yes? ~TJ From anewpage.media at gmail.com Fri Sep 20 16:03:06 2013 From: anewpage.media at gmail.com (Brian M. Blakely) Date: Fri, 20 Sep 2013 19:03:06 -0400 Subject: [whatwg] Add <input> "Switch" Type In-Reply-To: <CAAWBYDCScmVx46zSL0TZ0_L_AWWWfB_Oq2Ps3q7JfMJNTr4XAg@mail.gmail.com> References: <CAJGQg4G0OphnZocf_HjdniDDgN4FZoTd3oBHQkDz0OcXDvR66A@mail.gmail.com> <CAAWBYDCScmVx46zSL0TZ0_L_AWWWfB_Oq2Ps3q7JfMJNTr4XAg@mail.gmail.com> Message-ID: <17196F15-F100-486D-978D-A7CF22944E58@gmail.com> I was contemplating whether to propose a new input type, or an attribute valid only for checkboxes. But it isn't a checkbox, so I went with a new type value. You can choose to slide the switch or click it in most OS implementations, so even the behavior is different from a checkbox. I consider it a different input type the way "range" and "number" are different, despite being semantically identical. > On Sep 20, 2013, at 6:44 PM, "Tab Atkins Jr." <jackalmage at gmail.com> wrote: > >> On Fri, Sep 20, 2013 at 3:36 PM, Brian Blakely <anewpage.media at gmail.com> wrote: >> "iPhone OS" introduced the switch control (http://i.imgur.com/TA79fo2.png) >> in 2007. Since then, there have been many attempts to recreate this on the >> Web Platform by hacking existing control types and using a lot of >> meaningless markup, to varying degrees of success. >> >> The proposal is to add a "switch" <input> type. When it is active, the UA >> should render a switch control. It looks like this: >> >> <input type="switch" on /> >> >> The "on" attribute indicates whether the switch is in its "on" or "off" >> state. There is no "off" attribute, as switches are off by default. The >> values corresponding to each state are true and false, respectively. >> >> List of OSs that implement switch controls (likely incomplete): >> >> - Windows 8 >> - OS X >> - iOS >> - Android >> - Blackberry OS >> - Windows Phone >> >> The major advantage here, as with all controls in HTML, is that the >> behavior and default appearance of the control is guaranteed to be >> consistent for a user across the Web, and likely match their host OS as >> well. This is sure to be a very attractive and convenient solution for >> authors. > > This is just a "checkbox" input with different styling, yes? > > ~TJ From alonisser at gmail.com Sun Sep 22 02:51:06 2013 From: alonisser at gmail.com (alonn) Date: Sun, 22 Sep 2013 11:51:06 +0200 Subject: [whatwg] Add <input> "Switch" Type Message-ID: <CAN3noj39k=g96bEaDCe2dgB1v+qz8NBStfuY84mQOkjBjGJE3A@mail.gmail.com> +1 from the web author perspective. would be nice if this wasn't so "Hackish" and if the look was more consistent. I do agree that this could be achieved (maybe more backwards compatibly) with an "switch" attribute on the ```checkbox``` input type. Twitter:@alonisser <https://twitter.com/alonisser> LinkedIn Profile <http://www.linkedin.com/in/alonisser> Facebook <https://www.facebook.com/alonisser> *Tech blog:*4p-tech.co.il/blog *Personal Blog:*degeladom.wordpress.com Tel:972-54-6734469 On Sat, Sep 21, 2013 at 9:06 PM, <whatwg-request at lists.whatwg.org> wrote: > Send whatwg mailing list submissions to > whatwg at lists.whatwg.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org > or, via email, send a message with subject or body 'help' to > whatwg-request at lists.whatwg.org > > You can reach the person managing the list at > whatwg-owner at lists.whatwg.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of whatwg digest..." > > When replying to digest messages, please please PLEASE update the subject > line so it isn't the digest subject line. > Today's Topics: > > 1. Re: Canvas - Somewhat inconsistent rules in the spec for > drawImage (Robert O'Callahan) > 2. Add <input> "Switch" Type (Brian Blakely) > 3. Re: Add <input> "Switch" Type (Tab Atkins Jr.) > 4. Re: Add <input> "Switch" Type (Brian M. Blakely) > > > ---------- Forwarded message ---------- > From: "Robert O'Callahan" <robert at ocallahan.org> > To: Justin Novosad <junov at google.com> > Cc: Simon Sarris <simon.sarris at gmail.com>, WHATWG List <whatwg at whatwg.org> > Date: Sat, 21 Sep 2013 10:13:43 +1200 > Subject: Re: [whatwg] Canvas - Somewhat inconsistent rules in the spec for > drawImage > On Sat, Sep 21, 2013 at 6:40 AM, Justin Novosad <junov at google.com> wrote: > > > If we do anything, it should be the latter (draw nothing) to avoid > breaking > > existing apps. > > > > I agree. I commented on this a while ago, and I still think it's simpler > and more robust for drawing a zero-size "anything" to just draw nothing. > > Rob > -- > Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni > le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa > stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, > 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp > waanndt wyeonut thoo mken.o w * > * > > > > ---------- Forwarded message ---------- > From: Brian Blakely <anewpage.media at gmail.com> > To: "whatwg at lists.whatwg.org" <whatwg at lists.whatwg.org> > Cc: > Date: Fri, 20 Sep 2013 18:36:53 -0400 > Subject: [whatwg] Add <input> "Switch" Type > "iPhone OS" introduced the switch control (http://i.imgur.com/TA79fo2.png) > in 2007. Since then, there have been many attempts to recreate this on the > Web Platform by hacking existing control types and using a lot of > meaningless markup, to varying degrees of success. > > The proposal is to add a "switch" <input> type. When it is active, the UA > should render a switch control. It looks like this: > > <input type="switch" on /> > > The "on" attribute indicates whether the switch is in its "on" or "off" > state. There is no "off" attribute, as switches are off by default. The > values corresponding to each state are true and false, respectively. > > List of OSs that implement switch controls (likely incomplete): > > - Windows 8 > - OS X > - iOS > - Android > - Blackberry OS > - Windows Phone > > The major advantage here, as with all controls in HTML, is that the > behavior and default appearance of the control is guaranteed to be > consistent for a user across the Web, and likely match their host OS as > well. This is sure to be a very attractive and convenient solution for > authors. > > > > ---------- Forwarded message ---------- > From: "Tab Atkins Jr." <jackalmage at gmail.com> > To: Brian Blakely <anewpage.media at gmail.com> > Cc: "whatwg at lists.whatwg.org" <whatwg at lists.whatwg.org> > Date: Fri, 20 Sep 2013 15:44:55 -0700 > Subject: Re: [whatwg] Add <input> "Switch" Type > On Fri, Sep 20, 2013 at 3:36 PM, Brian Blakely <anewpage.media at gmail.com> > wrote: > > "iPhone OS" introduced the switch control ( > http://i.imgur.com/TA79fo2.png) > > in 2007. Since then, there have been many attempts to recreate this on > the > > Web Platform by hacking existing control types and using a lot of > > meaningless markup, to varying degrees of success. > > > > The proposal is to add a "switch" <input> type. When it is active, the > UA > > should render a switch control. It looks like this: > > > > <input type="switch" on /> > > > > The "on" attribute indicates whether the switch is in its "on" or "off" > > state. There is no "off" attribute, as switches are off by default. The > > values corresponding to each state are true and false, respectively. > > > > List of OSs that implement switch controls (likely incomplete): > > > > - Windows 8 > > - OS X > > - iOS > > - Android > > - Blackberry OS > > - Windows Phone > > > > The major advantage here, as with all controls in HTML, is that the > > behavior and default appearance of the control is guaranteed to be > > consistent for a user across the Web, and likely match their host OS as > > well. This is sure to be a very attractive and convenient solution for > > authors. > > This is just a "checkbox" input with different styling, yes? > > ~TJ > > > > ---------- Forwarded message ---------- > From: "Brian M. Blakely" <anewpage.media at gmail.com> > To: "Tab Atkins Jr." <jackalmage at gmail.com> > Cc: "whatwg at lists.whatwg.org" <whatwg at lists.whatwg.org> > Date: Fri, 20 Sep 2013 19:03:06 -0400 > Subject: Re: [whatwg] Add <input> "Switch" Type > I was contemplating whether to propose a new input type, or an attribute > valid only for checkboxes. But it isn't a checkbox, so I went with a new > type value. You can choose to slide the switch or click it in most OS > implementations, so even the behavior is different from a checkbox. > > I consider it a different input type the way "range" and "number" are > different, despite being semantically identical. > > > > On Sep 20, 2013, at 6:44 PM, "Tab Atkins Jr." <jackalmage at gmail.com> > wrote: > > > >> On Fri, Sep 20, 2013 at 3:36 PM, Brian Blakely < > anewpage.media at gmail.com> wrote: > >> "iPhone OS" introduced the switch control ( > http://i.imgur.com/TA79fo2.png) > >> in 2007. Since then, there have been many attempts to recreate this on > the > >> Web Platform by hacking existing control types and using a lot of > >> meaningless markup, to varying degrees of success. > >> > >> The proposal is to add a "switch" <input> type. When it is active, the > UA > >> should render a switch control. It looks like this: > >> > >> <input type="switch" on /> > >> > >> The "on" attribute indicates whether the switch is in its "on" or "off" > >> state. There is no "off" attribute, as switches are off by default. > The > >> values corresponding to each state are true and false, respectively. > >> > >> List of OSs that implement switch controls (likely incomplete): > >> > >> - Windows 8 > >> - OS X > >> - iOS > >> - Android > >> - Blackberry OS > >> - Windows Phone > >> > >> The major advantage here, as with all controls in HTML, is that the > >> behavior and default appearance of the control is guaranteed to be > >> consistent for a user across the Web, and likely match their host OS as > >> well. This is sure to be a very attractive and convenient solution for > >> authors. > > > > This is just a "checkbox" input with different styling, yes? > > > > ~TJ > > > _______________________________________________ > whatwg mailing list > whatwg at lists.whatwg.org > http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org > > From yoav at yoav.ws Sun Sep 22 04:05:20 2013 From: yoav at yoav.ws (Yoav Weiss) Date: Sun, 22 Sep 2013 13:05:20 +0200 Subject: [whatwg] The srcset attribute - some implementation feedback & questions Message-ID: <CACj=BEj0CLEP1BjG1-8G=b9ruzXVCkG2DBqx99PDSp6C6fCsSw@mail.gmail.com> I've recently ported the WebKit srcset implementation into Blink, and pretty much rewrote it in the process. I'd like to provide some feedback and ask for clarifications, in order to improve the implementation's spec[1] compliance. Below I'll discuss the algorithm's step and points that I'd like clarifications on. Step 5 ---------- What happens when the srcset attribute is of the form "candidate1.png, candidate2.png 2x"? As far as I understand it, according to the spec it results in a single image candidate url "candidate1.png," followed by the descriptors "candidate2.png 2x", which is probably not what the author intended. As a note, both WebKit & Blink implementations diverge from the spec here, by adding a "check if the URL's last char is ',' and if so, continue without trying to parse out descriptors" step. This also enables the implementations to ignore empty candidates such as "candidate1.png 1x, , , , , candidate2.png 2x". A similar case of <img srcset="candidate1.png,candidate2.png 2x"> results in the image candidate URL being "candidate1.png,candidate2.png". Is that the correct behavior? I'm not sure what should be the result here (since splitting on commas will break data URIs), but I'm certain this will be a source of confusion for authors. Step 13.6 ------------ What happens when one of the valid qualifier characters is followed by other non qualifier chars? e.g.is "2xbla" a valid descriptor? What happens when one of the valid qualifier characters is followed by another qualifier char? e.g.is "2xwh" a valid descriptor? Does it set all three variables to 2? What happens to invalid descriptors? If I understand correctly, invalid descriptors should just be ignored so that "2x 500tt bla" will results in a density of 2, width of infinity and height of infinity. Is that correct? Yoav [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#processing-the-image-candidates From simonp at opera.com Mon Sep 23 02:40:05 2013 From: simonp at opera.com (Simon Pieters) Date: Mon, 23 Sep 2013 11:40:05 +0200 Subject: [whatwg] The srcset attribute - some implementation feedback & questions In-Reply-To: <CACj=BEj0CLEP1BjG1-8G=b9ruzXVCkG2DBqx99PDSp6C6fCsSw@mail.gmail.com> References: <CACj=BEj0CLEP1BjG1-8G=b9ruzXVCkG2DBqx99PDSp6C6fCsSw@mail.gmail.com> Message-ID: <op.w3uyg3y8idj3kv@simons-macbook-pro.local> On Sun, 22 Sep 2013 13:05:20 +0200, Yoav Weiss <yoav at yoav.ws> wrote: > I've recently ported the WebKit srcset implementation into Blink, and > pretty much rewrote it in the process. > > I'd like to provide some feedback and ask for clarifications, in order to > improve the implementation's spec[1] compliance. Below I'll discuss the > algorithm's step and points that I'd like clarifications on. > > Step 5 > ---------- > What happens when the srcset attribute is of the form "candidate1.png, > candidate2.png 2x"? > As far as I understand it, according to the spec it results in a single > image candidate url "candidate1.png," followed by the descriptors > "candidate2.png 2x", Correct. > which is probably not what the author intended. > As a note, both WebKit & Blink implementations diverge from the spec > here, > by adding a "check if the URL's last char is ',' and if so, continue > without trying to parse out descriptors" step. This also enables the > implementations to ignore empty candidates such as "candidate1.png 1x, , > , > , , candidate2.png 2x". Maybe we can change the spec to do that. If the author wants to use a URL with a comma at the end, it can be percent-escaped. > A similar case of <img srcset="candidate1.png,candidate2.png 2x"> results > in the image candidate URL being "candidate1.png,candidate2.png". Is that > the correct behavior? Yes. > I'm not sure what should be the result here (since splitting on commas > will > break data URIs), but I'm certain this will be a source of confusion for > authors. > > Step 13.6 > ------------ > What happens when one of the valid qualifier characters is followed by > other non qualifier chars? e.g.is "2xbla" a valid descriptor? It doesn't match any of the three cases in that step, so it gets dropped on the floor. > What happens when one of the valid qualifier characters is followed by > another qualifier char? e.g.is "2xwh" a valid descriptor? Same as above. > Does it set all > three variables to 2? No. > What happens to invalid descriptors? If I understand correctly, invalid > descriptors should just be ignored so that "2x 500tt bla" will results > in a > density of 2, width of infinity and height of infinity. > Is that correct? Yes. Step 13.6. could say "Otherwise, do nothing", but that's implied. > Yoav > > [1] > http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#processing-the-image-candidates -- Simon Pieters Opera Software From bhsu at google.com Mon Sep 23 13:25:02 2013 From: bhsu at google.com (Bolin Hsu) Date: Mon, 23 Sep 2013 13:25:02 -0700 Subject: [whatwg] Type strings to specify number of AAC audio channels Message-ID: <CAGYei4mLTcZHSbEoHcK+GfEpKR+cnkayODXM+pPvXGyen0sP4Q@mail.gmail.com> Since the royalty for decoding surround sound AAC is higher than stereo AAC, some platforms can decode stereo AAC but not surround sound AAC. But the type string passed to HTMLMediaElement.canPlayType(type) doesn't specify number of channels. I discussed this with some colleagues before I found this list. Has this been covered by standard? Below are some ideas came up during discussion: - Use a new codec string, such as HTMLMediaElement.canPlayType('audio/mp4; codecs="aac51"') - Add a new parameter, such as HTMLMediaElement.canPlayTYpe('audio/mp4; codecs="mp4a.40.2", channels="6") - Add new element for platform configuration. Some platforms can only output stereo audio, so the surround sound is down mixed to stereo. This can potentially query the platform if it can really output 6 simultaneous audio streams, amount other things: HTMLNewElement.getCapability('audio') Thanks, Bolin From ian at hixie.ch Mon Sep 23 13:25:40 2013 From: ian at hixie.ch (Ian Hickson) Date: Mon, 23 Sep 2013 20:25:40 +0000 (UTC) Subject: [whatwg] Window and WindowProxy In-Reply-To: <5211BE6E.1000608@mit.edu> References: <520112A5.8070707@mit.edu> <alpine.DEB.2.00.1308061813150.27623@ps20323.dreamhostps.com> <52014495.8070609@mit.edu> <alpine.DEB.2.00.1308072112450.27623@ps20323.dreamhostps.com> <5203162F.8000006@mit.edu> <alpine.DEB.2.00.1308080607150.27623@ps20323.dreamhostps.com> <52037F6C.2000805@mit.edu> <alpine.DEB.2.00.1308081831300.27623@ps20323.dreamhostps.com> <5203F3B0.4000908@mit.edu> <alpine.DEB.2.00.1308082052130.27623@ps20323.dreamhostps.com> <52041E62.6050007@mit.edu> <alpine.DEB.2.00.1308132005090.27623@ps20323.dreamhostps.com> <5211BE6E.1000608@mit.edu> Message-ID: <alpine.DEB.2.00.1309231909460.12199@ps20323.dreamhostps.com> On Mon, 19 Aug 2013, Boris Zbarsky wrote: > > What Gecko does is that there is a set of canonical prototypes (the DOM > ones, Object.prototype, Array.prototype, etc) per global. The effective > script origin of a global is mutable. The effect of changing the > effective script origin of a global on the prototypes associated with > that global is that nothing at all happens to them: they stay as the > same objects. > > Now what happens to actual objects and their proto chains when they go from > being same-effective-script-origin to not or back... I'm not actually sure. > Bobby Holley probably knows, though; I think this is basically the situation > he's talking about in > <https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701#c38>. Isn't the answer to this question basically the answer to this thread? This new ES5/ES6 stuff all goes over my head, to be honest. I can't wrap my head around the implications, especially in a multi-global (let alone multi-origin) environment. Is there any chance people who do understand this stuff can tell me what it should do? Ideally people from more than one browser vendor, since all the browsers disagree and I get really different answers when I speak 1:1 to individuals from various browser vendors. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Mon Sep 23 13:35:25 2013 From: ian at hixie.ch (Ian Hickson) Date: Mon, 23 Sep 2013 20:35:25 +0000 (UTC) Subject: [whatwg] Forms-related feedback In-Reply-To: <CADnb78iNqA1d95Nb2HY3Djf0hu4KT5HHk_abk3jC6_W3r=xQOw@mail.gmail.com> References: <50AB6E5F.5050803@lamouri.fr> <Pine.LNX.4.64.1211201954290.26354@ps20323.dreamhostps.com> <CAGH7WqGBtP=kP4pBBmeY5cGT=t0W-1gMt+Efx_umEs9rMGYG4Q@mail.gmail.com> <alpine.DEB.2.00.1307122134270.30095@ps20323.dreamhostps.com> <CAGH7WqHPBsEPMvNhHjV9xE6GXOyVngykHnjeTiWuLLXtJH2tnA@mail.gmail.com> <CADnb78iNqA1d95Nb2HY3Djf0hu4KT5HHk_abk3jC6_W3r=xQOw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309232026140.12199@ps20323.dreamhostps.com> On Wed, 21 Aug 2013, TAMURA, Kent wrote: > On Sat, Jul 13, 2013 at 6:39 AM, Ian Hickson <ian at hixie.ch> wrote: > > On Wed, 9 Jan 2013, TAMURA, Kent wrote: > > > On Wed, Nov 21, 2012 at 7:51 AM, Ian Hickson <ian at hixie.ch> wrote: > > > > On Fri, 7 Sep 2012, TAMURA, Kent wrote: > > > > > > > > > > * For date, datetime, datetime-local, month, time, week, the > > > > > attribute returns a string in a field. If a field is > > > > > text-editable, it should return user-editing string like email > > > > > and number. If a field has a fixed localized date/time string > > > > > chosen by a date/time picker, the attribute should return the > > > > > localized string. [...] > > > > > > > > > > - We can enable text field selection APIs for email, number, and > > > > > other types > > > > > > > > How would this work when the control isn't a text control? I don't > > > > understand. For example, consider a date control that is actually > > > > three separate text fields (year month day); how do you envisage > > > > the selection API working and how would rawValue help with this? > > > > > > I think it's ok that rawValue doesn't work with form controls > > > without any text. One of use cases of rawValue would be to handle > > > user input errors. I think non-text form controls should be clever > > > enough to avoid bad user input. For example, users can't set bad > > > values to input[type=range]. > > > > I still don't understand how this would work. You suggest that it > > should work for type=date, but how? What happens when it's mutated by > > script, for instance? I really don't understand the purpose here or > > how it would work to achieve that purpose. > > As for type=date, rawValue should return what a user see. What if the user sees a calendar with a date circled? Or the string "your birthday"? (Exposing that would be a privacy violation.) Or what if the user doesn't see anything (because it's not a visual UA), but every time the user focuses it, the user agent plays a tune from one of Vivaldi's four seasons, followed by a trill to indicate how far into the season the date is? > Value set by script or not doesn't matter. I mean, how would the user agent parse the script's new value. > I saw some questions/requests of a way to get a localized date string in > crbug.com and stackoverflow.com. One of reasons one wanted to get it > was that there are no ways for script to get localized date format used > in type=date. One wanted to get the format to use consistent date format > in a web page, another wanted to get the format to focus on specific > field in type=date (Note that a type=date instance in Google Chrome > contains multiple focus targets.) Providing localisation is definitely something we should do, but rawValue isn't a sane way to do it. You don't want to have the "format a date" API be "create an <input> element, sets its value, and read it back". > As for type=number, I heard a web author wanted to get invalid value > typed by a user in order to show friendly error message without HTML > interactive form validation. The point of type=number is that the browser can do this, no need to reimplement it. (If an author does want to reimplement it, Web Components are presumably the long-term solution: reimplement the widget.) > > > > On Tue, 11 Sep 2012, TAMURA, Kent wrote: > > > > > > > > > Yes, I'd like to enable selection API for at least type=email > > > > > and type=number. All of their existing implementations are text > > > > > fields. I haven't seen a request to suport selection API for > > > > > type=email, etc.. However lack of selection API looks a defect > > > > > to me. > > > > > > > > Why does the page need to touch the selection? > > > > > > It must be same as input[type=text]. e.g. > > > - A page author wants to select the whole value or nothing of an > > > email form control when it gets focus. > > > > Why is that a valid thing for a page to be doing? The browser should > > take care of doing that, not the page. If the page does it, it'll be > > different on each page and the user will get confused. > > We can't force it. Web authors do what they want. We can force it. If we don't provide the API, the author can't do it. > https://code.google.com/p/chromium/issues/detail?id=263910#c3 > This is an actual case. I talked with him, and he said <datalist> > didn't work in his case because he wanted to show images on choices. The demo he gives is: https://chromium.googlecode.com/issues/attachment?aid=2639100003000&name=caret.html&token=tDkJ1CbBJ1hhXbsgb9Y0MRMzlks%3A1379968341420 If people want to reimplement widgets, then we should make sure Web Components can support their particular widget desires. I don't think it makes sense for us to make the default widgets be able to support every weird thing people want to do. > > > - A user entered an email address with unacceptable domain name. > > > A page author wants to move the caret to the beginning of the > > > domain name. > > > > How is that possible in the case of a custom e-mail widget where the > > e-mail address isn't shown, but a user picture and name is shown > > instead? > > I think rawValue isn't necessary in such UI. However all of existing > type=email implementation is a text field. On Wed, 21 Aug 2013, Anne van Kesteren wrote: > > If we start doing this (and other things you proposed) we'll constrain > future implementation strategies for this control. And other > implementations might be forced to follow particular conventions in > order to not break sites. That doesn't seem exactly ideal. Exactly. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From bzbarsky at MIT.EDU Mon Sep 23 13:44:47 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Mon, 23 Sep 2013 16:44:47 -0400 Subject: [whatwg] Window and WindowProxy In-Reply-To: <alpine.DEB.2.00.1309231909460.12199@ps20323.dreamhostps.com> References: <520112A5.8070707@mit.edu> <alpine.DEB.2.00.1308061813150.27623@ps20323.dreamhostps.com> <52014495.8070609@mit.edu> <alpine.DEB.2.00.1308072112450.27623@ps20323.dreamhostps.com> <5203162F.8000006@mit.edu> <alpine.DEB.2.00.1308080607150.27623@ps20323.dreamhostps.com> <52037F6C.2000805@mit.edu> <alpine.DEB.2.00.1308081831300.27623@ps20323.dreamhostps.com> <5203F3B0.4000908@mit.edu> <alpine.DEB.2.00.1308082052130.27623@ps20323.dreamhostps.com> <52041E62.6050007@mit.edu> <alpine.DEB.2.00.1308132005090.27623@ps20323.dreamhostps.com> <5211BE6E.1000608@mit.edu> <alpine.DEB.2.00.1309231909460.12199@ps20323.dreamhostps.com> Message-ID: <5240A83F.8010608@mit.edu> On 9/23/13 4:25 PM, Ian Hickson wrote: > Isn't the answer to this question basically the answer to this thread? I've lost track of what the "question" in this thread is... > This new ES5/ES6 stuff all goes over my head, to be honest. I can't wrap > my head around the implications, especially in a multi-global (let alone > multi-origin) environment. OK. > Is there any chance people who do understand this stuff can tell me what > it should do? I'm trying, sort of. ;) > Ideally people from more than one browser vendor, since all > the browsers disagree and I get really different answers when I speak 1:1 > to individuals from various browser vendors. Mmm... Sounds like we need some venue for standardizing this stuff or something. -Boris From ian at hixie.ch Wed Sep 25 16:23:36 2013 From: ian at hixie.ch (Ian Hickson) Date: Wed, 25 Sep 2013 23:23:36 +0000 (UTC) Subject: [whatwg] Navigation and history traversal issues In-Reply-To: <52160486.4040908@ado.is-a-geek.net> References: <CAFWcpZ51Zp-FQD06mHzfdNKbYrgcT9DOB+c12a2vA3EPyGbbHA@mail.gmail.com> <Pine.LNX.4.64.1209172122440.27765@ps20323.dreamhostps.com> <52160486.4040908@ado.is-a-geek.net> Message-ID: <alpine.DEB.2.00.1309232046350.12199@ps20323.dreamhostps.com> On Thu, 22 Aug 2013, Andrew Oakley wrote: > On 19/09/12 01:18, Ian Hickson wrote: > > > > I've changed the spec so that traversing the history by a delta always > > cancels any pending navigations unless you're in the middle of an > > unload, in which case it just aborts the algorithm entirely. > > > > I've also made back()/forward()/go() not work during the document's > > unload handler, since that could be used for griefing. I'm tempted to > > disable it entirely for all docs a la alert(), but I've no idea if > > that's Web- compatible and I suspect not. > > I assume this is where steps 3 and 4 of the "traverse the history by a > delta" algorithm came from. Step 3. Step 4 is about canceling an existing navigation if you hit back. > It's not clear from the spec which browsing context and document these > steps refer to. Is it the "specified browsing context" and the active > document of that context (I think that makes most sense)? Hm. I meant it to be the Document of the History object, but you raise an interesting point. This whole thing is rather poorly defined. I've tried to clear it up. > Additionally it isn't clear which event loop the task should be > associated with. I've tried to clear this up too. It turns out this wasn't taking into account per-frame process isolation, anyway. I had to introduce yet another kind of event loop. This does introduce some race conditions in UAs with more than one event loop per tab, but I don't know what we can do about that without adding in a lot of blocking during traversal, which I am guessing wouldn't be popular. > > Aah, ok. The spec already says that's not allowed. You can't get to > > the History object of a cross-origin Window: > > > > http://www.whatwg.org/specs/web-apps/current-work/#security-window > > > > (I forget what the story is if you get a History object from a > > same-origin Window, then have the browsing context navigated, then use > > the History object you kept around... I expect it is supposed to work > > much as if you were to call it on the new, cross-origin, History > > object, though.) > > The implication here as that you should never be able to do a history > traversal of a browsing context that is not same origin (and so there is > only one event loop to choose from). The "story" about keeping history > objects around seems does not seem to be specified anywhere (so the > assumption was that it should work as normal). > > It looks like some browsers don't let you use history objects you kept > around (they should probably throw an InvalidStateError), others let you > use them if the current document of the relevant browsing context is > same-origin (and should probably throw a SecurityError). > > It's rather awkward to test this, but can we have something in the spec > to prevent cross-origin history traversal? If this is not in the same > section as the "traverse the history by a delta" algorithm can we have a > note to say that this can never happen cross-origin? Well, no, not really, because it can. For example, if you have an iframe that's cross-origin, and it's navigated, and then you call your own History object's back() method, it'll actually traverse that iframe. But a History object of a non-active Document is a different matter... Looks like this will need help from WebIDL. I've filed bug 23359 and marked it as blocked on bug 23358: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23359 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23358 -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From me at kylehuey.com Wed Sep 25 20:00:55 2013 From: me at kylehuey.com (Kyle Huey) Date: Thu, 26 Sep 2013 11:00:55 +0800 Subject: [whatwg] [Workers] CSP and SharedWorkers Message-ID: <CAP045ApN_NPZEO3X=nNbL1eh4rGWJQya3AT49JwW5h2YeVbmJg@mail.gmail.com> It's unclear how SharedWorkers should interact with Content Security Policies. This came up during code review of the SharedWorker implementation in Gecko[0]. There was a public-webappsec thread[1] on this back in May that didn't really reach a conclusion and I'd like to drive towards one here. Because CSPs are associated with a document, and multiple documents can connect to the same SharedWorker, it is unclear which CSP should be used by a SharedWorker. Furthermore, there are plans to introduce Service Workers ( *n?e* Event Pages) which come into existence before any document exists for the origin at all. It seems like the best solution to this problem is to associate a CSP directly with the worker from the headers served when the JS file for the worker is shipped down. Giving them their own CSP solves the "what CSP do I use" problem. I don't have strong feelings about whether or not we should deny a page with a more liberal CSP from connecting to a SharedWorker with a more strict CSP, but I suspect others might. If we choose to do this we should also think about whether we should do the same for regular workers. The same JS file and the same headers being run under different policies if you do Worker(foo.js) and SharedWorker(foo.js) seems unexpected. We could make regular workers default to the document CSP if nothing is specified for backwards compatibility. Thoughts? - Kyle [0] https://bugzilla.mozilla.org/show_bug.cgi?id=643325 [1] http://lists.w3.org/Archives/Public/public-webappsec/2013May/0054.html From annevk at annevk.nl Thu Sep 26 05:53:30 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Thu, 26 Sep 2013 08:53:30 -0400 Subject: [whatwg] [Workers] CSP and SharedWorkers In-Reply-To: <CAP045ApN_NPZEO3X=nNbL1eh4rGWJQya3AT49JwW5h2YeVbmJg@mail.gmail.com> References: <CAP045ApN_NPZEO3X=nNbL1eh4rGWJQya3AT49JwW5h2YeVbmJg@mail.gmail.com> Message-ID: <CADnb78hhcaVj-N+3aboXAPnv+ZKTehKJh5r=8RwMXxT0qQ1nDg@mail.gmail.com> On Wed, Sep 25, 2013 at 11:00 PM, Kyle Huey <me at kylehuey.com> wrote: > Thoughts? What happens today for <iframe>? The load itself seems to be governed by the parent. Does the policy inherit into it? I feel like workers should work like <iframe> as they're essentially their own global objects. -- http://annevankesteren.nl/ From jaffathecake at gmail.com Thu Sep 26 06:57:33 2013 From: jaffathecake at gmail.com (Jake Archibald) Date: Thu, 26 Sep 2013 14:57:33 +0100 Subject: [whatwg] [Workers] CSP and SharedWorkers In-Reply-To: <CADnb78hhcaVj-N+3aboXAPnv+ZKTehKJh5r=8RwMXxT0qQ1nDg@mail.gmail.com> References: <CAP045ApN_NPZEO3X=nNbL1eh4rGWJQya3AT49JwW5h2YeVbmJg@mail.gmail.com> <CADnb78hhcaVj-N+3aboXAPnv+ZKTehKJh5r=8RwMXxT0qQ1nDg@mail.gmail.com> Message-ID: <CAJ5xic8=j61sYjffVj0UEMP5zgMc2sbEr6NX5658Tm4Zb8v4iQ@mail.gmail.com> The registration of a Service Worker is currently only possible via DOM call from an HTML document, so it makes sense for registration to be governed by CSP. There was some discussion here https://github.com/slightlyoff/ServiceWorker/issues/46 So script-src would cover registration, but there was also suggestion that x-domain controllers would be disallowed be default, and enabled by script-src or perhaps an additional controller-src CSP directive. Note, this only covers registration. If http://example.com allows controllers from http://example.co.uk, and successfully calls registerServiceWorker("/*", "http://example.co.uk/service.js"), that controller will be used for all top-level fetches on http://example.com, and all fetches originating from documents on http://example.com, regardless of their CSP headers. The browser will re-fetch (ugrade) and continue to use http://example.co.uk/service.js even if the CSP rules are changed to disallow controllers from that url. But if a page attempts to register a new controller, the url must be allowed by CSP. Does script-src apply to importScripts in Workers currently? The spec doesn't explicitly mention it, feels like it should. I don't have a strong opinion on whether Workers should have their own CSP. Seems sensible for SharedWorkers to obey their own CSP headers and ignore those of the constructing/registering page (except for the actual constructing/registering of course). script-src should apply for importScripts and imported scripts would use the rules of the top-level SharedWorker. connect-src should also apply to fetch ( https://github.com/slightlyoff/ServiceWorker/blob/master/service_worker.ts#L193 ). On 26 September 2013 13:53, Anne van Kesteren <annevk at annevk.nl> wrote: > On Wed, Sep 25, 2013 at 11:00 PM, Kyle Huey <me at kylehuey.com> wrote: > > Thoughts? > > What happens today for <iframe>? The load itself seems to be governed > by the parent. Does the policy inherit into it? I feel like workers > should work like <iframe> as they're essentially their own global > objects. > > > -- > http://annevankesteren.nl/ > From jaffathecake at gmail.com Thu Sep 26 07:28:11 2013 From: jaffathecake at gmail.com (Jake Archibald) Date: Thu, 26 Sep 2013 15:28:11 +0100 Subject: [whatwg] [Workers] CSP and SharedWorkers In-Reply-To: <CAJ5xic8=j61sYjffVj0UEMP5zgMc2sbEr6NX5658Tm4Zb8v4iQ@mail.gmail.com> References: <CAP045ApN_NPZEO3X=nNbL1eh4rGWJQya3AT49JwW5h2YeVbmJg@mail.gmail.com> <CADnb78hhcaVj-N+3aboXAPnv+ZKTehKJh5r=8RwMXxT0qQ1nDg@mail.gmail.com> <CAJ5xic8=j61sYjffVj0UEMP5zgMc2sbEr6NX5658Tm4Zb8v4iQ@mail.gmail.com> Message-ID: <CAJ5xic9wJf54vO9gaGXqhNNZ6LhaTBPhMy3GTab2jk5XgBY+eA@mail.gmail.com> On 26 September 2013 14:57, Jake Archibald <jaffathecake at gmail.com> wrote: > Note, this only covers registration. If http://example.com allows > controllers from http://example.co.uk, and successfully calls > registerServiceWorker("/*", "http://example.co.uk/service.js"), that > controller will be used for all top-level fetches on http://example.com, > and all fetches originating from documents on http://example.com, > regardless of their CSP headers. > Oops, that's misleading, I mean the existing worker will be used for all fetches even if the CSP rule of the page has changed to disallow registering of that worker. The CSP of the page will still govern script loading, XHR etc. If the page's CSP disallows a resource from a particular URL, it won't consult the worker at all. If the page requests an allowed url, and the worker serves up a response (cached or otherwise) from a not-allowed url, CSP should block it. (apologies for saying "controller" when I mean "service worker") From benjamin at smedbergs.us Thu Sep 26 08:19:10 2013 From: benjamin at smedbergs.us (Benjamin Smedberg) Date: Thu, 26 Sep 2013 11:19:10 -0400 Subject: [whatwg] Supporting scanners on the web Message-ID: <5244506E.3020808@smedbergs.us> One of the use cases that has come up for why people are still using plugins is supporting scanning to the web, in particular multi-page scanning. It seems to me that we could hook this up to <input type="file" multiple>, but that we should try to provide UAs with a hint that a page expects a document instead of images. This primarily may affect whether/how the browser presents a scanner option to the user in addition to or instead of camera/photos when selecting an image. A couple questions I've thought about but don't have answers to: * Do/can PNG images contain information about their resolution, so that the site can reconstruct the actual page size? * Should we give the site any way to specify preferred resolution or color depth for an image? Or should the site be prepared process any images to the required resolution, convert to monochrome, etc. * Should the spec recommend any specific MIME types for scanner page images? Most desktop scanners appear to default to .tiff, but that's not a normal web format: perhaps we should recommend that UAs convert to PNG. --BDS From annevk at annevk.nl Thu Sep 26 10:31:01 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Thu, 26 Sep 2013 13:31:01 -0400 Subject: [whatwg] Supporting scanners on the web In-Reply-To: <5244506E.3020808@smedbergs.us> References: <5244506E.3020808@smedbergs.us> Message-ID: <CADnb78j+8J+eML0d_RwaJKa2+RUCSsbowzkCWVUOy-LrH+y06g@mail.gmail.com> On Thu, Sep 26, 2013 at 11:19 AM, Benjamin Smedberg <benjamin at smedbergs.us> wrote: > One of the use cases that has come up for why people are still using plugins > is supporting scanning to the web, in particular multi-page scanning. It > seems to me that we could hook this up to <input type="file" multiple>, but > that we should try to provide UAs with a hint that a page expects a document > instead of images. This primarily may affect whether/how the browser > presents a scanner option to the user in addition to or instead of > camera/photos when selecting an image. > > A couple questions I've thought about but don't have answers to: > > * Do/can PNG images contain information about their resolution, so that the > site can reconstruct the actual page size? > * Should we give the site any way to specify preferred resolution or color > depth for an image? Or should the site be prepared process any images to the > required resolution, convert to monochrome, etc. > * Should the spec recommend any specific MIME types for scanner page images? > Most desktop scanners appear to default to .tiff, but that's not a normal > web format: perhaps we should recommend that UAs convert to PNG. So what do the plugins do here (pointers to the plugins?)? It seems if we want to replace these plugins, knowing what they do would be a great start. -- http://annevankesteren.nl/ From ian at hixie.ch Thu Sep 26 11:41:03 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 26 Sep 2013 18:41:03 +0000 (UTC) Subject: [whatwg] OUTPUT tag: clarify purpose in spec? In-Reply-To: <52191C14.8060700@kennardconsulting.com> References: <52191C14.8060700@kennardconsulting.com> Message-ID: <alpine.DEB.2.00.1309261831420.12199@ps20323.dreamhostps.com> On Sun, 25 Aug 2013, Richard Kennard wrote: > > Thanks for all the great work you do on the HTML 5 specification! > > Can I ask for a little clarification in the spec? Specifically it says: > > "The output element represents the result of a calculation or user > action." > http://www.w3.org/TR/html5/forms.html#the-output-element > > It is my understanding (or hope!) that the output tag fills a hole in > form markup. For example, if this is the editable version of a form: > > <label for="name">Name:</label><input id="name" type="text" value="Bob"> > > Then this can be its read-only variant: > > <label for="name" value="Name:"><output id="name">Bob</output> No, the readonly variant would be: <label for="name">Name:</label><input id="name" type="text" value="Bob" readonly> > Essentially, I am taking 'result of a calculation' to include 'values looked > up from database, REST call, etc'. Is that correct? I guess. I meant more actual calculations rather than just lookups, but lookups can be the results of "user action", so... There's a lot of <output> examples in the spec; do they help at all? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jkorpela at cs.tut.fi Thu Sep 26 13:00:16 2013 From: jkorpela at cs.tut.fi (Jukka K. Korpela) Date: Thu, 26 Sep 2013 23:00:16 +0300 Subject: [whatwg] OUTPUT tag: clarify purpose in spec? In-Reply-To: <alpine.DEB.2.00.1309261831420.12199@ps20323.dreamhostps.com> References: <52191C14.8060700@kennardconsulting.com> <alpine.DEB.2.00.1309261831420.12199@ps20323.dreamhostps.com> Message-ID: <52449250.9080609@cs.tut.fi> 2013-09-26 21:41, Ian Hickson wrote: > There's a lot of <output> examples in the spec; do they help at all? There are indeed several examples, but they are scattered around; the section that specifically deals with the <output> element, 4.10.15, has only one example. It is a simple calculator that shows the calculated result in an <output> element. And it is a form with no action attribute and with onsubmit="return false", so it is clearly meant to work in the browser only. That is, the value of the output element is not submitted. The question then arises why <output> is used, instead of just showing the result in a <span> or <div> element as usual. In fact, none of the examples about <output> have no apparent association with any submission to server-side processing. Yet, the from the properties defined for <output>, whole point seems to be that the <output> element has a special purpose: it is a control, with a value that may be included in form data upon submission, but its value is not meant to be changed by the user directly, only via actions that may indirectly modify it. Simultaneously, it is normally visible to the user. As I see it, the difference between <output> and a readonly <input> is that the latter is not meant to be changed by the user *at all*, whereas <output> is not be changed *directly*. If this interpretation is correct, I think some of it should be somehow expressed in the spec, and there should be at least one example where <output> is seemingly participating in form data submission. It's of course too late to change the name "output" now, but it is really misleading, since it suggests that the element is just for output (possibly even suggesting that it's really a duplicate of <samp>!). Yet it seems that it primarily computed data (in a broad sense for "computed") to be submitted, though it can, like <input>, be used without submission too. So <computed> or <input type=computed> might have been better. I mention this because this name problem emphasizes the need for explaining what the element is really for. I still don't quite see *why* <output> has been introduced. I can understand it as a purely logical creation, but what is the practical gain expected to be? Yucca From ian at hixie.ch Thu Sep 26 15:15:41 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 26 Sep 2013 22:15:41 +0000 (UTC) Subject: [whatwg] Comments on <dialog> In-Reply-To: <CANMdWTtM00BSP0qFShRfRXQOa9W-0T6Km+zicxekykqWi2F7WA@mail.gmail.com> References: <CAJ_xCi=dZeocSKh=okFnwVfq15PfXQUNsrtOxLQ4Y1yyM_wQdg@mail.gmail.com> <Pine.LNX.4.64.1304221922420.18848@ps20323.dreamhostps.com> <661F94F1-F67E-4AE6-87C0-AA0CAF9B57FF@apple.com> <alpine.DEB.2.00.1308270030250.28417@ps20323.dreamhostps.com> <CANMdWTtM00BSP0qFShRfRXQOa9W-0T6Km+zicxekykqWi2F7WA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309261841150.12199@ps20323.dreamhostps.com> On Mon, 26 Aug 2013, Matt Falkenhagen wrote: > On Thu, Aug 22, 2013 at 7:58 AM, Ian Hickson <ian at hixie.ch> wrote: > > On Mon, 22 Apr 2013, Tab Atkins Jr. wrote: > > > On Mon, Apr 22, 2013 at 12:38 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > On Mon, 22 Apr 2013, Matt Falkenhagen wrote: > > > >> 3. For centering in the viewport, the spec mandates that the used > > > >> value of 'top' be specially calculated. I found it more > > > >> convenient to implement by mutating the computed value rather > > > >> than the used value. This has the added benefit that it's > > > >> straightforward for the page author to implement dragging using > > > >> getComputedStyle. > > > > > > > > The computed value can't rely on layout, since it's used for > > > > inheritance, which can happen without layout, if I'm not mistaken. > > > > > > Matt means that we, the browser, explicitly set the computed value to > > > whatever's appropriate, based on layout values at the time that .show() > > > is called. (Done either by setting values in the override stylesheet, or > > > by manipulating the style attribute on the element. Probably the latter, > > > because there's no guarantee we can uniquely target the dialog via a > > > selector.) > > > > I don't really think this makes any sense. For example, it wouldn't handle > > viewport video changes as it's currently described. > > > > The way the spec is defined now, it's the static position that is set -- > > the 'top' property is unaffected except indirectly by its dependency on > > the static position. What's wrong with that? > > Can you elaborate on what viewport video changes are and what the > problem is? I think I meant viewport width changes, sorry. As in, when you resize the viewport, it would either fail to move the dialog, or it would override the user's move, depending on how we implemented this, without the author really being able to do anything about it. The way the spec is written now, you can still trivially implement dragging; you just set 'top' appropriately based on the element's position. Then, onresize or whenever you want to revert to the default position, you remove the 'top' property. It all just works. I don't really see the problem here. > It may not be a strong reason to change the spec, but in my experience, > implementing this in terms of static position in WebKit/Blink was very > challenging. As an example of the challenge, normally static position > is computed for a box during its layout, which is too early for dialog: > the dialog's dimensions must be known in order to center it, so it must > have been laid out already. How does this differ from, e.g., computing 'auto' margins of shrink-wrapped blocks? > Changing the static position after layout breaks much assumptions in the > code and would seem to require invasive work across the render tree, > layer tree, possibly painting, etc. In contrast, if CSS is manipulated > after the first layout pass, the layout engine just works. So I found it > convenient and stable to mutate CSS 'top' directly. I don't think mutating attributes is a sane approach to doing this. It feels like a hack, it interferes with author affordances, it makes it harder for us to distinguish script-set property values from UA-set property values, it makes it harder for authors to specifically override the UA, etc. > That said there have been some spec changes since my last attempt that > may make this easier, such as the dialog's cb is the icb. That also > means you can just use offsetTop/Left to implement dragging so perhaps > it's no longer helpful for getComputedStyle to return the centered top. Please do let me know if it is too difficult with the static position as defined. We could maybe consider other options like having a special computed value just for 'top', etc, the way we do for 'position'. On Tue, 27 Aug 2013, Ian Hickson wrote: > On Mon, 26 Aug 2013, Ryosuke Niwa wrote: > > On Apr 22, 2013, at 12:38 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > > > The current naming is based on window.showModalDialog() and > > > window.close(). I agree the naming is weird, but being consistent is > > > probably going to be more helpful on the long run. > > > > But that's because we have window.open but not an equivalent of > > window.close for window.showModalDialog, right? > > > > It seems more consistent to use show/hide or open/close as Matt > > suggested. > > Consistent with what? We have window.open()/window.close, and > window.showModalDialog()/window.close(). We also have > document.open()/document.close(), and so on (EventSource, etc). I > suppose we could change show() to open(), but then we'd be inconsistent > with showModalDialog() for openModal()... On Mon, 26 Aug 2013, Ojan Vafai wrote: > > IMO, showModalDialog is the legacy broken API we're stuck with. Better > to name the new thing in a way that's self-consistent and consistent > with everything else (i.e. openModal). I started doing this, since several people have asked about this and it seems the consistency between showModalDialog()/close() seems less interesting to people than the consistency with "open" everywhere else. However, it turns out this would make the show() method clash with the "open" IDL attribute on <dialog>, which we want since it matches the name of the open="" content attribute which matches <details open>. Note that window.open() and document.open() don't really do the same as this method does, either. window.open() creates a new Window, or navigates and existing one; document.open() resets the document. dialog.show() just changes the dialog to be visible. Also, there's an interesting mix in other APIs. (Disclaimer: I don't know many of these APIs personally, so I may be misinterpreting their documentation wildly. I basically looked for terms like "open" and "close" in the docs and tried to see what the right methods were in each case. I only included methods for modal dialogs if there was a trivial method; many APIs have to be configured to make dialogs modals separately.) Android uses show() and dismiss() Closure uses setVisible() Cocoa uses makeKeyAndOrderFront:, orderOut:, close, and performClose:. Delphi uses Show(), ShowModal(), Hide(), and Close(). Ext JS uses show(), hide(), and close(). jQuery uses "open" and "close". Gtk uses gtk_widget_show(), gtk_dialog_run(), gtk_window_close(). .NET uses Show(), ShowDialog(), Hide(), and Close(). Win32 uses ShowWindow() and CloseWindow(). X11 uses XMapWindow() and XUnmapWindow() Most of the APIs I looked at use "close". Most use "show". So I think we're in ok company here. I've left the spec as is. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Thu Sep 26 15:41:55 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 26 Sep 2013 22:41:55 +0000 (UTC) Subject: [whatwg] Elements should be removed from the past names map once it's no longer associated with the form element In-Reply-To: <521C0A6D.1020504@mit.edu> References: <3D1589C6-876D-4E5D-9CAC-79FB788E2F52@apple.com> <521BDC5A.7010203@mit.edu> <24F84694-2924-4176-A12C-0883C37F23DA@apple.com> <521C026D.1060400@mit.edu> <41892703-8416-4333-B683-E87086605EEE@apple.com> <521C0A6D.1020504@mit.edu> Message-ID: <alpine.DEB.2.00.1309262238260.12199@ps20323.dreamhostps.com> On Mon, 26 Aug 2013, Ryosuke Niwa wrote: > > I propose to change the specification to remove any elements that are no > longer associated with the form from the past names map: > http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#past-names-map > > It's strange for elements to linger around forever in the past names map > after the element get associated with a new form element. Since IE > didn't support form attribute for a long time (or maybe still hasn't?), > I don't think there is any compatibility concern. > > The change makes the elements associated with the form element more > consistent and easier to reason about. We can make form[x].form === > form an invariant for every x such that form[x] is a form control > element. This was fixed in response to: On Mon, 26 Aug 2013, Boris Zbarsky wrote: > > I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=23073 Let me know if there's still something to fix here. Note that there's no need to file a bug if feedback on the spec is sent to the list; I treat them both as input to the spec. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Thu Sep 26 15:45:42 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 26 Sep 2013 22:45:42 +0000 (UTC) Subject: [whatwg] Canonical Image and Color In-Reply-To: <CAJGQg4H8UdQvh1f5vphEAVAxzWufp5kAV-mMrOO8HLypEcweFQ@mail.gmail.com> References: <CAJGQg4EwgYOqf5y67Q_=WN=UewBZvkXzs5ZG8wQDrD2AM3GGnQ@mail.gmail.com> <CAAWBYDC_T=-GgUtpyApWUsaQ3yDuHvQiZKg0BzB8e44RZedGZw@mail.gmail.com> <CAJGQg4FY4WHvCK09dG=Fs=_w31oEuJ-CaraNH7uMhCxjYbmhyQ@mail.gmail.com> <alpine.DEB.2.00.1307121730320.15729@ps20323.dreamhostps.com> <CAJGQg4H8UdQvh1f5vphEAVAxzWufp5kAV-mMrOO8HLypEcweFQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309262243040.12199@ps20323.dreamhostps.com> On Wed, 28 Aug 2013, Brian Blakely wrote: > On Fri, Jul 12, 2013 at 1:32 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > You are welcome to register these on the wiki and convince people to > > use them, sure. > > Would you kindly link me to the wiki? http://wiki.whatwg.org/wiki/MetaExtensions -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jrburke at gmail.com Thu Sep 26 18:15:28 2013 From: jrburke at gmail.com (James Burke) Date: Thu, 26 Sep 2013 18:15:28 -0700 Subject: [whatwg] Notifications: usage feedback Message-ID: <CAHgY_ifiJ-mjci7xAAasUTqM_jLVCzL9CwQuRJOe9LO8JbS=Gg@mail.gmail.com> This Notifications feedback comes from using them in FirefoxOS for the email web app. It uses an alarm API to periodically wake up, do an email sync, and if new messages, creates some Notifications. The web app may also shut itself down if it was not already opened in a visible state. The OS may also decide to kill it to use the memory for some other app. 1) Ability to pass data with the Notification Right now, we URL-encode some args to the iconURL to pass data to the handler function that is registered via navigator.mozSetMessageHandler('notification', function(){}) [1]. It would be better if I could just pass a JSON-friendly data object to Notification instance and then have access to that data in the notification callbacks that are triggered. We cannot depend on notification.onclick to work since the app can be closed after the notification is fired. It also seemed very unreliable to depend on it, given garbage collection possibilities. So we cannot reliably capture state using a function closure. 2) General notification callback entry point We are avoiding use of notification.onclick/onclose and would prefer to have a generic entry point to receive notification events. Right now we use navigator.mozSetMessageHandler('notification', function(){}). but I would prefer to see a more official entry point in the spec. I would go so far as to want to deprecate the .onclick and .onclose as in practice they are not reliable, given that the app may be closed down after firing the Notification but before it is clicked. 3) onclick fires onclose too? It seemed a bit unclear in the spec, but right now FirefoxOS fires onclose too for onclick actions, as the onclick pathway removes the notification from the list of notifications. This seems counterintuitive to me, I would have only expected one event. Perhaps clarifying the onclick behavior would be good. I would prefer to just see one event fired in this case, if onclick/onclose are kept around. If the general notification callback entry point is established, then just firing it once with the event.clicked property set to true for the clicked route. 4) onclick does not bring web app to front This may be part of just further defining the steps for the "click" pathway in the spec, but at least in FirefoxOS right now, the notification onclick pathway does not bring the app to the visible front in all cases. The email app has to do some extra document.hidden checking and try to bring itself to the front. What I would rather see is by default the web page is brought to the visible front, and then perhaps allow the app a way to cancel that behavior perhaps via a preventDefault() type of mechanism on any notification click event. This would also reduce the need for an API that the app could call to bring itself "to the visible front". Right now, there is an app.launch() API in FirefoxOS for this, but there are concerns that giving apps the ability to launch themselves to the front could lead to an abuse of that API. 5) Ability to set notification modes. This one is a bit less defined. I would rather this one is discarded than spending too much time on it if it meant losing track of the points above: For email notifications, we did not necessarily want the phone to light up the screen on every notification and make a sound or vibrate (particularly at night), but rather just register the notification and have it show up in the notification count and listing. While ideally there is UI for the user to control notification behavior for all web apps, I can also see the case for allowing notifications the ability to opt in to the notification modes it prefers. Any user settings would override the modes specified in the notification, but for apps that did want to be nice, it would be a way to avoid a very annoying first notification behavior, in the case of email, not disturbing the user unless they did an explicit override. This may be too tricky to specify, but I started a bugzilla bug for FirefoxOS for this[2]. One suggestion was listing the preferred modes in the web app manifest, but I can see an app may have different types of notifications, so it would be more flexible to set per Notification instance. There is a dev-gaia thread[3] that prompted this feedback. [1] https://developer.mozilla.org/en-US/docs/Web/API/window.navigator.mozSetMessageHandler [2] https://bugzilla.mozilla.org/show_bug.cgi?id=912645 [3] https://groups.google.com/forum/#!topic/mozilla.dev.gaia/NVacmcxGt2Q James From robert at ocallahan.org Thu Sep 26 19:11:34 2013 From: robert at ocallahan.org (Robert O'Callahan) Date: Fri, 27 Sep 2013 14:11:34 +1200 Subject: [whatwg] Supporting scanners on the web In-Reply-To: <5244506E.3020808@smedbergs.us> References: <5244506E.3020808@smedbergs.us> Message-ID: <CAOp6jLZj7o4S-qA4g5hs0rhj6UApX-hANMbLDzZd1pfjXmktGw@mail.gmail.com> On Fri, Sep 27, 2013 at 3:19 AM, Benjamin Smedberg <benjamin at smedbergs.us>wrote: > A couple questions I've thought about but don't have answers to: > > * Do/can PNG images contain information about their resolution, so that > the site can reconstruct the actual page size? > Yes: http://www.scantips.com/basics9p.html > * Should we give the site any way to specify preferred resolution or color > depth for an image? Or should the site be prepared process any images to > the required resolution, convert to monochrome, etc. > That sounds useful. These values could be just hints. * Should the spec recommend any specific MIME types for scanner page > images? Most desktop scanners appear to default to .tiff, but that's not a > normal web format: perhaps we should recommend that UAs convert to PNG. > PNG sounds good given it's lossless and ubiqutious. Apps can transcode to JPEG (or any other format the browser supports encoding of) on the client if they want to. Is implementing a full scanning UI in a Web app in scope or out of scope? If it's in scope, then we'd need the ability to display incremental scan results, and we'd need to be able to do a preview vs full-view scan, and control the area scanned. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * From jonas at sicking.cc Thu Sep 26 20:52:15 2013 From: jonas at sicking.cc (Jonas Sicking) Date: Thu, 26 Sep 2013 20:52:15 -0700 Subject: [whatwg] [Workers] CSP and SharedWorkers In-Reply-To: <CAP045ApN_NPZEO3X=nNbL1eh4rGWJQya3AT49JwW5h2YeVbmJg@mail.gmail.com> References: <CAP045ApN_NPZEO3X=nNbL1eh4rGWJQya3AT49JwW5h2YeVbmJg@mail.gmail.com> Message-ID: <CA+c2ei81phQ4AmGP0wWgmoWSwbWtn5pFtH49NJceNQN0dsCroQ@mail.gmail.com> On Wed, Sep 25, 2013 at 8:00 PM, Kyle Huey <me at kylehuey.com> wrote: > It's unclear how SharedWorkers should interact with Content Security > Policies. This came up during code review of the SharedWorker > implementation in Gecko[0]. There was a public-webappsec thread[1] on this > back in May that didn't really reach a conclusion and I'd like to drive > towards one here. For both Shared Workers and Service Workers is seems pretty clear that we can't "inherit" the policy of the loading document. Any such constructs would feel non-sensical in too many situations. So here I think we should let the worker get its CSP from the script load itself. With Dedicated Workers we could in theory inherit the policy of loading document, but it feels like that creates a lot of inconsistency with Shared/Service Workers. So my off-the-top-of-my-head suggestion would be to always let workers get the CSP from the script load. Though one question is what to do for workers loaded from blob:, data: or filesystem:. Maybe we should disallow shared/service workers from those types of URLs, and make dedicated workers inherit the CSP when loaded from those URLs. Though I could see shared workers from filesystem: being useful. What do implementations do with regards to linking <script> to blob/data/filesystem? Are they treated like normal protocols, or are they treated like eval()? If they are treated like normal protocols then maybe we can simply not have any special rules for them and say that for now they never get a CSP. > I don't have strong feelings about whether or not we should > deny a page with a more liberal CSP from connecting to a SharedWorker with a > more strict CSP, but I suspect others might. What do we do for <iframe>s here. If nothing then I don't think we should do anything for workers either. / Jonas From jonas at sicking.cc Thu Sep 26 22:29:32 2013 From: jonas at sicking.cc (Jonas Sicking) Date: Thu, 26 Sep 2013 22:29:32 -0700 Subject: [whatwg] Supporting scanners on the web In-Reply-To: <5244506E.3020808@smedbergs.us> References: <5244506E.3020808@smedbergs.us> Message-ID: <CA+c2ei8HOxZJ-sN0NM6zxbt+4=bFwfWMTxyM0+iXsHJmgX8wQQ@mail.gmail.com> On Thu, Sep 26, 2013 at 8:19 AM, Benjamin Smedberg <benjamin at smedbergs.us> wrote: > One of the use cases that has come up for why people are still using plugins > is supporting scanning to the web, in particular multi-page scanning. It > seems to me that we could hook this up to <input type="file" multiple>, but > that we should try to provide UAs with a hint that a page expects a document > instead of images. What we've done in Firefox for Android is to treat <input type=file accept="image/*"> as a hint that the page wants an image any source. So we give the user options to use any built-in gallery or camera apps for example. We could do the same on desktop platforms and display an additional button next to the normal "select file" button if we detected that there are additional image sources like cameras or scanners available. There's also been proposals around <input type=file accept="image/*" capture>. This was supposed to mean "invoke media specific capturing methods". I think there was also something like <input type=file capture=camera> being proposed which would specifically enable camera-backed capturing. > * Should we give the site any way to specify preferred resolution or color > depth for an image? Or should the site be prepared process any images to the > required resolution, convert to monochrome, etc. The most requested ability is to resize images to a particular resolution. This is something that can be done using canvas, but not for videos or animated images. And currently you can't do it off the main thread, which is an issue for larger images. It would be nice to expose a image-resize API to the web. This way they could do things like resize images to the various sizes needed and just upload the resized images. Currently you have to upload the fullsized image, or you have to resize once to the maximum size you want and upload that, and then resize again on the server. But that results in lower image quality. Likewise it would be nice to have an API for re-encoding images without using canvas. This will likely be especially important if we decide on a jpeg successor to add support for. > * Should the spec recommend any specific MIME types for scanner page images? > Most desktop scanners appear to default to .tiff, but that's not a normal > web format: perhaps we should recommend that UAs convert to PNG. Yes, definitely. / Jonas From robert at ocallahan.org Thu Sep 26 22:45:15 2013 From: robert at ocallahan.org (Robert O'Callahan) Date: Fri, 27 Sep 2013 17:45:15 +1200 Subject: [whatwg] Supporting scanners on the web In-Reply-To: <CA+c2ei8HOxZJ-sN0NM6zxbt+4=bFwfWMTxyM0+iXsHJmgX8wQQ@mail.gmail.com> References: <5244506E.3020808@smedbergs.us> <CA+c2ei8HOxZJ-sN0NM6zxbt+4=bFwfWMTxyM0+iXsHJmgX8wQQ@mail.gmail.com> Message-ID: <CAOp6jLYOtSVZTTuY+g_u2G38jFxoq2wrix8buVbNifSfmCjz5w@mail.gmail.com> On Fri, Sep 27, 2013 at 5:29 PM, Jonas Sicking <jonas at sicking.cc> wrote: > The most requested ability is to resize images to a particular > resolution. This is something that can be done using canvas, but not > for videos or animated images. And currently you can't do it off the > main thread, which is an issue for larger images. > You can actually. You can draw the image to an offscreen <canvas>, scaling it, and then call toBlob() on the canvas, which is async. Nothing forces the image drawing and scaling part of that process to be sync. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * From atwilson at google.com Fri Sep 27 00:54:36 2013 From: atwilson at google.com (Andrew Wilson) Date: Fri, 27 Sep 2013 09:54:36 +0200 Subject: [whatwg] Notifications: usage feedback In-Reply-To: <CAHgY_ifiJ-mjci7xAAasUTqM_jLVCzL9CwQuRJOe9LO8JbS=Gg@mail.gmail.com> References: <CAHgY_ifiJ-mjci7xAAasUTqM_jLVCzL9CwQuRJOe9LO8JbS=Gg@mail.gmail.com> Message-ID: <CAArhhishhjN4TnbXLicEV2fV7O77RY-r1M5Z1M-oJcsMzDOnoA@mail.gmail.com> So, I'm not entirely sure how many lessons taken from the FirefoxOS implementation are applicable to the API for web pages in general, but I agree that "what do we do if the user clicks on a notification after the parent page has been closed" is a bit of an unsolved/unsolveable problem with the current API. I dimly recall seeing an email thread proposing adding some kind of click URL to a notification (and my search-fu is not strong enough to find a link to it, sadly), which seems like it would address some of the issues you have with the current API (encoding data that can be passed back to the app on a notification click, even if the app has been closed in the meantime). The solution I've seen implemented on the web (shutdown notifications when a web page is closed) clearly doesn't work for a platform like FirefoxOS which does memory management and app shutdown behind the scenes. On Fri, Sep 27, 2013 at 3:15 AM, James Burke <jrburke at gmail.com> wrote: > This Notifications feedback comes from using them in FirefoxOS for the > email web app. It uses an alarm API to periodically wake up, do an > email sync, and if new messages, creates some Notifications. The web > app may also shut itself down if it was not already opened in a > visible state. The OS may also decide to kill it to use the memory for > some other app. > > 1) Ability to pass data with the Notification > > Right now, we URL-encode some args to the iconURL to pass data to the > handler function that is registered via > navigator.mozSetMessageHandler('notification', function(){}) [1]. > > It would be better if I could just pass a JSON-friendly data object to > Notification instance and then have access to that data in the > notification callbacks that are triggered. > > We cannot depend on notification.onclick to work since the app can be > closed after the notification is fired. It also seemed very unreliable > to depend on it, given garbage collection possibilities. So we cannot > reliably capture state using a function closure. > > 2) General notification callback entry point > > We are avoiding use of notification.onclick/onclose and would prefer > to have a generic entry point to receive notification events. Right > now we use navigator.mozSetMessageHandler('notification', > function(){}). > > but I would prefer to see a more official entry point in the spec. I > would go so far as to want to deprecate the .onclick and .onclose as > in practice they are not reliable, given that the app may be closed > down after firing the Notification but before it is clicked. > > 3) onclick fires onclose too? > > It seemed a bit unclear in the spec, but right now FirefoxOS fires > onclose too for onclick actions, as the onclick pathway removes the > notification from the list of notifications. > > This seems counterintuitive to me, I would have only expected one > event. Perhaps clarifying the onclick behavior would be good. > > I would prefer to just see one event fired in this case, if > onclick/onclose are kept around. If the general notification callback > entry point is established, then just firing it once with the > event.clicked property set to true for the clicked route. > > 4) onclick does not bring web app to front > > This may be part of just further defining the steps for the "click" > pathway in the spec, but at least in FirefoxOS right now, the > notification onclick pathway does not bring the app to the visible > front in all cases. The email app has to do some extra document.hidden > checking and try to bring itself to the front. > > What I would rather see is by default the web page is brought to the > visible front, and then perhaps allow the app a way to cancel that > behavior perhaps via a preventDefault() type of mechanism on any > notification click event. > > This would also reduce the need for an API that the app could call to > bring itself "to the visible front". Right now, there is an > app.launch() API in FirefoxOS for this, but there are concerns that > giving apps the ability to launch themselves to the front could lead > to an abuse of that API. > > 5) Ability to set notification modes. > > This one is a bit less defined. I would rather this one is discarded > than spending too much time on it if it meant losing track of the > points above: > > For email notifications, we did not necessarily want the phone to > light up the screen on every notification and make a sound or vibrate > (particularly at night), but rather just register the notification and > have it show up in the notification count and listing. > > While ideally there is UI for the user to control notification > behavior for all web apps, I can also see the case for allowing > notifications the ability to opt in to the notification modes it > prefers. > > Any user settings would override the modes specified in the > notification, but for apps that did want to be nice, it would be a way > to avoid a very annoying first notification behavior, in the case of > email, not disturbing the user unless they did an explicit override. > > This may be too tricky to specify, but I started a bugzilla bug for > FirefoxOS for this[2]. One suggestion was listing the preferred modes > in the web app manifest, but I can see an app may have different types > of notifications, so it would be more flexible to set per Notification > instance. > > There is a dev-gaia thread[3] that prompted this feedback. > > [1] > https://developer.mozilla.org/en-US/docs/Web/API/window.navigator.mozSetMessageHandler > > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=912645 > > [3] https://groups.google.com/forum/#!topic/mozilla.dev.gaia/NVacmcxGt2Q > > James > From jmuizelaar at mozilla.com Fri Sep 27 11:13:34 2013 From: jmuizelaar at mozilla.com (Jeff Muizelaar) Date: Fri, 27 Sep 2013 14:13:34 -0400 Subject: [whatwg] Supporting scanners on the web In-Reply-To: <CA+c2ei8HOxZJ-sN0NM6zxbt+4=bFwfWMTxyM0+iXsHJmgX8wQQ@mail.gmail.com> References: <5244506E.3020808@smedbergs.us> <CA+c2ei8HOxZJ-sN0NM6zxbt+4=bFwfWMTxyM0+iXsHJmgX8wQQ@mail.gmail.com> Message-ID: <B6E1DE41-A274-425E-92A2-5AD37D503C11@mozilla.com> On 2013-09-27, at 1:29 AM, Jonas Sicking wrote: > On Thu, Sep 26, 2013 at 8:19 AM, Benjamin Smedberg > <benjamin at smedbergs.us> wrote: >> One of the use cases that has come up for why people are still using plugins >> is supporting scanning to the web, in particular multi-page scanning. It >> seems to me that we could hook this up to <input type="file" multiple>, but >> that we should try to provide UAs with a hint that a page expects a document >> instead of images. > > What we've done in Firefox for Android is to treat <input type=file > accept="image/*"> as a hint that the page wants an image any source. > So we give the user options to use any built-in gallery or camera apps > for example. > > We could do the same on desktop platforms and display an additional > button next to the normal "select file" button if we detected that > there are additional image sources like cameras or scanners available. > > There's also been proposals around <input type=file accept="image/*" > capture>. This was supposed to mean "invoke media specific capturing > methods". I think there was also something like <input type=file > capture=camera> being proposed which would specifically enable > camera-backed capturing. > >> * Should we give the site any way to specify preferred resolution or color >> depth for an image? Or should the site be prepared process any images to the >> required resolution, convert to monochrome, etc. > > The most requested ability is to resize images to a particular > resolution. This is something that can be done using canvas, but not > for videos or animated images. And currently you can't do it off the > main thread, which is an issue for larger images. > > It would be nice to expose a image-resize API to the web. This can already easily be done with javascript: http://people.mozilla.org/~jmuizelaar/image-scaling/scale.html The code above could easily run in a worker and can scale a 4288 ? 2848 image in under a second -Jeff From jonas at sicking.cc Fri Sep 27 11:37:08 2013 From: jonas at sicking.cc (Jonas Sicking) Date: Fri, 27 Sep 2013 11:37:08 -0700 Subject: [whatwg] Supporting scanners on the web In-Reply-To: <CAOp6jLYOtSVZTTuY+g_u2G38jFxoq2wrix8buVbNifSfmCjz5w@mail.gmail.com> References: <5244506E.3020808@smedbergs.us> <CA+c2ei8HOxZJ-sN0NM6zxbt+4=bFwfWMTxyM0+iXsHJmgX8wQQ@mail.gmail.com> <CAOp6jLYOtSVZTTuY+g_u2G38jFxoq2wrix8buVbNifSfmCjz5w@mail.gmail.com> Message-ID: <CA+c2ei-PSD6fWoPgwCR7EqrFE8786CqndDibN+AJ5+h5CK_MBw@mail.gmail.com> On Thu, Sep 26, 2013 at 10:45 PM, Robert O'Callahan <robert at ocallahan.org> wrote: > On Fri, Sep 27, 2013 at 5:29 PM, Jonas Sicking <jonas at sicking.cc> wrote: >> >> The most requested ability is to resize images to a particular >> resolution. This is something that can be done using canvas, but not >> for videos or animated images. And currently you can't do it off the >> main thread, which is an issue for larger images. > > You can actually. You can draw the image to an offscreen <canvas>, scaling > it, and then call toBlob() on the canvas, which is async. Nothing forces the > image drawing and scaling part of that process to be sync. Good point. Still doesn't solve the video or animated image problem though. Also, does any browser actually do implement asynchronous scaling in this case? We definitely shouldn't add an API to work around the lack of another API, but there's also a difference between something theoretically being possible to implement, and it actually being doable enough to happen. / Jonas From ian at hixie.ch Fri Sep 27 14:05:47 2013 From: ian at hixie.ch (Ian Hickson) Date: Fri, 27 Sep 2013 21:05:47 +0000 (UTC) Subject: [whatwg] 2D canvas feature proposal: text decoration In-Reply-To: <CABpaAqTWJq+-zrGj-Rnme1XLbDyp-2m5Bpnx8ubuo1QLr9SJWw@mail.gmail.com> References: <CABpaAqS79N2Xfqy+CrniQJBDSzmaYgxFmdboBK9AtMCFGrvjTg@mail.gmail.com> <CAGN7qDCpb3CWi0j9uibGfn4wKCpf+YfUHLfzj7kJr46Z=TuXew@mail.gmail.com> <CABpaAqTFpDq5HMQyDCRVx3ru_KVeUniaySb6eFocnrg7kgqXgQ@mail.gmail.com> <CAGN7qDD2Z=g11F2PXMFtFQPedmfEtzs4oKsQSsRiJ8qwGQk2pw@mail.gmail.com> <CAAWBYDCuv9gxz1utnsMQ2OsYhgo+gJH6W+_=5Gko7XmJekoSKw@mail.gmail.com> <CAGN7qDC6Dj1aoAtwiRzdm5L83=4yq2GhpXjhddyAQbF44LtwYQ@mail.gmail.com> <CAAWBYDDbpXtAs3V8vvPBWXe4aNOfy+hU-2bre3_ie-sSQ7Q=rQ@mail.gmail.com> <CAGN7qDBT1+=m_yL=RTR1M0bhY6s3gtEXwLgnfXZTAsBEOMEFdg@mail.gmail.com> <CABpaAqQ87sLn_dqHwr9ZPLeeE665_2irC+mMhDGK4j=hWd7fTw@mail.gmail.com> <51716E59.6080609@mit.edu> <alpine.DEB.2.00.1308202224320.27209@ps20323.dreamhostps.com> <CABpaAqTWJq+-zrGj-Rnme1XLbDyp-2m5Bpnx8ubuo1QLr9SJWw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309272041490.12199@ps20323.dreamhostps.com> On Wed, 21 Aug 2013, Justin Novosad wrote: > On Tue, Aug 20, 2013 at 6:32 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Thu, 18 Apr 2013, Justin Novosad wrote: > > > > > > This is a really simple proposal to add support for text decorations > > > in 2D canvas contexts. > > > > > > IDL to add to interface CanvasDrawingStyles: > > > > > > attribute DOMString textDecoration; > > > > > > It would support all the same modes as the 'text-decoration' CSS > > > property (except inherit), and default would be 'none'. > > > > That's anything but simple. :-) > > > > The CSS text-decoration model is actually quite complex. Also, there > > have been many proposals to split 'text-decoration' into > > sub-properties, so it is only going to get more complicated from > > there. > > > > What's your use case? That is, when do you need to underline text? > > Take a web app that presents a view of an arbitrarily large document (map, > spreadsheet, word processor document, drawing, etc). Well, which one? :-) A word processor document definitely doesn't belong in <canvas>, as discussed here: http://whatwg.org/html/#best-practices Maps and drawings are obviously applicable to <canvas>. Spreadsheets maybe, though probably only because we don't have a better solution. So, let's assume we're talking about maps and drawings. > Using the DOM to represent such documents for the purpose of rendering can > be quite inefficient. The two basic approaches are: > a) Put the entire document into the DOM and incur massive layout and style > recalculation penalties. > b) Put only the visible part of the document in the DOM and incur frequent > layout and style recalculation penalties, as you scroll around > > With 2D canvas, the app can manage its own document model, often in ways > that perform better by several orders of magnitude. > There is increasing pressure from app developers for us to improve the text > feature set in 2D canvas so that so that apps can be ported to 2D canvas. What maps and drawings need underlines that are more elaborate than just stroking a line under the text manually? > Text decoration can theoretically be drawn directly by the application > by using font metrics to compute decoration positions, but this is often > very complex to do correctly in a truly portable way. We could add underline metrics to TextMetrics if that would help. I definitely do not think it makes sense to add APIs to <canvas> until such time as it's possible to create a CSS-compliant text formatter in <canvas>. That way lies madness, as text formatting is ludicrously complicated. We already have CSS. If doing things with CSS and the DOM is too slow, then we should fix that, we shouldn't just tell people to rewrite their apps in <canvas>. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Fri Sep 27 14:08:07 2013 From: ian at hixie.ch (Ian Hickson) Date: Fri, 27 Sep 2013 21:08:07 +0000 (UTC) Subject: [whatwg] Blurry lines in 2D Canvas In-Reply-To: <CAGN7qDC8hBPJc+HhRjgodkBAkhFEgJX0kAe=pMp9g3AnUm49Wg@mail.gmail.com> References: <CAGN7qDAdABj2NCNcc53qDd23Twq2=999u0Sio-gEsBJURrpCcg@mail.gmail.com> <CAPeKFThd5HvtYFvokX=n7UR_Qs=wmqHy2vMFDoDs9y9Jd5jM=Q@mail.gmail.com> <CAGN7qDCOdadxurg5qp6q3UMygv0gjBNc5BoHOgtZKggD=5ppNQ@mail.gmail.com> <CABirCh_0orFzaZAUrtg3Z+Jg0LdSGMZxuapVdKZgigEdKJJVXQ@mail.gmail.com> <CAGN7qDDbS5Vy65SqiSdVtxgz8W9w+8WO3n=2H4wpSdkaQNLBCQ@mail.gmail.com> <CABirCh-NiwtSMzs5J5=cqazNYGAKufA3s1Lz1cW-6YvhGbt8pg@mail.gmail.com> <CAGN7qDBqXxY-aWmb3kWwxXh=rfD1BfHCEiESs9yHiFkpxkPFig@mail.gmail.com> <CABirCh9RSb0SEMsqy9KHEV77h7s04hgq7G6evCYLFRM10Kh+1A@mail.gmail.com> <CAGN7qDA8fe42MUR-Dt1sxtCnN=hPYLe6TcasSfjV+q+i-UmrjA@mail.gmail.com> <alpine.DEB.2.00.1309052119410.7443@ps20323.dreamhostps.com> <CAGN7qDC8hBPJc+HhRjgodkBAkhFEgJX0kAe=pMp9g3AnUm49Wg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309272106060.12199@ps20323.dreamhostps.com> On Thu, 5 Sep 2013, Rik Cabanier wrote: > On Thu, Sep 5, 2013 at 3:22 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Sat, 10 Aug 2013, Rik Cabanier wrote: > > > > > > I was wondering if this is something that happens in Flash as well. > > > It turns out that there's an option called "hinting: Keep stroke > > > anchors on full pixels to prevent blurry lines." There's a blog post > > > on what this does: > > > > > > http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html > > > http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html > > > > > > I created an example (in flash sorry) that shows the feature: > > > http://cabanier.github.io/BlendExamples/pixelsnap/pixelsnap.html 2 > > > sets of strokes move across the screen and are also scaled. > > > > > > The top strokes behave like canvas does today. They start of blurry > > > and during the animation they slowly get ticker. For some reason it > > > doesn't look very smooth. The bottom strokes have hinting turned on. > > > They are sharp at the beginning and during the animation they stay > > > the same size until the internal stroke width is large enough. At > > > that point you see a 'jump'. > > > > > > I think canvas should have a similar feature... > > > > Can you elaborate on how exactly you would want this to work? How > > would you avoid the alignment and distortion problems when applying > > this to anything less trivial than a rectangle? > > Basically, this would *just* move the control points and the width of > paths so the strokes are always aligned to the pixel grid (This would > take pixel density and transformations into account). After this, you > would draw as usual. Can you define "aligned to the pixel grid"? If I have a line from x1,y to x2,y, followed by an arc from x2,y back to x1,y with radius r, what should happen and why? What if they're draw as separate paths? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From whatwg at therealcha0s.net Fri Sep 27 14:13:19 2013 From: whatwg at therealcha0s.net (Ruben Rodriguez II) Date: Fri, 27 Sep 2013 16:13:19 -0500 Subject: [whatwg] Blurry lines in 2D Canvas (and SVG) In-Reply-To: <CAGN7qDCTSsg-CNxofmnhVCKh7xRUBjemn1XvjwyyM8x7UGeNyg@mail.gmail.com> References: <CAGN7qDAdABj2NCNcc53qDd23Twq2=999u0Sio-gEsBJURrpCcg@mail.gmail.com> <51EF205B.6060905@mozilla.com> <CAGN7qDAMLPe00Ako7nTLtSTWnKwe3yWK5ox8jV1y0OpNmxfGrw@mail.gmail.com> <51EF29DC.5090207@mozilla.com> <CAGN7qDCTSsg-CNxofmnhVCKh7xRUBjemn1XvjwyyM8x7UGeNyg@mail.gmail.com> Message-ID: <5245F4EF.5040407@therealcha0s.net> It seems like those should be two separate things instead of lumped all together in a monolithic "You can do this if you want... or whatever!" "Snapping" is definitely something different than antialiasing. It's a huge pain for anyone trying to provide a(n accurate) simple 2D primitive library. On 07/23/2013 08:16 PM, Rik Cabanier wrote: > I guess there's too many "might"s in there :-) > > I want to "adjust line positions and line widths to align edges with device > pixels" but not "the user agent might turn off anti-aliasing for all lines > and curves" > > On Tue, Jul 23, 2013 at 6:11 PM, Brian Birtles <bbirtles at mozilla.com> wrote: > >> (2013/07/24 10:07), Rik Cabanier wrote: >> >>> yeah, at first blush that seemed what was needed. >>> However, this simply turns off antialiasing completely so regular >>> artwork looks terrible. >>> >> That's a quality of implementation issue. The description of the property >> value says, >> >> "Indicates that the user agent shall attempt to emphasize the contrast >> between clean edges of artwork over rendering speed and geometric >> precision. To achieve crisp edges, the user agent might turn off >> anti-aliasing for all lines and curves or possibly just for straight lines >> which are close to vertical or horizontal. Also, the user agent might >> adjust line positions and line widths to align edges with device pixels." >> >> I'm not sure what use case you have in mind though. Perhaps it's something >> that doesn't fit that description? >> >> From ian at hixie.ch Fri Sep 27 14:21:01 2013 From: ian at hixie.ch (Ian Hickson) Date: Fri, 27 Sep 2013 21:21:01 +0000 (UTC) Subject: [whatwg] Adding 2D Canvas features In-Reply-To: <CAK-G-KUOzNXhRfZRTtmuYFHHcHDriSodcRmoORGqi4XhFevNuQ@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <51D12692.4030002@artspark.co.jp> <CAK-G-KVLsECC4cETFYdcPyoqigaaoRhUxcezhMG3jZc2fAViRg@mail.gmail.com> <alpine.DEB.2.00.1309052049070.7443@ps20323.dreamhostps.com> <CAA5isUYmMm9sHu=_Ybwmhw7GWfO+vRpP+8MdM_+OXKPCc+i4+Q@mail.gmail.com> <CAK-G-KUOzNXhRfZRTtmuYFHHcHDriSodcRmoORGqi4XhFevNuQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309272108410.12199@ps20323.dreamhostps.com> On Thu, 5 Sep 2013, Tom Wiltzius wrote: > > Meanwhile this doesn't change the other Canvas2D-related work ongoing in > the Chromium project, so we're still keen to see some new features added > to the Canvas spec. Ian if it would help to identify items in the spec > that Chromium doesn't intend to implement (at least any time soon), we > can attempt to do so. If there are specific things in the spec that you think are bad and should be removed, please do raise them on the mailing list, yes. If there are specific things not in the spec that you have implemented, then please file a bug pointing to the documentation for whatever you have implemented, using: http://whatwg.org/newbug If there's multiple implementations, and HTML is the right spec, then I'll pretty much automatically spec it. Otherwise, it'll be based on whether it makes sense and has use cases. (So far example, I haven't added canvas text decoration APIs, which have been raised as something Chrome might implement, as discussed in my last e-mail to this list. The alpha parameter, though, needs speccing, I just haven't gotten around to it yet -- it's on my list though.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From whatwg at therealcha0s.net Fri Sep 27 14:21:20 2013 From: whatwg at therealcha0s.net (Ruben Rodriguez II) Date: Fri, 27 Sep 2013 16:21:20 -0500 Subject: [whatwg] Blurry lines in 2D Canvas In-Reply-To: <alpine.DEB.2.00.1309052119410.7443@ps20323.dreamhostps.com> References: <CAGN7qDAdABj2NCNcc53qDd23Twq2=999u0Sio-gEsBJURrpCcg@mail.gmail.com> <CAPeKFThd5HvtYFvokX=n7UR_Qs=wmqHy2vMFDoDs9y9Jd5jM=Q@mail.gmail.com> <CAGN7qDCOdadxurg5qp6q3UMygv0gjBNc5BoHOgtZKggD=5ppNQ@mail.gmail.com> <CABirCh_0orFzaZAUrtg3Z+Jg0LdSGMZxuapVdKZgigEdKJJVXQ@mail.gmail.com> <CAGN7qDDbS5Vy65SqiSdVtxgz8W9w+8WO3n=2H4wpSdkaQNLBCQ@mail.gmail.com> <CABirCh-NiwtSMzs5J5=cqazNYGAKufA3s1Lz1cW-6YvhGbt8pg@mail.gmail.com> <CAGN7qDBqXxY-aWmb3kWwxXh=rfD1BfHCEiESs9yHiFkpxkPFig@mail.gmail.com> <CABirCh9RSb0SEMsqy9KHEV77h7s04hgq7G6evCYLFRM10Kh+1A@mail.gmail.com> <CAGN7qDA8fe42MUR-Dt1sxtCnN=hPYLe6TcasSfjV+q+i-UmrjA@mail.gmail.com> <alpine.DEB.2.00.1309052119410.7443@ps20323.dreamhostps.com> Message-ID: <5245F6D0.2090209@therealcha0s.net> I would just like to note that sometimes we do not WANT to draw precise shapes. :) Many people enjoy the aesthetic of 2d pixel-based graphics, and it should be a viable choice for the graphical style of a game, for instance. Canvas makes this more difficult, and it shouldn't be so! Why can't we have a global option to turn this off if we want to? I'm not trying to advocate for throwing away all antialiasing... I understand that most applications will probably want it by default, and agree with having it as the default. Basically all it is is http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#image-smoothing ... except that we're not talking about scaling. On 09/05/2013 05:22 PM, Ian Hickson wrote: > On Tue, 23 Jul 2013, Rik Cabanier wrote: >> we've noticed that if you draw lines in canvas or SVG, they always end >> up blurry. For instance see this fiddle: http://jsfiddle.net/V92Gn/128/ > Not always, only if you don't draw the line aligned with the pixel grid > (e.g. you draw a diagonal line, or a horizontal or vertical line that > isn't centered in the middle of pixels on the pixels grid, or a horizontal > or vertical line whose width isn't an integral number of pixels, etc). > > The options, on a pixel grid display, are: > > - don't honour the position precisely -- this leads to very ugly > artifacts when animating (lines jerk around), and basically means that > the graphics aren't accurate. > > - instead of describing the shapes as vectors, describe them using > programs that can adapt to the position and size they're being drawn > at, such that they automatically snap to the pixel grid in a pretty > fashion -- this is what fonts do. > > - try to trick the eye by using anti-aliasing when things don't line up > exactly on the pixel grid. > > The first two really aren't plausible options for <canvas>. > > > On Wed, 24 Jul 2013, Kornel Lesi?ski wrote: >> For 1-pixel lines it could be fixed by allowing authors to specify that >> path should be stroked with lines aligned to inside/outside of the path >> (which is a useful feature on its own). > https://www.w3.org/Bugs/Public/show_bug.cgi?id=22674 > > > On Tue, 23 Jul 2013, Rik Cabanier wrote: >> Sure, but how can we fix this? > What is there to fix? The options above are basically the only options. > You can't not do one of them -- there's no way to draw a crisp line that > isn't pixel aligned. There's no pixels there. Similarly, there's no way to > draw a line that's neither horizontal nor vertical yet is crisp and > doesn't look jaggy. The pixels are squares, they don't rotate on modern > pixel displays. > > > On Wed, 24 Jul 2013, Kornel Lesi?ski wrote: >> Should arc() and bezier curves also be snapped? What if you want a line >> that touches the curve? > That's precisely the problem with snapping -- it is far worse than > antialiasing. You can't draw precise shapes if you have snapping. > > > On Wed, 24 Jul 2013, Dirk Schulze wrote: >> Means implementations would need to take viewport, transformations of >> the document, transformations on elements in the DOM hierarchy, zoom >> level, aspect ratio of the canvas, position of the canvas in the >> document, transformations in the canvas and device pixel resolution into >> account to snap lines to the correct position on the individual device, >> right?Otherwise it sounds to be hard to guarantee that you don't see >> antialiased strokes and lines might snap more then just one device >> pixel. This would also be a problem for aligning shapes to each other in >> the canvas I guess. What happens on the next transformation after a >> drawing operation. Say you draw a line that was snapped to the grid and >> then you do scale(1.1, 1.1). Shall the implementation redraw the canvas? >> After all it is an pixel image. A vector based drawing format would be >> better suited for such a task. > Indeed. > > > On Sat, 10 Aug 2013, Rik Cabanier wrote: >> I was wondering if this is something that happens in Flash as well. It >> turns out that there's an option called "hinting: Keep stroke anchors on >> full pixels to prevent blurry lines." There's a blog post on what this >> does: >> http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html >> <http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html> >> >> I created an example (in flash sorry) that shows the feature: >> http://cabanier.github.io/BlendExamples/pixelsnap/pixelsnap.html >> 2 sets of strokes move across the screen and are also scaled. >> >> The top strokes behave like canvas does today. They start of blurry and >> during the animation they slowly get ticker. For some reason it doesn't >> look very smooth. >> The bottom strokes have hinting turned on. They are sharp at the beginning >> and during the animation they stay the same size until the internal stroke >> width is large enough. At that point you see a 'jump'. >> >> I think canvas should have a similar feature... > Can you elaborate on how exactly you would want this to work? How would > you avoid the alignment and distortion problems when applying this to > anything less trivial than a rectangle? > From jstpierre at mecheye.net Fri Sep 27 14:38:56 2013 From: jstpierre at mecheye.net (Jasper St. Pierre) Date: Fri, 27 Sep 2013 17:38:56 -0400 Subject: [whatwg] Blurry lines in 2D Canvas In-Reply-To: <5245F6D0.2090209@therealcha0s.net> References: <CAGN7qDAdABj2NCNcc53qDd23Twq2=999u0Sio-gEsBJURrpCcg@mail.gmail.com> <CAPeKFThd5HvtYFvokX=n7UR_Qs=wmqHy2vMFDoDs9y9Jd5jM=Q@mail.gmail.com> <CAGN7qDCOdadxurg5qp6q3UMygv0gjBNc5BoHOgtZKggD=5ppNQ@mail.gmail.com> <CABirCh_0orFzaZAUrtg3Z+Jg0LdSGMZxuapVdKZgigEdKJJVXQ@mail.gmail.com> <CAGN7qDDbS5Vy65SqiSdVtxgz8W9w+8WO3n=2H4wpSdkaQNLBCQ@mail.gmail.com> <CABirCh-NiwtSMzs5J5=cqazNYGAKufA3s1Lz1cW-6YvhGbt8pg@mail.gmail.com> <CAGN7qDBqXxY-aWmb3kWwxXh=rfD1BfHCEiESs9yHiFkpxkPFig@mail.gmail.com> <CABirCh9RSb0SEMsqy9KHEV77h7s04hgq7G6evCYLFRM10Kh+1A@mail.gmail.com> <CAGN7qDA8fe42MUR-Dt1sxtCnN=hPYLe6TcasSfjV+q+i-UmrjA@mail.gmail.com> <alpine.DEB.2.00.1309052119410.7443@ps20323.dreamhostps.com> <5245F6D0.2090209@therealcha0s.net> Message-ID: <CAA0H+QTBEPDr65ZJS7Y9LrHi4PZJ89+nXROp98yfA9muSjefxQ@mail.gmail.com> The issue here is that the canvas API does not specify how pixels are sited on the canvas: if you imagine pixels as enlarged squares on a grid (shush, I know), does an X coordinate of 5 name the center of the square, or the intersection between 4th and 5th squares? If we say that it names the center of the square itself, then we'll have sharp strokes but blurry fills -- filling from x=5 to x=10 will only fill half the area in the 5th square. If we say that it names the intersection between the pixels then we'll have blurry strokes but sharp fills. For perspective, old APIs that didn't have support for antialiased graphics like X11 and GDI say that it's the former, but the lack of antialiasing made it not noticeable. Modern APIs like cairo, Quartz 2D and Direct2D say it's the latter, and stick by it. The recommended solution is either to use even line widths with pixel-perfect coordinates or add 0.5 to all lines you draw so they're offset by half a pixel. [0] Neither of these are perfect solutions when you have transforms; perhaps optional support for crisp lines or otherwise turning off AA would be a good idea. But whatever we do, we should certainly pick a pixel citing system (and I'd highly suggest the latter) and make it explicit in the spec. http://cairographics.org/FAQ/#sharp_lines On Fri, Sep 27, 2013 at 5:21 PM, Ruben Rodriguez II <whatwg at therealcha0s.net > wrote: > I would just like to note that sometimes we do not WANT to draw precise > shapes. :) Many people enjoy the aesthetic of 2d pixel-based graphics, and > it should be a viable choice for the graphical style of a game, for > instance. Canvas makes this more difficult, and it shouldn't be so! > > Why can't we have a global option to turn this off if we want to? I'm not > trying to advocate for throwing away all antialiasing... I understand that > most applications will probably want it by default, and agree with having > it as the default. > > Basically all it is is http://www.whatwg.org/specs/** > web-apps/current-work/**multipage/the-canvas-element.** > html#image-smoothing<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#image-smoothing>... except that we're not talking about scaling. > > On 09/05/2013 05:22 PM, Ian Hickson wrote: > >> On Tue, 23 Jul 2013, Rik Cabanier wrote: >> >>> we've noticed that if you draw lines in canvas or SVG, they always end >>> up blurry. For instance see this fiddle: http://jsfiddle.net/V92Gn/128/ >>> >> Not always, only if you don't draw the line aligned with the pixel grid >> (e.g. you draw a diagonal line, or a horizontal or vertical line that >> isn't centered in the middle of pixels on the pixels grid, or a horizontal >> or vertical line whose width isn't an integral number of pixels, etc). >> >> The options, on a pixel grid display, are: >> >> - don't honour the position precisely -- this leads to very ugly >> artifacts when animating (lines jerk around), and basically means that >> the graphics aren't accurate. >> >> - instead of describing the shapes as vectors, describe them using >> programs that can adapt to the position and size they're being drawn >> at, such that they automatically snap to the pixel grid in a pretty >> fashion -- this is what fonts do. >> >> - try to trick the eye by using anti-aliasing when things don't line up >> exactly on the pixel grid. >> >> The first two really aren't plausible options for <canvas>. >> >> >> On Wed, 24 Jul 2013, Kornel Lesi?ski wrote: >> >>> For 1-pixel lines it could be fixed by allowing authors to specify that >>> path should be stroked with lines aligned to inside/outside of the path >>> (which is a useful feature on its own). >>> >> https://www.w3.org/Bugs/**Public/show_bug.cgi?id=22674<https://www.w3.org/Bugs/Public/show_bug.cgi?id=22674> >> >> >> On Tue, 23 Jul 2013, Rik Cabanier wrote: >> >>> Sure, but how can we fix this? >>> >> What is there to fix? The options above are basically the only options. >> You can't not do one of them -- there's no way to draw a crisp line that >> isn't pixel aligned. There's no pixels there. Similarly, there's no way to >> draw a line that's neither horizontal nor vertical yet is crisp and >> doesn't look jaggy. The pixels are squares, they don't rotate on modern >> pixel displays. >> >> >> On Wed, 24 Jul 2013, Kornel Lesi?ski wrote: >> >>> Should arc() and bezier curves also be snapped? What if you want a line >>> that touches the curve? >>> >> That's precisely the problem with snapping -- it is far worse than >> antialiasing. You can't draw precise shapes if you have snapping. >> >> >> On Wed, 24 Jul 2013, Dirk Schulze wrote: >> >>> Means implementations would need to take viewport, transformations of >>> the document, transformations on elements in the DOM hierarchy, zoom >>> level, aspect ratio of the canvas, position of the canvas in the >>> document, transformations in the canvas and device pixel resolution into >>> account to snap lines to the correct position on the individual device, >>> right?Otherwise it sounds to be hard to guarantee that you don't see >>> antialiased strokes and lines might snap more then just one device >>> pixel. This would also be a problem for aligning shapes to each other in >>> the canvas I guess. What happens on the next transformation after a >>> drawing operation. Say you draw a line that was snapped to the grid and >>> then you do scale(1.1, 1.1). Shall the implementation redraw the canvas? >>> After all it is an pixel image. A vector based drawing format would be >>> better suited for such a task. >>> >> Indeed. >> >> >> >> On Sat, 10 Aug 2013, Rik Cabanier wrote: >> >>> I was wondering if this is something that happens in Flash as well. It >>> turns out that there's an option called "hinting: Keep stroke anchors on >>> full pixels to prevent blurry lines." There's a blog post on what this >>> does: >>> http://www.kaourantin.net/**2005/08/stroke-hinting-in-** >>> flash-player-8-aka.html<http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html> >>> <http://www.kaourantin.net/**2005/08/stroke-hinting-in-** >>> flash-player-8-aka.html<http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html> >>> > >>> >>> I created an example (in flash sorry) that shows the feature: >>> http://cabanier.github.io/**BlendExamples/pixelsnap/**pixelsnap.html<http://cabanier.github.io/BlendExamples/pixelsnap/pixelsnap.html> >>> 2 sets of strokes move across the screen and are also scaled. >>> >>> The top strokes behave like canvas does today. They start of blurry and >>> during the animation they slowly get ticker. For some reason it doesn't >>> look very smooth. >>> The bottom strokes have hinting turned on. They are sharp at the >>> beginning >>> and during the animation they stay the same size until the internal >>> stroke >>> width is large enough. At that point you see a 'jump'. >>> >>> I think canvas should have a similar feature... >>> >> Can you elaborate on how exactly you would want this to work? How would >> you avoid the alignment and distortion problems when applying this to >> anything less trivial than a rectangle? >> >> > -- Jasper From ian at hixie.ch Fri Sep 27 14:51:30 2013 From: ian at hixie.ch (Ian Hickson) Date: Fri, 27 Sep 2013 21:51:30 +0000 (UTC) Subject: [whatwg] High-density canvases In-Reply-To: <CABpaAqRc1y-G_Oh1JgNDFXSZ-7nYMHKX+GJxpenJ1R1-8W9nPg@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <CABpaAqRc1y-G_Oh1JgNDFXSZ-7nYMHKX+GJxpenJ1R1-8W9nPg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309272132210.1460@ps20323.dreamhostps.com> On Mon, 9 Sep 2013, Rik Cabanier wrote: > On Mon, Sep 9, 2013 at 5:00 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > So my understanding is that the reason this feature failed is that > > there's existing content that assumes a 1:1 ratio, and having an > > automatic high-density mode was making some pages end up with canvases > > with four canvas pixels per CSS pixel (linearly) -- two from the > > browser making a native canvas, times two from the page scaling the > > canvas for high DPI displays. This is a factor of sixteen over a 1:1 > > canvas, a factor of four more than it should be for high DPI, and a > > big waste of resources. > > > > As much as sites do this manually, though, it's a huge pain in the > > neck to have to worry about pixel density when you're creating your > > canvas and drawing on it, especially if you're not drawing sprites on > > it. > > > > While we're talking about annoying things, there's also the annoyance > > that canvases tend to not take zoom into account (either > > density-affecting zoom like page zoom on desktop, or "transparent" > > zoom like pinch-zoom on mobile for non-mobile-optimised sites, which > > the site isn't supposed to know about): you have to remember to listen > > for onresize, and then manually blow away your canvas and recreate it > > at the right density and then squeeze it into place so that the > > coordinate space matches what your code is expecting while the > > <canvas> is actually sized for the display. > > > > There's also the issue of full-bleed canvases where every time the > > container changes, you have to remember to re-update the canvas > > coordinate space and repaint because otherwise your pretty page gets > > all warped. > > > > It would be nice to fix these all at once, and I think we can, by > > introducing a configuration option on getContext(), in the style of > > WebGL: > > > > getContext('2d', { density: 'autosize' }); > > > > This would trigger the following behaviour: When the context is > > created, and subsequently when the <canvas> changes size (e.g. due to > > being sized with CSS relative units and the element they're relative > > to changing), or when the display density changes size (e.g. due to > > page zoom), then: > > > > - the width and height of the canvas bitmaps get updated to match the > > new native size of the <canvas>, at native density. > > > > - the coordinate space of the canvas (context.width/context.height) > > gets updated to match the size of the <canvas> in CSS pixel units. > > > > - a 'resize' event gets fired at the <canvas>. > > Will this workflow introduce flickering? So long as the resize event (and thus the redrawing) is synchronous with the clearing, I don't see why it would. > I'm unsure if these calls are really needed. An author can already do > this today with a couple of lines of JS. It's a heck of a lot more than a couple of lines to do it right today. > By doing the actual resizing in the event handler, I believe flickering > is avoided. Not sure what you mean here. > I share Dean's worry that it will lead to bad redrawing if people don't > test all scenarios that causes resizing. Can you be more specific? What scenarios do you think would result in bad redrawing? > (Temporary canvases would also have to be resized manually) We'd have to provide a way to link canvases so that they maintain the same density. It's on my list of things to make sure I handle if I spec this. On Tue, 10 Sep 2013, Stephen White wrote: > > For posterity, here were our objections to the original high-DPI canvas > spec: > > - The API feels like a short-term hack to automagically do something > that the developer may or may not want done (e.g., if the game/app was > tuned for particular resolution, or for pixel-exact rendering) that we'll > be stuck with in the web platform long after its short-term usefulness has > expired This is avoided in the new proposal by making it opt-in. > - It doesn't scale well to non-integer devicePixelRatios Can you elaborate on this? I don't see why the new proposal would have this problem, but I also don't see why the old one would, so I don't know if it's because I don't understand the problem or if it's because I'm missing something from the old proposal. > - It is easy for developers to implement the above behaviour in JS if > desired I wouldn't say "easy". > I think the new proposal addresses the first point, since it's opt-in. I > don't think the second point is a problem, since [get|put]ImageData() > will be back to manipulating exact backing store pixels, so no > non-integer resizing will be required. The third point becomes moot. Agreed. > One question: now that some browsers are including browser zoom (page > zoom) in window.devicePixelRatio, will/should the new proposal > automatically cause a resize callback on page zoom, in order to preserve > 1:1 device pixels? My intent was to do so, yes. In practice I presume it'd be up to the browser to decide how often to actually do this (e.g. if page zoom is being smoothly animated, you may wish to only do it every few frames). > (Note that I think this is a problem with current JS-based > implementations of canvas auto-scale as well, although perhaps there's a > DOM event for this that you can listen to; I might just be showing my > ignorance here.) Currently page zoom should trigger a 'resize' event, but I expect few pages check. On Tue, 10 Sep 2013, Justin Novosad wrote: > > There is another closely related issue that's been discussed before: > adding a redraw callback to 2d canvas. In the past we discussed this > for solving the problem of recoverring from a gpu context loss, but it > seems there may be better reasons to consider adding a redraw callback > such as freeing memory consumed by canvas backing stores that are in > background tabs, and re-building the content when needed. This > discussion was revived in the past few days on the chromium graphics-dev > mailing list: > https://groups.google.com/a/chromium.org/forum/?fromgroups#!topic/graphics-dev/CQJXpXxO6dk > > The idea is still embryonic and we're brainstorming in this chromium > issue: crbug.com/287823 > > I think that discussion should be merged with this thread because a > resize event is another case where one may want to redraw. It would be > great to solve all of these issues together. I think it would make eminent sense to also fire the event ('resize', I guess) if the context was lost or if the canvas was about to be made visible again after the browser dropped the rendering, yes. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Fri Sep 27 15:07:40 2013 From: ian at hixie.ch (Ian Hickson) Date: Fri, 27 Sep 2013 22:07:40 +0000 (UTC) Subject: [whatwg] Challenging canvas.supportsContext In-Reply-To: <CAJTmd9q+Zyh=Fz3mRwBDBfy5q+mR5tVoNTv+rEtKJueQv2mfwg@mail.gmail.com> References: <CAJTmd9rkwsjC+WDfLr7um0=h8Pvtg9JOJCRHzH4PhdbXjgpaaA@mail.gmail.com> <CAJTmd9q-eH8fnZSP5mr3kX-quyQcNXnyXTh5o_hX+MdfuXfrGQ@mail.gmail.com> <alpine.DEB.2.00.1309032240300.7443@ps20323.dreamhostps.com> <CAJTmd9q+Zyh=Fz3mRwBDBfy5q+mR5tVoNTv+rEtKJueQv2mfwg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309272152500.1460@ps20323.dreamhostps.com> On Thu, 5 Sep 2013, Benoit Jacob wrote: > 2013/9/3 Ian Hickson <ian at hixie.ch> > > > > The long and short of this is that I renamed "supportsContext()" to > > "probablySupportsContext()". It's already implemented in WebKit > > And that's the real cost of having accepted supportsContext too early in > the HTML spec. I'm not sure I would characterise it as a cost. > > Fundamentally, it addresses a need that none of the other proposals > > addressed: how to know whether or not you can expect to be able to do > > 3D. It's not 100% reliable, but then neither would actually attempting > > to create a context, because creating a context is so expensive on > > some platforms that some UAs are going to move to doing it lazily > > The only conformant way to do lazy context creation would be to have > getContext return lost contexts, but given that only a tiny minority of > real-world code cares about that concept, that's not going to be > feasible in the foreseeable future. Maybe in a few years, > optimistically. You could implement lazy context creation by just returning optimistically and if you later find you can't actually create what was requested, pretending you lost the context. Or, the spec could be changed. But yes, that's the problem. That's why we need this feature. > > On Wed, 19 Jun 2013, Benoit Jacob wrote: > > > > > However, that only shifts the question to: what is the reason for > > > them to expose such APIs? In the end, I claim that the only thing > > > that we should recognize as a reason to add a feature to the HTML > > > spec, is *application* use cases. > > > > Oh well the use case for knowing whether or not 3D is supported on a > > particular device is straight-forward: you want to know which set of > > assets and logic to download and run. > > Application developer wants things. But these are not necessarily good > ideas, because they may not reflect how things really work. Certainly. > > > So let's look at the naive application usage pattern for supportsContext: > > > > > > if (canvas.supportsContext("webgl")) { > > > context = canvas.getContext("webgl"); > > > } > > > > > > The problem is that the same can be achieved with just the > > > getContext call, and checking whether it succeeded. > > > > Suppose you have an app that has a 3D feature, but it's not > > immediately used upon startup. For example, a preview window that is > > displayed on request. You want to preload all the code to run the > > preview window, but you need to load different code based on whether > > the device can do 3D or not. So the use case is more: > > > > if (canvas.supportsContext("webgl")) > > load3DCode(); > > else > > load2DCode(); > > > > // 3D code: > > function run() { > > context = canvas.getContext("webgl"); > > // ... > > } > > If now application developers call probablySupportsContext, it returns > true, they start downloading the WebGL assets, but getContext("webgl") > fails, their application startup experience will be wose, which will > pressure browser developers to optimize the accuracy of > probablySupportsContext, but that's going to be hard and unrewarding. This is a rare case, and it's a rare case that can happen even with using getContext() twice instead of probablySupportsContext() and getContext(). > Instead, they should do their actual getContext call --- the one > creating the context that they will actually want to use --- right at > the beginning of their application startup, and download the right > assets based on the outcome of that getContext. Sure, but we've repeatedly heard application developers say that's not going to happen, so... > The downside of course is that assets download becomes gated on getContext > returning. But in practice that's not too bad: > - Only the first getContext in a browser sessing can be really slow (say > 100 ms), subsequent ones tend to take less than 5 ms --- not that much > compared to the time to download big assets. > - If any assets are shared between the two code paths, they can be > downloaded first while getContext is running. We might not consider it too bad, but we have heard other people say it's too bad. > > You don't want to pay the cost of creating a throw-away 3D context on > > startup just to know which scripts to load. It defeats the whole point > > of not loading all the code up-front. > > I'm not talking about having any throw-away 3d contexts just for > testing. I understand that modernizr has an API that would force it to > be implemented in that way. In my view, that makes it a bad API. There > should be only one context, the one that we actually want to use. Well, as much as I agree with you, we still have to take author needs into account. Take the example I gave above, with a preview window. The <canvas> that you'll be drawing on might not exist yet. The entire fragment of the document, or indeed, the entire <iframe> containing the relevant document, might not exist yet. > > > Outside of exceptional cases (out of memory...), the slow path in > > > getContext is the *success* case, and again, in that case a real > > > application would want to actually *use* that context. > > > > Not necessarily, as noted above. The <canvas> you're going to draw to > > might not even exist at the point you need to know if it's 3D or not. > > Precisely, that's my point: don't cater to the pathological > use-a-separate-throwaway-context use case, instead assume that people > are smart and that if the first getContext succeeds, they will use that > context. Assuming that people are "smart" when they have told us explicitly that they want to do something "not smart" is not a winning strategy. Also, I don't think "smart" is the right way to think of this. Consider someone who is using a self-contained 3D library that creates the <canvas> and handles lost contexts and so on. They also have a totally separate 2D library that creates its own <canvas> and so forth. And they have a sniffing library that they use to decide which to use. Realistically, it's quite likely that these libraries have never heard of each other and do not support handing off canvas elements and contexts to each other. The person writing this code might not know anything about contexts, either. It's not that they're not "smart", it's that they don't know this stuff. > > > Keep in mind that supportsContext can't guarantee that if it returns > > > true, then a subsequent getContext will succeed. > > > > Sure. getContext() can't guarantee that if it returns a context, the > > context will work forever, either. > > Indeed, there is some non-determinism inherent to how GPUs work. > > I'm just talking about not adding more non-determinism to it. I don't think this adds more, really. If probablySupportsContext() returns true, then most of the time, so will getContext(). Just like if getContext() returned non-null, it likely will again. > > > Given such deep problems, I think that the usefulness bar for > > > accepting supportsContext into the spec should be quite high. > > > > The problem is that there's no alternative solution. > > As I've been advocating, there is a more reasonable alternative which is > not to have anything else than getContext. That is only a reasonable alternative if we ignore the feedback we're getting from Web developers. > (I want to be clear that the long delay hinders my ability to continue > this conversation. I'm just one regular Mozilla developer --- I'm not > supposed to be spending a lot of time discussing the canvas standard, > and right now, I can't really afford to. Back when I started this thread > in june, I did have some time to invest in a long conversation on this. > Right now I don't.) Feel free to wait until you have time to reply. Fundamentally, I can't reply to all incoming mail immediately; I reply to it mostly on a first-come-first-served basis, grouped by threads. Sometimes I have a few months of lag. I don't know what I could do about this. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From robert at ocallahan.org Fri Sep 27 15:17:03 2013 From: robert at ocallahan.org (Robert O'Callahan) Date: Sat, 28 Sep 2013 10:17:03 +1200 Subject: [whatwg] Supporting scanners on the web In-Reply-To: <CA+c2ei-PSD6fWoPgwCR7EqrFE8786CqndDibN+AJ5+h5CK_MBw@mail.gmail.com> References: <5244506E.3020808@smedbergs.us> <CA+c2ei8HOxZJ-sN0NM6zxbt+4=bFwfWMTxyM0+iXsHJmgX8wQQ@mail.gmail.com> <CAOp6jLYOtSVZTTuY+g_u2G38jFxoq2wrix8buVbNifSfmCjz5w@mail.gmail.com> <CA+c2ei-PSD6fWoPgwCR7EqrFE8786CqndDibN+AJ5+h5CK_MBw@mail.gmail.com> Message-ID: <CAOp6jLajd5s8gUi9rfKobSR+ibpMnwcn5RKOEmfVKo-_zA9K0A@mail.gmail.com> On Sat, Sep 28, 2013 at 6:37 AM, Jonas Sicking <jonas at sicking.cc> wrote: > Also, does any browser actually do implement asynchronous scaling in > this case? We definitely shouldn't add an API to work around the lack > of another API, but there's also a difference between something > theoretically being possible to implement, and it actually being > doable enough to happen. > I don't know. As of recently, we do the image encoding step off the main thread, but the main thread still blocks for the scaling. That is fixable. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * From ian at hixie.ch Fri Sep 27 15:35:35 2013 From: ian at hixie.ch (Ian Hickson) Date: Fri, 27 Sep 2013 22:35:35 +0000 (UTC) Subject: [whatwg] Stroking algorithm in Canvas 2d In-Reply-To: <CAGN7qDDgfZmoZvj9JEwzM764LHWivn=nh_WyGfJOX7SdW31vvg@mail.gmail.com> References: <CAGN7qDA-iib4SULW-JDf4_vpsyuxpg1m8AkXq=qgDtY1OkXahA@mail.gmail.com> <alpine.DEB.2.00.1309091626010.12210@ps20323.dreamhostps.com> <CAGN7qDDgfZmoZvj9JEwzM764LHWivn=nh_WyGfJOX7SdW31vvg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309272226380.1460@ps20323.dreamhostps.com> On Mon, 9 Sep 2013, Rik Cabanier wrote: > On Mon, Sep 9, 2013 at 9:33 AM, Ian Hickson <ian at hixie.ch> wrote: > > On Thu, 5 Sep 2013, Rik Cabanier wrote: > > > > > > we've looked over the algorithm in the Canvas spec that describes > > > how strokes are computed. [1] We think that this section is making > > > some incorrect assumptions. For instance, the dashes are calculated > > > over the total lenght of all subpaths, but each subpath should be > > > treated separately. > > > > That's intentional, otherwise if you stroke an already-dashed line, > > you get weird results. > > As Stephan said, when would this happen? Are you thinking of a case > where you did the dashing yourself and then dash/stroke it again? If so, > that is expected to give different results. Expected by whom? The idea here is that this line: ------------------------------ ...would result in this dash (assuming equally spaced on-off): --- --- --- --- --- ...while this line, dashed with the same stroke: --- --- --- --- --- ...would result in this different line, rather than result in no change: --- --- --- ...and this line, dashed with the same stroke: -- -- -- -- -- -- -- -- ...would result in something more like: -- - -- - -- - ...rather than, again, resulting in no change. > > > It's also a bit strange that the spec is trying to describe how to > > > stroke. > > > > It's trying to describe sufficient detail to get interoperable > > behaviour. > > > > > For instance, it goes in minute detail on how dashes are applied but > > > the hardest part of stroking ("inflating the paths in path > > > perpendicular to the direction") is not described at all. > > > > Is there any ambiguity in the part that's not described? > > Yes. What is "inflating"? The dictionary definition is what I intended. To grow, increase in size, get bigger in all directions. Inflate. If you have any better suggestion for how to word this, I'm all for it. > A stroked bezier curve is no longer a bezier and has to be calculated. Yes. The idea of defining it in terms of the earlier path is that there's no need to be explicit about the maths here. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jamesr at chromium.org Fri Sep 27 15:37:56 2013 From: jamesr at chromium.org (James Robinson) Date: Fri, 27 Sep 2013 15:37:56 -0700 Subject: [whatwg] Bug in 12.2.5.4.8 (The "text" insertion mode) when invoking the "spin the event loop" algorithm Message-ID: <CAD73md+UUivE3NFEM2V=S71d7LYqri+Z2VD+0ggvkNiH03YJjw@mail.gmail.com> 12.2.5.4.8 (The "text" insertion mode) defines an following algorithm for dealing with inline <script> tags that aren't ready to execute when parsed. I believe there are some subtle bugs with the way the algorithm is specified. More importantly, the invocation of the "spin the event loop" algorithm makes it harder to reason about the system as a whole. The algorithm in question runs when parsing a </script> at a script nesting level (i.e. not one generated by document.write()): 1.) Let *the script* be the pending parsing-blocking script<http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#pending-parsing-blocking-script>. There is no longer a pending parsing-blocking script<http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#pending-parsing-blocking-script> . 2.) Block the tokenizer<http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#tokenization>for this instance of the HTML parser<http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#html-parser>, such that the event loop<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-loop>will not run tasks<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#concept-task>that invoke the tokenizer<http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#tokenization> . 3.) If the parser's Document<http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#document> has a style sheet that is blocking scripts<http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#has-a-style-sheet-that-is-blocking-scripts>or *the script*'s "ready to be parser-executed"<http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#ready-to-be-parser-executed>flag is not set: spin the event loop<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#spin-the-event-loop>until the parser's Document<http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#document> has no style sheet that is blocking scripts<http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#has-no-style-sheet-that-is-blocking-scripts>and *the script*'s "ready to be parser-executed"<http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#ready-to-be-parser-executed>flag is set. 4.) Unblock the tokenizer<http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#tokenization>for this instance of the HTML parser<http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#html-parser>, such that tasks<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#concept-task>that invoke the tokenizer<http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#tokenization>can again be run. 5.) Let the insertion point<http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#insertion-point>be just before the next input character<http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#next-input-character> . 6.) Increment the parser's script nesting level<http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#script-nesting-level>by one (it should be zero before this step, so this sets it to one). 7.) Execute<http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#execute-the-script-block> *the script*. ... Step 3 spins the event loop. The issue is that while the tokenizer is blocked other tasks can run whenever the event loop is spun and cause changes that make the rest of the algorithm incorrect. For example, consider: <!DOCTYPE html> <script> window.setTimeout(function() { document.write("Goodbye"); }, 50); <link rel="stylesheet" type="text/css" href="long_loading.css"></link> <script> window.alert("Hello"); </script> The algorithm in question will run when parsing the last </script>. The second script can't execute until the stylesheet loads, so the spec spins the event loop until that happens. However, if the setTimeout fires before long_loading.css loads then the document.write() call will first perform an implicit document.open(), since there is no insertion point, and blow away the entire Document. This cancels any pending tasks but doesn't (as far as I can tell) cancel already started tasks. By my reading of the spec, the rest of the steps of the algorithm should still run and the script should execute. However, what actually happens in every browser I can test (Chrome Canary* / Firefox 22 / IE10) the alert never fires. What the Blink code actually does is simply suspend the tokenizer and then return control the the underlying (non-nested, usually) event loop. I propose that instead of spinning the event loop, we instead have step 3 enter an asynchronous section if the script isn't ready to run yet which queues a task once the script is ready to run. Since this algorithm only runs at a script nesting level of zero this is a fairly minor tweak in overall behavior, but I believe it means that invoking the tokenizer can never spin the event loop which is a nice property to have. - James * This testcase actually crashes Chrome versions other than recent canaries. Oops. From glenn at zewt.org Fri Sep 27 19:41:24 2013 From: glenn at zewt.org (Glenn Maynard) Date: Fri, 27 Sep 2013 21:41:24 -0500 Subject: [whatwg] Blurry lines in 2D Canvas In-Reply-To: <CAA0H+QTBEPDr65ZJS7Y9LrHi4PZJ89+nXROp98yfA9muSjefxQ@mail.gmail.com> References: <CAGN7qDAdABj2NCNcc53qDd23Twq2=999u0Sio-gEsBJURrpCcg@mail.gmail.com> <CAPeKFThd5HvtYFvokX=n7UR_Qs=wmqHy2vMFDoDs9y9Jd5jM=Q@mail.gmail.com> <CAGN7qDCOdadxurg5qp6q3UMygv0gjBNc5BoHOgtZKggD=5ppNQ@mail.gmail.com> <CABirCh_0orFzaZAUrtg3Z+Jg0LdSGMZxuapVdKZgigEdKJJVXQ@mail.gmail.com> <CAGN7qDDbS5Vy65SqiSdVtxgz8W9w+8WO3n=2H4wpSdkaQNLBCQ@mail.gmail.com> <CABirCh-NiwtSMzs5J5=cqazNYGAKufA3s1Lz1cW-6YvhGbt8pg@mail.gmail.com> <CAGN7qDBqXxY-aWmb3kWwxXh=rfD1BfHCEiESs9yHiFkpxkPFig@mail.gmail.com> <CABirCh9RSb0SEMsqy9KHEV77h7s04hgq7G6evCYLFRM10Kh+1A@mail.gmail.com> <CAGN7qDA8fe42MUR-Dt1sxtCnN=hPYLe6TcasSfjV+q+i-UmrjA@mail.gmail.com> <alpine.DEB.2.00.1309052119410.7443@ps20323.dreamhostps.com> <5245F6D0.2090209@therealcha0s.net> <CAA0H+QTBEPDr65ZJS7Y9LrHi4PZJ89+nXROp98yfA9muSjefxQ@mail.gmail.com> Message-ID: <CABirCh9zgFgtZiO7o=GaBhHFF+Unz1CtKsAG_sLXfdh=1VmWkw@mail.gmail.com> On Fri, Sep 27, 2013 at 4:38 PM, Jasper St. Pierre <jstpierre at mecheye.net>wrote: > The issue here is that the canvas API does not specify how pixels are sited > on the canvas: if you imagine pixels as enlarged squares on a grid (shush, > I know), does an X coordinate of 5 name the center of the square, or the > intersection between 4th and 5th squares? > That's not the issue this thread is about. I don't know if it's specified (though I suspect is is), but WebKit, Firefox and IE10's Canvas implementations all use OpenGL's coordinate system. This can be seen in the very first post in the thread, which renders consistently in all three browsers. http://jsfiddle.net/V92Gn/128/ -- Glenn Maynard From cabanier at gmail.com Fri Sep 27 20:58:49 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Fri, 27 Sep 2013 20:58:49 -0700 Subject: [whatwg] Stroking algorithm in Canvas 2d In-Reply-To: <alpine.DEB.2.00.1309272226380.1460@ps20323.dreamhostps.com> References: <CAGN7qDA-iib4SULW-JDf4_vpsyuxpg1m8AkXq=qgDtY1OkXahA@mail.gmail.com> <alpine.DEB.2.00.1309091626010.12210@ps20323.dreamhostps.com> <CAGN7qDDgfZmoZvj9JEwzM764LHWivn=nh_WyGfJOX7SdW31vvg@mail.gmail.com> <alpine.DEB.2.00.1309272226380.1460@ps20323.dreamhostps.com> Message-ID: <CAGN7qDD4vA-7N_=KX_vZAeRPHZvtQAvhSSKE2bCi9T+iOReO-g@mail.gmail.com> On Fri, Sep 27, 2013 at 3:35 PM, Ian Hickson <ian at hixie.ch> wrote: > On Mon, 9 Sep 2013, Rik Cabanier wrote: > > On Mon, Sep 9, 2013 at 9:33 AM, Ian Hickson <ian at hixie.ch> wrote: > > > On Thu, 5 Sep 2013, Rik Cabanier wrote: > > > > > > > > we've looked over the algorithm in the Canvas spec that describes > > > > how strokes are computed. [1] We think that this section is making > > > > some incorrect assumptions. For instance, the dashes are calculated > > > > over the total lenght of all subpaths, but each subpath should be > > > > treated separately. > > > > > > That's intentional, otherwise if you stroke an already-dashed line, > > > you get weird results. > > > > As Stephan said, when would this happen? Are you thinking of a case > > where you did the dashing yourself and then dash/stroke it again? If so, > > that is expected to give different results. > > Expected by whom? > > The idea here is that this line: > > ------------------------------ > > ...would result in this dash (assuming equally spaced on-off): > > --- --- --- --- --- > > ...while this line, dashed with the same stroke: > > --- --- --- --- --- > > ...would result in this different line, rather than result in no change: > > --- --- --- > > ...and this line, dashed with the same stroke: > > -- -- -- -- -- -- -- -- > > ...would result in something more like: > > -- - -- - -- - > > ...rather than, again, resulting in no change. > Yep, this is where assumptions went wrong. Dashes are calculated per subpath, not per 'line'/whole path. > > > > > > It's also a bit strange that the spec is trying to describe how to > > > > stroke. > > > > > > It's trying to describe sufficient detail to get interoperable > > > behaviour. > > > > > > > For instance, it goes in minute detail on how dashes are applied but > > > > the hardest part of stroking ("inflating the paths in path > > > > perpendicular to the direction") is not described at all. > > > > > > Is there any ambiguity in the part that's not described? > > > > Yes. What is "inflating"? > > The dictionary definition is what I intended. To grow, increase in size, > get bigger in all directions. Inflate. > > If you have any better suggestion for how to word this, I'm all for it. > I think Stephan could come up with a formula. Not sure if we should do this though. You can see a stroke as if you're drawing with a marker with a round, square or flat tip (= end caps). Maybe it's OK the say that in the spec? > > > > A stroked bezier curve is no longer a bezier and has to be calculated. > > Yes. The idea of defining it in terms of the earlier path is that there's > no need to be explicit about the maths here. How is a UA going to implement that? I can imagine many ways to "inflate" a path From cabanier at gmail.com Sat Sep 28 20:42:37 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Sat, 28 Sep 2013 20:42:37 -0700 Subject: [whatwg] Blurry lines in 2D Canvas In-Reply-To: <alpine.DEB.2.00.1309272106060.12199@ps20323.dreamhostps.com> References: <CAGN7qDAdABj2NCNcc53qDd23Twq2=999u0Sio-gEsBJURrpCcg@mail.gmail.com> <CAPeKFThd5HvtYFvokX=n7UR_Qs=wmqHy2vMFDoDs9y9Jd5jM=Q@mail.gmail.com> <CAGN7qDCOdadxurg5qp6q3UMygv0gjBNc5BoHOgtZKggD=5ppNQ@mail.gmail.com> <CABirCh_0orFzaZAUrtg3Z+Jg0LdSGMZxuapVdKZgigEdKJJVXQ@mail.gmail.com> <CAGN7qDDbS5Vy65SqiSdVtxgz8W9w+8WO3n=2H4wpSdkaQNLBCQ@mail.gmail.com> <CABirCh-NiwtSMzs5J5=cqazNYGAKufA3s1Lz1cW-6YvhGbt8pg@mail.gmail.com> <CAGN7qDBqXxY-aWmb3kWwxXh=rfD1BfHCEiESs9yHiFkpxkPFig@mail.gmail.com> <CABirCh9RSb0SEMsqy9KHEV77h7s04hgq7G6evCYLFRM10Kh+1A@mail.gmail.com> <CAGN7qDA8fe42MUR-Dt1sxtCnN=hPYLe6TcasSfjV+q+i-UmrjA@mail.gmail.com> <alpine.DEB.2.00.1309052119410.7443@ps20323.dreamhostps.com> <CAGN7qDC8hBPJc+HhRjgodkBAkhFEgJX0kAe=pMp9g3AnUm49Wg@mail.gmail.com> <alpine.DEB.2.00.1309272106060.12199@ps20323.dreamhostps.com> Message-ID: <CAGN7qDCgiSWx9GWGBp9S4gueEqBnW6NPWA1bsXOAbOmr+k9UGg@mail.gmail.com> On Fri, Sep 27, 2013 at 2:08 PM, Ian Hickson <ian at hixie.ch> wrote: > On Thu, 5 Sep 2013, Rik Cabanier wrote: > > On Thu, Sep 5, 2013 at 3:22 PM, Ian Hickson <ian at hixie.ch> wrote: > > > On Sat, 10 Aug 2013, Rik Cabanier wrote: > > > > > > > > I was wondering if this is something that happens in Flash as well. > > > > It turns out that there's an option called "hinting: Keep stroke > > > > anchors on full pixels to prevent blurry lines." There's a blog post > > > > on what this does: > > > > > > > > > http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html > > > > > http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html > > > > > > > > I created an example (in flash sorry) that shows the feature: > > > > http://cabanier.github.io/BlendExamples/pixelsnap/pixelsnap.html 2 > > > > sets of strokes move across the screen and are also scaled. > > > > > > > > The top strokes behave like canvas does today. They start of blurry > > > > and during the animation they slowly get ticker. For some reason it > > > > doesn't look very smooth. The bottom strokes have hinting turned on. > > > > They are sharp at the beginning and during the animation they stay > > > > the same size until the internal stroke width is large enough. At > > > > that point you see a 'jump'. > > > > > > > > I think canvas should have a similar feature... > > > > > > Can you elaborate on how exactly you would want this to work? How > > > would you avoid the alignment and distortion problems when applying > > > this to anything less trivial than a rectangle? > > > > Basically, this would *just* move the control points and the width of > > paths so the strokes are always aligned to the pixel grid (This would > > take pixel density and transformations into account). After this, you > > would draw as usual. > > Can you define "aligned to the pixel grid"? > > If I have a line from x1,y to x2,y, followed by an arc from x2,y back to > x1,y with radius r, what should happen and why? > Align the anchor points of all the segments. Don't change any of the anti-aliasing behavior. > > What if they're draw as separate paths? I'm unsure if I follow. That shouldn't make a different. What might be different however, is if you draw a diagonal line in 1 segment or 2 since the middle point will be aligned to the grid in the latter case. From cabanier at gmail.com Sat Sep 28 20:43:49 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Sat, 28 Sep 2013 20:43:49 -0700 Subject: [whatwg] Blurry lines in 2D Canvas In-Reply-To: <CABirCh9zgFgtZiO7o=GaBhHFF+Unz1CtKsAG_sLXfdh=1VmWkw@mail.gmail.com> References: <CAGN7qDAdABj2NCNcc53qDd23Twq2=999u0Sio-gEsBJURrpCcg@mail.gmail.com> <CAPeKFThd5HvtYFvokX=n7UR_Qs=wmqHy2vMFDoDs9y9Jd5jM=Q@mail.gmail.com> <CAGN7qDCOdadxurg5qp6q3UMygv0gjBNc5BoHOgtZKggD=5ppNQ@mail.gmail.com> <CABirCh_0orFzaZAUrtg3Z+Jg0LdSGMZxuapVdKZgigEdKJJVXQ@mail.gmail.com> <CAGN7qDDbS5Vy65SqiSdVtxgz8W9w+8WO3n=2H4wpSdkaQNLBCQ@mail.gmail.com> <CABirCh-NiwtSMzs5J5=cqazNYGAKufA3s1Lz1cW-6YvhGbt8pg@mail.gmail.com> <CAGN7qDBqXxY-aWmb3kWwxXh=rfD1BfHCEiESs9yHiFkpxkPFig@mail.gmail.com> <CABirCh9RSb0SEMsqy9KHEV77h7s04hgq7G6evCYLFRM10Kh+1A@mail.gmail.com> <CAGN7qDA8fe42MUR-Dt1sxtCnN=hPYLe6TcasSfjV+q+i-UmrjA@mail.gmail.com> <alpine.DEB.2.00.1309052119410.7443@ps20323.dreamhostps.com> <5245F6D0.2090209@therealcha0s.net> <CAA0H+QTBEPDr65ZJS7Y9LrHi4PZJ89+nXROp98yfA9muSjefxQ@mail.gmail.com> <CABirCh9zgFgtZiO7o=GaBhHFF+Unz1CtKsAG_sLXfdh=1VmWkw@mail.gmail.com> Message-ID: <CAGN7qDA9roFayg71rFRjd1Bj9AtY=a1b1f-r6A0pTkxAmsmKoQ@mail.gmail.com> Yeah, this should be specified somewhere. As you point out, luckily everyone is in agreement. On Fri, Sep 27, 2013 at 7:41 PM, Glenn Maynard <glenn at zewt.org> wrote: > On Fri, Sep 27, 2013 at 4:38 PM, Jasper St. Pierre <jstpierre at mecheye.net > >wrote: > > > The issue here is that the canvas API does not specify how pixels are > sited > > on the canvas: if you imagine pixels as enlarged squares on a grid > (shush, > > I know), does an X coordinate of 5 name the center of the square, or the > > intersection between 4th and 5th squares? > > > > That's not the issue this thread is about. I don't know if it's specified > (though I suspect is is), but WebKit, Firefox and IE10's Canvas > implementations all use OpenGL's coordinate system. This can be seen in > the very first post in the thread, which renders consistently in all three > browsers. http://jsfiddle.net/V92Gn/128/ > > -- > Glenn Maynard > From benjamin at smedbergs.us Mon Sep 30 05:59:53 2013 From: benjamin at smedbergs.us (Benjamin Smedberg) Date: Mon, 30 Sep 2013 08:59:53 -0400 Subject: [whatwg] Supporting scanners on the web In-Reply-To: <CAOp6jLZj7o4S-qA4g5hs0rhj6UApX-hANMbLDzZd1pfjXmktGw@mail.gmail.com> References: <5244506E.3020808@smedbergs.us> <CAOp6jLZj7o4S-qA4g5hs0rhj6UApX-hANMbLDzZd1pfjXmktGw@mail.gmail.com> Message-ID: <524975C9.4030209@smedbergs.us> On 9/26/2013 10:11 PM, Robert O'Callahan wrote: > Is implementing a full scanning UI in a Web app in scope or out of scope? For now I intend to focus on implementing the scanning UI in the browser and just handing the site the final product. Any thoughts of exposing a fine-grained control over previews and incremental results needs significantly more thought about how that would work on both desktop and mobile devices. --BDS From cabanier at gmail.com Mon Sep 30 10:15:25 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Mon, 30 Sep 2013 10:15:25 -0700 Subject: [whatwg] Outline style to use for drawSystemFocusRing In-Reply-To: <CAFz-FYwi6tQ7WcODc3MBC=6pM_=G5ZONe=nVSHLs5EGTiUjE=w@mail.gmail.com> References: <CAFz-FYxS-sLLOMA2=5bj-aJ1bmsBq8w_4Rminw_JLCMnYaMfPw@mail.gmail.com> <alpine.DEB.2.00.1307242308540.27623@ps20323.dreamhostps.com> <CAGN7qDCdCR1F-D9PtEKUcHkh5KdwKhum4vEAyUQ0VkLeeC+PCA@mail.gmail.com> <alpine.DEB.2.00.1307292147040.27623@ps20323.dreamhostps.com> <CAGN7qDAaq8XnX1z_BbpLVhgE5m4j--b720ZuHSEzq_iN1es0=Q@mail.gmail.com> <alpine.DEB.2.00.1307300020510.27623@ps20323.dreamhostps.com> <CAGN7qDAjRPOQ25gQT+BY+sp8Y503_9KxTa1j2aZSGYU-9BmBVA@mail.gmail.com> <CAFz-FYzzPFU3g+fM+QGbEDAJ-3DSU2qGHY9R+heZRbAWVAN2rw@mail.gmail.com> <CAGN7qDDu3PNxK9PTVr09sqUc0FrOnXgRaQDwLXQ13BhH_=85Bw@mail.gmail.com> <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> <alpine.DEB.2.00.1309120051240.12199@ps20323.dreamhostps.com> <CAFz-FYwi6tQ7WcODc3MBC=6pM_=G5ZONe=nVSHLs5EGTiUjE=w@mail.gmail.com> Message-ID: <CAGN7qDDhuCSSbBtF6gLTUy06sKoNXub3hD6EcUCvKr4ojkzhMA@mail.gmail.com> On Thu, Sep 12, 2013 at 9:32 AM, Dominic Mazzoni <dmazzoni at google.com>wrote: > On Wed, Sep 11, 2013 at 5:54 PM, Ian Hickson <ian at hixie.ch> wrote: > > > On Tue, 10 Sep 2013, Dominic Mazzoni wrote: > > > > > > We've finished implementing drawSystemFocusRing and drawCustomFocusRing > > > in Chrome. Try it in Chrome 31 or higher (either canary or dev channel > > > should work today). You'll need to go to chrome://flags and enable > > > *experimental canvas features*, then restart the browser. > > > > > > Here's a demo I built that uses drawSystemFocusRing: > > > http://dmazzoni-google.github.io/canvas-focus-ring-demo/ > > > > Looks good. Was your conclusion that the spec was ok as is, or did you > > deviate from the spec in some way that needs a spec change > > > > I think drawSystemFocusRing is good to go. If you want, you can update the > spec to reflect that an implementation is available (behind a flag). > > Only one minor issue for clarification: if the current path is a line or > unclosed polygon, should it be closed (or otherwise outlined) when drawing > the focus ring? Currently we're not doing so in Chrome, but it might help > to clarify. For example, if the path is a line, what's drawn is just an > additional stroke on that line, not a "ring". > > I'm not as sure about drawCustomFocusRing. The spec says "If the user has > requested the use of particular focus rings", but I'm not aware of any > platform API we could use to query that. To the best of my knowledge, > assistive technology that draws its own focus rings, like ZoomText, > normally draws an additional focus ring with extra padding, rather than > replacing the system one. (Example: > http://www.aisquared.com/zoomtext/tour/enhancements#focus_enhancements) > > So, I'm not sure how I'd implement that part of the spec. Chrome definitely > has no plans to give users an additional preference for focus rings as a > browser setting. > > So, what we implemented in Chrome for drawCustomFocusRing is basically just > a function that notifies assistive technology of the bounding rect of the > focused region within the canvas. It's still useful, but if that's all it > does, then drawCustomFocusRing is a poor name. Perhaps it should be called > something like notifyFocusLocation or something like that. > 'drawCustomFocusRing' returns a boolean that signals the author that he is supposed to draw the focus ring. If you want to rename it, then maybe 'needsFocusRing' is better. 'drawSystemFocusRing' could then be simplified to 'drawFocusRing' From cabanier at gmail.com Mon Sep 30 13:25:41 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Mon, 30 Sep 2013 13:25:41 -0700 Subject: [whatwg] Outline style to use for drawSystemFocusRing In-Reply-To: <CAGN7qDDhuCSSbBtF6gLTUy06sKoNXub3hD6EcUCvKr4ojkzhMA@mail.gmail.com> References: <CAFz-FYxS-sLLOMA2=5bj-aJ1bmsBq8w_4Rminw_JLCMnYaMfPw@mail.gmail.com> <alpine.DEB.2.00.1307242308540.27623@ps20323.dreamhostps.com> <CAGN7qDCdCR1F-D9PtEKUcHkh5KdwKhum4vEAyUQ0VkLeeC+PCA@mail.gmail.com> <alpine.DEB.2.00.1307292147040.27623@ps20323.dreamhostps.com> <CAGN7qDAaq8XnX1z_BbpLVhgE5m4j--b720ZuHSEzq_iN1es0=Q@mail.gmail.com> <alpine.DEB.2.00.1307300020510.27623@ps20323.dreamhostps.com> <CAGN7qDAjRPOQ25gQT+BY+sp8Y503_9KxTa1j2aZSGYU-9BmBVA@mail.gmail.com> <CAFz-FYzzPFU3g+fM+QGbEDAJ-3DSU2qGHY9R+heZRbAWVAN2rw@mail.gmail.com> <CAGN7qDDu3PNxK9PTVr09sqUc0FrOnXgRaQDwLXQ13BhH_=85Bw@mail.gmail.com> <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> <alpine.DEB.2.00.1309120051240.12199@ps20323.dreamhostps.com> <CAFz-FYwi6tQ7WcODc3MBC=6pM_=G5ZONe=nVSHLs5EGTiUjE=w@mail.gmail.com> <CAGN7qDDhuCSSbBtF6gLTUy06sKoNXub3hD6EcUCvKr4ojkzhMA@mail.gmail.com> Message-ID: <CAGN7qDASLvnt8N=CfEKKpB9YYhAtnKkWP5q_KEkLVm9cCL=-2g@mail.gmail.com> Ian pointed out on IRC that 'drawCustomFocusRing' *could* draw if the user requested high contrast rings. (Since I prototyped it in Firefox which does not have this feature, I forgot about that case) In light of that, maybe it's OK to leave the spec as-is. ' notifyFocusLocation' is just as confusing... On Mon, Sep 30, 2013 at 10:15 AM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > On Thu, Sep 12, 2013 at 9:32 AM, Dominic Mazzoni <dmazzoni at google.com>wrote: > >> On Wed, Sep 11, 2013 at 5:54 PM, Ian Hickson <ian at hixie.ch> wrote: >> >> > On Tue, 10 Sep 2013, Dominic Mazzoni wrote: >> > > >> > > We've finished implementing drawSystemFocusRing and >> drawCustomFocusRing >> > > in Chrome. Try it in Chrome 31 or higher (either canary or dev channel >> > > should work today). You'll need to go to chrome://flags and enable >> > > *experimental canvas features*, then restart the browser. >> > > >> > > Here's a demo I built that uses drawSystemFocusRing: >> > > http://dmazzoni-google.github.io/canvas-focus-ring-demo/ >> > >> > Looks good. Was your conclusion that the spec was ok as is, or did you >> > deviate from the spec in some way that needs a spec change >> > >> >> I think drawSystemFocusRing is good to go. If you want, you can update the >> spec to reflect that an implementation is available (behind a flag). >> >> Only one minor issue for clarification: if the current path is a line or >> unclosed polygon, should it be closed (or otherwise outlined) when drawing >> the focus ring? Currently we're not doing so in Chrome, but it might help >> to clarify. For example, if the path is a line, what's drawn is just an >> additional stroke on that line, not a "ring". >> >> I'm not as sure about drawCustomFocusRing. The spec says "If the user has >> requested the use of particular focus rings", but I'm not aware of any >> platform API we could use to query that. To the best of my knowledge, >> assistive technology that draws its own focus rings, like ZoomText, >> normally draws an additional focus ring with extra padding, rather than >> replacing the system one. (Example: >> http://www.aisquared.com/zoomtext/tour/enhancements#focus_enhancements) >> >> So, I'm not sure how I'd implement that part of the spec. Chrome >> definitely >> has no plans to give users an additional preference for focus rings as a >> browser setting. >> >> So, what we implemented in Chrome for drawCustomFocusRing is basically >> just >> a function that notifies assistive technology of the bounding rect of the >> focused region within the canvas. It's still useful, but if that's all it >> does, then drawCustomFocusRing is a poor name. Perhaps it should be called >> something like notifyFocusLocation or something like that. >> > > 'drawCustomFocusRing' returns a boolean that signals the author that he > is supposed to draw the focus ring. > If you want to rename it, then maybe 'needsFocusRing' is better. > > 'drawSystemFocusRing' could then be simplified to 'drawFocusRing' > From dmazzoni at google.com Mon Sep 30 13:48:19 2013 From: dmazzoni at google.com (Dominic Mazzoni) Date: Mon, 30 Sep 2013 13:48:19 -0700 Subject: [whatwg] Outline style to use for drawSystemFocusRing In-Reply-To: <CAGN7qDASLvnt8N=CfEKKpB9YYhAtnKkWP5q_KEkLVm9cCL=-2g@mail.gmail.com> References: <CAFz-FYxS-sLLOMA2=5bj-aJ1bmsBq8w_4Rminw_JLCMnYaMfPw@mail.gmail.com> <alpine.DEB.2.00.1307242308540.27623@ps20323.dreamhostps.com> <CAGN7qDCdCR1F-D9PtEKUcHkh5KdwKhum4vEAyUQ0VkLeeC+PCA@mail.gmail.com> <alpine.DEB.2.00.1307292147040.27623@ps20323.dreamhostps.com> <CAGN7qDAaq8XnX1z_BbpLVhgE5m4j--b720ZuHSEzq_iN1es0=Q@mail.gmail.com> <alpine.DEB.2.00.1307300020510.27623@ps20323.dreamhostps.com> <CAGN7qDAjRPOQ25gQT+BY+sp8Y503_9KxTa1j2aZSGYU-9BmBVA@mail.gmail.com> <CAFz-FYzzPFU3g+fM+QGbEDAJ-3DSU2qGHY9R+heZRbAWVAN2rw@mail.gmail.com> <CAGN7qDDu3PNxK9PTVr09sqUc0FrOnXgRaQDwLXQ13BhH_=85Bw@mail.gmail.com> <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> <alpine.DEB.2.00.1309120051240.12199@ps20323.dreamhostps.com> <CAFz-FYwi6tQ7WcODc3MBC=6pM_=G5ZONe=nVSHLs5EGTiUjE=w@mail.gmail.com> <CAGN7qDDhuCSSbBtF6gLTUy06sKoNXub3hD6EcUCvKr4ojkzhMA@mail.gmail.com> <CAGN7qDASLvnt8N=CfEKKpB9YYhAtnKkWP5q_KEkLVm9cCL=-2g@mail.gmail.com> Message-ID: <CAFz-FYwBdi9-t1r+2i6X_zaZAuUuLWJtyHngysB70aqhkAnOGQ@mail.gmail.com> On Mon, Sep 30, 2013 at 1:25 PM, Rik Cabanier <cabanier at gmail.com> wrote: > Ian pointed out on IRC that 'drawCustomFocusRing' *could* draw if the > user requested high contrast rings. (Since I prototyped it in Firefox which > does not have this feature, I forgot about that case) > Yes, but I'm arguing that the high contrast rings is not a good idea and we should drop that part of the spec. Once that part is gone (or once no browser has plans to implement that part), drawCustomFocusRing no longer makes sense. > In light of that, maybe it's OK to leave the spec as-is. ' > notifyFocusLocation' is just as confusing... > I don't think notifyFocusLocation is just as confusing as having a drawCustomFocusRing API that never actually draws. I do agree that most web developers might not realize who is being notified and why, but they can at least surmise that *someone* cares about the focus location and wants to be told where it is. Here's my alternative idea, though: how about calling it something like scrollFocusedObjectIntoView, and have the *primary* purpose of the API be to make the browser scroll the viewport, if needed to make sure that the bounding box of the path is visible, if that object is focused. The drawFocusRing spec would be modified to specify that scrolling the viewport is part of the spec, too. Both APIs would also have accessibility implications, of course - but the average web developer who doesn't know much about accessibility would have two useful APIs for handling focused controls in a canvas, that are easy to test if they're working in any browser. - Dominic > > > > On Mon, Sep 30, 2013 at 10:15 AM, Rik Cabanier <cabanier at gmail.com> wrote: > >> >> >> >> On Thu, Sep 12, 2013 at 9:32 AM, Dominic Mazzoni <dmazzoni at google.com>wrote: >> >>> On Wed, Sep 11, 2013 at 5:54 PM, Ian Hickson <ian at hixie.ch> wrote: >>> >>> > On Tue, 10 Sep 2013, Dominic Mazzoni wrote: >>> > > >>> > > We've finished implementing drawSystemFocusRing and >>> drawCustomFocusRing >>> > > in Chrome. Try it in Chrome 31 or higher (either canary or dev >>> channel >>> > > should work today). You'll need to go to chrome://flags and enable >>> > > *experimental canvas features*, then restart the browser. >>> > > >>> > > Here's a demo I built that uses drawSystemFocusRing: >>> > > http://dmazzoni-google.github.io/canvas-focus-ring-demo/ >>> > >>> > Looks good. Was your conclusion that the spec was ok as is, or did you >>> > deviate from the spec in some way that needs a spec change >>> > >>> >>> I think drawSystemFocusRing is good to go. If you want, you can update >>> the >>> spec to reflect that an implementation is available (behind a flag). >>> >>> Only one minor issue for clarification: if the current path is a line or >>> unclosed polygon, should it be closed (or otherwise outlined) when >>> drawing >>> the focus ring? Currently we're not doing so in Chrome, but it might help >>> to clarify. For example, if the path is a line, what's drawn is just an >>> additional stroke on that line, not a "ring". >>> >>> I'm not as sure about drawCustomFocusRing. The spec says "If the user has >>> requested the use of particular focus rings", but I'm not aware of any >>> platform API we could use to query that. To the best of my knowledge, >>> assistive technology that draws its own focus rings, like ZoomText, >>> normally draws an additional focus ring with extra padding, rather than >>> replacing the system one. (Example: >>> http://www.aisquared.com/zoomtext/tour/enhancements#focus_enhancements) >>> >>> So, I'm not sure how I'd implement that part of the spec. Chrome >>> definitely >>> has no plans to give users an additional preference for focus rings as a >>> browser setting. >>> >>> So, what we implemented in Chrome for drawCustomFocusRing is basically >>> just >>> a function that notifies assistive technology of the bounding rect of the >>> focused region within the canvas. It's still useful, but if that's all it >>> does, then drawCustomFocusRing is a poor name. Perhaps it should be >>> called >>> something like notifyFocusLocation or something like that. >>> >> >> 'drawCustomFocusRing' returns a boolean that signals the author that he >> is supposed to draw the focus ring. >> If you want to rename it, then maybe 'needsFocusRing' is better. >> >> 'drawSystemFocusRing' could then be simplified to 'drawFocusRing' >> > > From wiltzius at chromium.org Mon Sep 30 14:03:06 2013 From: wiltzius at chromium.org (Tom Wiltzius) Date: Mon, 30 Sep 2013 14:03:06 -0700 Subject: [whatwg] Adding 2D Canvas features In-Reply-To: <alpine.DEB.2.00.1309272108410.12199@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <51D12692.4030002@artspark.co.jp> <CAK-G-KVLsECC4cETFYdcPyoqigaaoRhUxcezhMG3jZc2fAViRg@mail.gmail.com> <alpine.DEB.2.00.1309052049070.7443@ps20323.dreamhostps.com> <CAA5isUYmMm9sHu=_Ybwmhw7GWfO+vRpP+8MdM_+OXKPCc+i4+Q@mail.gmail.com> <CAK-G-KUOzNXhRfZRTtmuYFHHcHDriSodcRmoORGqi4XhFevNuQ@mail.gmail.com> <alpine.DEB.2.00.1309272108410.12199@ps20323.dreamhostps.com> Message-ID: <CAK-G-KV64xnPGLfz+66bRFpgt5escPqPxZX8rR4SuT+k2xRC0g@mail.gmail.com> On Fri, Sep 27, 2013 at 2:21 PM, Ian Hickson <ian at hixie.ch> wrote: > On Thu, 5 Sep 2013, Tom Wiltzius wrote: > > > > Meanwhile this doesn't change the other Canvas2D-related work ongoing in > > the Chromium project, so we're still keen to see some new features added > > to the Canvas spec. Ian if it would help to identify items in the spec > > that Chromium doesn't intend to implement (at least any time soon), we > > can attempt to do so. > > If there are specific things in the spec that you think are bad and should > be removed, please do raise them on the mailing list, yes. > I think we're reasonably certain that *HD methods should be removed, but those are the only solid ones. > > If there are specific things not in the spec that you have implemented, > then please file a bug pointing to the documentation for whatever you have > implemented, using: http://whatwg.org/newbug > > If there's multiple implementations, and HTML is the right spec, then I'll > pretty much automatically spec it. Otherwise, it'll be based on whether it > makes sense and has use cases. (So far example, I haven't added canvas > text decoration APIs, which have been raised as something Chrome might > implement, as discussed in my last e-mail to this list. The alpha > parameter, though, needs speccing, I just haven't gotten around to it > yet -- it's on my list though.) > Great, I was wondering specifically about the status of the alpha attribute-- glad to hear it's just spec'ing that needs to happen, I wasn't clear on if this was blocked on "no new features" or not. Thanks! > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > From junov at google.com Mon Sep 30 14:17:58 2013 From: junov at google.com (Justin Novosad) Date: Mon, 30 Sep 2013 17:17:58 -0400 Subject: [whatwg] 2D canvas feature proposal: text decoration In-Reply-To: <alpine.DEB.2.00.1309272041490.12199@ps20323.dreamhostps.com> References: <CABpaAqS79N2Xfqy+CrniQJBDSzmaYgxFmdboBK9AtMCFGrvjTg@mail.gmail.com> <CAGN7qDCpb3CWi0j9uibGfn4wKCpf+YfUHLfzj7kJr46Z=TuXew@mail.gmail.com> <CABpaAqTFpDq5HMQyDCRVx3ru_KVeUniaySb6eFocnrg7kgqXgQ@mail.gmail.com> <CAGN7qDD2Z=g11F2PXMFtFQPedmfEtzs4oKsQSsRiJ8qwGQk2pw@mail.gmail.com> <CAAWBYDCuv9gxz1utnsMQ2OsYhgo+gJH6W+_=5Gko7XmJekoSKw@mail.gmail.com> <CAGN7qDC6Dj1aoAtwiRzdm5L83=4yq2GhpXjhddyAQbF44LtwYQ@mail.gmail.com> <CAAWBYDDbpXtAs3V8vvPBWXe4aNOfy+hU-2bre3_ie-sSQ7Q=rQ@mail.gmail.com> <CAGN7qDBT1+=m_yL=RTR1M0bhY6s3gtEXwLgnfXZTAsBEOMEFdg@mail.gmail.com> <CABpaAqQ87sLn_dqHwr9ZPLeeE665_2irC+mMhDGK4j=hWd7fTw@mail.gmail.com> <51716E59.6080609@mit.edu> <alpine.DEB.2.00.1308202224320.27209@ps20323.dreamhostps.com> <CABpaAqTWJq+-zrGj-Rnme1XLbDyp-2m5Bpnx8ubuo1QLr9SJWw@mail.gmail.com> <alpine.DEB.2.00.1309272041490.12199@ps20323.dreamhostps.com> Message-ID: <CABpaAqQTpMMuW_RXhp74kKqFBiP6OhngvsFnb7or5DZioYFUOQ@mail.gmail.com> On Fri, Sep 27, 2013 at 5:05 PM, Ian Hickson <ian at hixie.ch> wrote: > > > Text decoration can theoretically be drawn directly by the application > > by using font metrics to compute decoration positions, but this is often > > very complex to do correctly in a truly portable way. > > We could add underline metrics to TextMetrics if that would help. > > Perhaps that would be the right solution, but I don't know enough about metrics to authoritatively state what information is missing. The fact that most browsers do not fully support the text metrics as currently spec'ed does not help either (I know, Chrome is one of the worst offenders w.r.t. metrics support). > > If doing things with CSS and the DOM is > too slow, then we should fix that, we shouldn't just tell people to > rewrite their apps in <canvas>. > Easier said than done. In theory, it should be possible to obtain canvas-like performance when DOM usage is constrained to styles that make layout calculations trivial (as in no-op). However, this is still a more or less unsolved problem despite the best efforts of a large number of very smart people. Let's not hold our breaths. > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > From cabanier at gmail.com Mon Sep 30 15:21:01 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Mon, 30 Sep 2013 15:21:01 -0700 Subject: [whatwg] Outline style to use for drawSystemFocusRing In-Reply-To: <CAFz-FYwBdi9-t1r+2i6X_zaZAuUuLWJtyHngysB70aqhkAnOGQ@mail.gmail.com> References: <CAFz-FYxS-sLLOMA2=5bj-aJ1bmsBq8w_4Rminw_JLCMnYaMfPw@mail.gmail.com> <alpine.DEB.2.00.1307242308540.27623@ps20323.dreamhostps.com> <CAGN7qDCdCR1F-D9PtEKUcHkh5KdwKhum4vEAyUQ0VkLeeC+PCA@mail.gmail.com> <alpine.DEB.2.00.1307292147040.27623@ps20323.dreamhostps.com> <CAGN7qDAaq8XnX1z_BbpLVhgE5m4j--b720ZuHSEzq_iN1es0=Q@mail.gmail.com> <alpine.DEB.2.00.1307300020510.27623@ps20323.dreamhostps.com> <CAGN7qDAjRPOQ25gQT+BY+sp8Y503_9KxTa1j2aZSGYU-9BmBVA@mail.gmail.com> <CAFz-FYzzPFU3g+fM+QGbEDAJ-3DSU2qGHY9R+heZRbAWVAN2rw@mail.gmail.com> <CAGN7qDDu3PNxK9PTVr09sqUc0FrOnXgRaQDwLXQ13BhH_=85Bw@mail.gmail.com> <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> <alpine.DEB.2.00.1309120051240.12199@ps20323.dreamhostps.com> <CAFz-FYwi6tQ7WcODc3MBC=6pM_=G5ZONe=nVSHLs5EGTiUjE=w@mail.gmail.com> <CAGN7qDDhuCSSbBtF6gLTUy06sKoNXub3hD6EcUCvKr4ojkzhMA@mail.gmail.com> <CAGN7qDASLvnt8N=CfEKKpB9YYhAtnKkWP5q_KEkLVm9cCL=-2g@mail.gmail.com> <CAFz-FYwBdi9-t1r+2i6X_zaZAuUuLWJtyHngysB70aqhkAnOGQ@mail.gmail.com> Message-ID: <CAGN7qDCHL9g8TsBFpFNQfu3Pjgf-KTRQavzz=QBs_M4H86aL8g@mail.gmail.com> On Mon, Sep 30, 2013 at 1:48 PM, Dominic Mazzoni <dmazzoni at google.com>wrote: > On Mon, Sep 30, 2013 at 1:25 PM, Rik Cabanier <cabanier at gmail.com> wrote: > >> Ian pointed out on IRC that 'drawCustomFocusRing' *could* draw if the >> user requested high contrast rings. (Since I prototyped it in Firefox which >> does not have this feature, I forgot about that case) >> > > Yes, but I'm arguing that the high contrast rings is not a good idea and > we should drop that part of the spec. Once that part is gone (or once no > browser has plans to implement that part), drawCustomFocusRing no longer > makes sense. > I just checked Windows and they offer the option "Make the focus rectangle thicker". I checked IE and it honors that setting. It's too bad that we didn't get feedback from them but it does look like this is something IE would implement. > > >> In light of that, maybe it's OK to leave the spec as-is. ' >> notifyFocusLocation' is just as confusing... >> > > I don't think notifyFocusLocation is just as confusing as having a drawCustomFocusRing > API that never actually draws. I do agree that most web developers might > not realize who is being notified and why, but they can at least surmise > that *someone* cares about the focus location and wants to be told where it > is. > But it's not a 'notify' action though. You're basically asking the browser if the author should draw the focus area (while also telling the browser about the region) > > Here's my alternative idea, though: how about calling it something like > scrollFocusedObjectIntoView, and have the *primary* purpose of the API be > to make the browser scroll the viewport, if needed to make sure that the > bounding box of the path is visible, if that object is focused. The > drawFocusRing spec would be modified to specify that scrolling the viewport > is part of the spec, too. > That sounds very much like 'scrollPathIntoView'. I think that this is changing the API too much. > > Both APIs would also have accessibility implications, of course - but the > average web developer who doesn't know much about accessibility would have > two useful APIs for handling focused controls in a canvas, that are easy to > test if they're working in any browser. > > - Dominic > > >> >> >> >> On Mon, Sep 30, 2013 at 10:15 AM, Rik Cabanier <cabanier at gmail.com>wrote: >> >>> >>> >>> >>> On Thu, Sep 12, 2013 at 9:32 AM, Dominic Mazzoni <dmazzoni at google.com>wrote: >>> >>>> On Wed, Sep 11, 2013 at 5:54 PM, Ian Hickson <ian at hixie.ch> wrote: >>>> >>>> > On Tue, 10 Sep 2013, Dominic Mazzoni wrote: >>>> > > >>>> > > We've finished implementing drawSystemFocusRing and >>>> drawCustomFocusRing >>>> > > in Chrome. Try it in Chrome 31 or higher (either canary or dev >>>> channel >>>> > > should work today). You'll need to go to chrome://flags and enable >>>> > > *experimental canvas features*, then restart the browser. >>>> > > >>>> > > Here's a demo I built that uses drawSystemFocusRing: >>>> > > http://dmazzoni-google.github.io/canvas-focus-ring-demo/ >>>> > >>>> > Looks good. Was your conclusion that the spec was ok as is, or did you >>>> > deviate from the spec in some way that needs a spec change >>>> > >>>> >>>> I think drawSystemFocusRing is good to go. If you want, you can update >>>> the >>>> spec to reflect that an implementation is available (behind a flag). >>>> >>>> Only one minor issue for clarification: if the current path is a line or >>>> unclosed polygon, should it be closed (or otherwise outlined) when >>>> drawing >>>> the focus ring? Currently we're not doing so in Chrome, but it might >>>> help >>>> to clarify. For example, if the path is a line, what's drawn is just an >>>> additional stroke on that line, not a "ring". >>>> >>>> I'm not as sure about drawCustomFocusRing. The spec says "If the user >>>> has >>>> requested the use of particular focus rings", but I'm not aware of any >>>> platform API we could use to query that. To the best of my knowledge, >>>> assistive technology that draws its own focus rings, like ZoomText, >>>> normally draws an additional focus ring with extra padding, rather than >>>> replacing the system one. (Example: >>>> http://www.aisquared.com/zoomtext/tour/enhancements#focus_enhancements) >>>> >>>> So, I'm not sure how I'd implement that part of the spec. Chrome >>>> definitely >>>> has no plans to give users an additional preference for focus rings as a >>>> browser setting. >>>> >>>> So, what we implemented in Chrome for drawCustomFocusRing is basically >>>> just >>>> a function that notifies assistive technology of the bounding rect of >>>> the >>>> focused region within the canvas. It's still useful, but if that's all >>>> it >>>> does, then drawCustomFocusRing is a poor name. Perhaps it should be >>>> called >>>> something like notifyFocusLocation or something like that. >>>> >>> >>> 'drawCustomFocusRing' returns a boolean that signals the author that he >>> is supposed to draw the focus ring. >>> If you want to rename it, then maybe 'needsFocusRing' is better. >>> >>> 'drawSystemFocusRing' could then be simplified to 'drawFocusRing' >>> >> >> > From dmazzoni at google.com Mon Sep 30 15:31:05 2013 From: dmazzoni at google.com (Dominic Mazzoni) Date: Mon, 30 Sep 2013 15:31:05 -0700 Subject: [whatwg] Outline style to use for drawSystemFocusRing In-Reply-To: <CAGN7qDCHL9g8TsBFpFNQfu3Pjgf-KTRQavzz=QBs_M4H86aL8g@mail.gmail.com> References: <CAFz-FYxS-sLLOMA2=5bj-aJ1bmsBq8w_4Rminw_JLCMnYaMfPw@mail.gmail.com> <alpine.DEB.2.00.1307242308540.27623@ps20323.dreamhostps.com> <CAGN7qDCdCR1F-D9PtEKUcHkh5KdwKhum4vEAyUQ0VkLeeC+PCA@mail.gmail.com> <alpine.DEB.2.00.1307292147040.27623@ps20323.dreamhostps.com> <CAGN7qDAaq8XnX1z_BbpLVhgE5m4j--b720ZuHSEzq_iN1es0=Q@mail.gmail.com> <alpine.DEB.2.00.1307300020510.27623@ps20323.dreamhostps.com> <CAGN7qDAjRPOQ25gQT+BY+sp8Y503_9KxTa1j2aZSGYU-9BmBVA@mail.gmail.com> <CAFz-FYzzPFU3g+fM+QGbEDAJ-3DSU2qGHY9R+heZRbAWVAN2rw@mail.gmail.com> <CAGN7qDDu3PNxK9PTVr09sqUc0FrOnXgRaQDwLXQ13BhH_=85Bw@mail.gmail.com> <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> <alpine.DEB.2.00.1309120051240.12199@ps20323.dreamhostps.com> <CAFz-FYwi6tQ7WcODc3MBC=6pM_=G5ZONe=nVSHLs5EGTiUjE=w@mail.gmail.com> <CAGN7qDDhuCSSbBtF6gLTUy06sKoNXub3hD6EcUCvKr4ojkzhMA@mail.gmail.com> <CAGN7qDASLvnt8N=CfEKKpB9YYhAtnKkWP5q_KEkLVm9cCL=-2g@mail.gmail.com> <CAFz-FYwBdi9-t1r+2i6X_zaZAuUuLWJtyHngysB70aqhkAnOGQ@mail.gmail.com> <CAGN7qDCHL9g8TsBFpFNQfu3Pjgf-KTRQavzz=QBs_M4H86aL8g@mail.gmail.com> Message-ID: <CAFz-FYyEKYyJYvTMXDJ1f+zmZpxSMpG26xxX37Ne2tDd9tq5Yg@mail.gmail.com> On Mon, Sep 30, 2013 at 3:21 PM, Rik Cabanier <cabanier at gmail.com> wrote: > I just checked Windows and they offer the option "Make the focus rectangle > thicker". I checked IE and it honors that setting. > It's too bad that we didn't get feedback from them but it does look like > this is something IE would implement. > Yes, and drawSystemFocusRing should respect the thicker focus rectangle. I don't think that drawCustomFocusRing should switch to the system focus rectangle style just because that preference was set - it might look horrible on a particular canvas. Plus, Rich's original argument wasn't about the "make the focus rectangle thicker", it was about handling Windows high contrast mode correctly - but again, I still don't think that the system is going to do a better job at drawing a focus ring on a canvas just because high contrast mode is on. What we really need is an API for web developers to know if high contrast mode is on, and that's orthogonal to canvas. Here's my alternative idea, though: how about calling it something like >> scrollFocusedObjectIntoView, and have the *primary* purpose of the API be >> to make the browser scroll the viewport, if needed to make sure that the >> bounding box of the path is visible, if that object is focused. The >> drawFocusRing spec would be modified to specify that scrolling the viewport >> is part of the spec, too. >> > > That sounds very much like 'scrollPathIntoView'. > I think that this is changing the API too much. > I still don't understand why we're in a situation where we can't change it too much. If the choice is ship drawCustomFocusRing with flaws or delay it until the next revision so we can get it right, my vote is firmly for the latter. I do not support shipping it as-is. - Dominic From ian at hixie.ch Mon Sep 30 16:00:46 2013 From: ian at hixie.ch (Ian Hickson) Date: Mon, 30 Sep 2013 23:00:46 +0000 (UTC) Subject: [whatwg] Adding 2D Canvas features In-Reply-To: <CAK-G-KV64xnPGLfz+66bRFpgt5escPqPxZX8rR4SuT+k2xRC0g@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <51D12692.4030002@artspark.co.jp> <CAK-G-KVLsECC4cETFYdcPyoqigaaoRhUxcezhMG3jZc2fAViRg@mail.gmail.com> <alpine.DEB.2.00.1309052049070.7443@ps20323.dreamhostps.com> <CAA5isUYmMm9sHu=_Ybwmhw7GWfO+vRpP+8MdM_+OXKPCc+i4+Q@mail.gmail.com> <CAK-G-KUOzNXhRfZRTtmuYFHHcHDriSodcRmoORGqi4XhFevNuQ@mail.gmail.com> <alpine.DEB.2.00.1309272108410.12199@ps20323.dreamhostps.com> <CAK-G-KV64xnPGLfz+66bRFpgt5escPqPxZX8rR4SuT+k2xRC0g@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309302257590.20189@ps20323.dreamhostps.com> On Mon, 30 Sep 2013, Tom Wiltzius wrote: > On Fri, Sep 27, 2013 at 2:21 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Thu, 5 Sep 2013, Tom Wiltzius wrote: > > > > > > Meanwhile this doesn't change the other Canvas2D-related work > > > ongoing in the Chromium project, so we're still keen to see some new > > > features added to the Canvas spec. Ian if it would help to identify > > > items in the spec that Chromium doesn't intend to implement (at > > > least any time soon), we can attempt to do so. > > > > If there are specific things in the spec that you think are bad and > > should be removed, please do raise them on the mailing list, yes. > > I think we're reasonably certain that *HD methods should be removed, but > those are the only solid ones. Yeah those are going to be cut, I'm just trying to figure out how to replace them. See: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Sep/thread.html#msg68 > > If there are specific things not in the spec that you have > > implemented, then please file a bug pointing to the documentation for > > whatever you have implemented, using: http://whatwg.org/newbug > > > > If there's multiple implementations, and HTML is the right spec, then > > I'll pretty much automatically spec it. Otherwise, it'll be based on > > whether it makes sense and has use cases. (So far example, I haven't > > added canvas text decoration APIs, which have been raised as something > > Chrome might implement, as discussed in my last e-mail to this list. > > The alpha parameter, though, needs speccing, I just haven't gotten > > around to it yet -- it's on my list though.) > > Great, I was wondering specifically about the status of the alpha > attribute-- glad to hear it's just spec'ing that needs to happen, I > wasn't clear on if this was blocked on "no new features" or not. Thanks! The idea of limiting the rate of spec additions is to limit the rate of new implementations. If the implementations already exist, there's no point not adding it to the spec. :-) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Mon Sep 30 16:10:25 2013 From: ian at hixie.ch (Ian Hickson) Date: Mon, 30 Sep 2013 23:10:25 +0000 (UTC) Subject: [whatwg] Outline style to use for drawSystemFocusRing In-Reply-To: <CAFz-FYwBdi9-t1r+2i6X_zaZAuUuLWJtyHngysB70aqhkAnOGQ@mail.gmail.com> References: <CAFz-FYxS-sLLOMA2=5bj-aJ1bmsBq8w_4Rminw_JLCMnYaMfPw@mail.gmail.com> <alpine.DEB.2.00.1307292147040.27623@ps20323.dreamhostps.com> <CAGN7qDAaq8XnX1z_BbpLVhgE5m4j--b720ZuHSEzq_iN1es0=Q@mail.gmail.com> <alpine.DEB.2.00.1307300020510.27623@ps20323.dreamhostps.com> <CAGN7qDAjRPOQ25gQT+BY+sp8Y503_9KxTa1j2aZSGYU-9BmBVA@mail.gmail.com> <CAFz-FYzzPFU3g+fM+QGbEDAJ-3DSU2qGHY9R+heZRbAWVAN2rw@mail.gmail.com> <CAGN7qDDu3PNxK9PTVr09sqUc0FrOnXgRaQDwLXQ13BhH_=85Bw@mail.gmail.com> <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> <alpine.DEB.2.00.1309120051240.12199@ps20323.dreamhostps.com> <CAFz-FYwi6tQ7WcODc3MBC=6pM_=G5ZONe=nVSHLs5EGTiUjE=w@mail.gmail.com> <CAGN7qDDhuCSSbBtF6gLTUy06sKoNXub3hD6EcUCvKr4ojkzhMA@mail.gmail.com> <CAGN7qDASLvnt8N=CfEKKpB9YYhAtnKkWP5q_KEkLVm9cCL=-2g@mail.gmail.com> <CAFz-FYwBdi9-t1r+2i6X_zaZAuUuLWJtyHngysB70aqhkAnOGQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309302300540.20189@ps20323.dreamhostps.com> On Mon, 30 Sep 2013, Rik Cabanier wrote: > > 'drawCustomFocusRing' returns a boolean that signals the author that he > is supposed to draw the focus ring. If you want to rename it, then maybe > 'needsFocusRing' is better. > > 'drawSystemFocusRing' could then be simplified to 'drawFocusRing' On Mon, 30 Sep 2013, Rik Cabanier wrote: > > Ian pointed out on IRC that 'drawCustomFocusRing' *could* draw if the > user requested high contrast rings. (Since I prototyped it in Firefox > which does not have this feature, I forgot about that case) > > In light of that, maybe it's OK to leave the spec as-is. ' > notifyFocusLocation' is just as confusing... Yeah... The current name isn't great, but I don't know what would be better (without making its name an essay or something). On Mon, 30 Sep 2013, Dominic Mazzoni wrote: > > Yes, but I'm arguing that the high contrast rings is not a good idea and > we should drop that part of the spec. Some users have great trouble seeing the default focus rings. > Once that part is gone (or once no browser has plans to implement that > part), drawCustomFocusRing no longer makes sense. It's certainly true that if we don't want to support users with poor vision, the API would be simpler. But I don't think that's an option. We don't get to arbitrarily ignore some users. But drawCustomFocusRing() does more than just draw high-contrast focus rings. It also moves the magnification, moves the screen-reader focus, etc. It does everything drawSystemFocusRing() does other than draw the actual focus ring. > Here's my alternative idea, though: how about calling it something like > scrollFocusedObjectIntoView, and have the *primary* purpose of the API > be to make the browser scroll the viewport, if needed to make sure that > the bounding box of the path is visible, if that object is focused. The > drawFocusRing spec would be modified to specify that scrolling the > viewport is part of the spec, too. How would this differ from scrollPathIntoView() ? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Mon Sep 30 16:12:08 2013 From: ian at hixie.ch (Ian Hickson) Date: Mon, 30 Sep 2013 23:12:08 +0000 (UTC) Subject: [whatwg] Outline style to use for drawSystemFocusRing In-Reply-To: <CAFz-FYyEKYyJYvTMXDJ1f+zmZpxSMpG26xxX37Ne2tDd9tq5Yg@mail.gmail.com> References: <CAFz-FYxS-sLLOMA2=5bj-aJ1bmsBq8w_4Rminw_JLCMnYaMfPw@mail.gmail.com> <alpine.DEB.2.00.1307300020510.27623@ps20323.dreamhostps.com> <CAGN7qDAjRPOQ25gQT+BY+sp8Y503_9KxTa1j2aZSGYU-9BmBVA@mail.gmail.com> <CAFz-FYzzPFU3g+fM+QGbEDAJ-3DSU2qGHY9R+heZRbAWVAN2rw@mail.gmail.com> <CAGN7qDDu3PNxK9PTVr09sqUc0FrOnXgRaQDwLXQ13BhH_=85Bw@mail.gmail.com> <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> <alpine.DEB.2.00.1309120051240.12199@ps20323.dreamhostps.com> <CAFz-FYwi6tQ7WcODc3MBC=6pM_=G5ZONe=nVSHLs5EGTiUjE=w@mail.gmail.com> <CAGN7qDDhuCSSbBtF6gLTUy06sKoNXub3hD6EcUCvKr4ojkzhMA@mail.gmail.com> <CAGN7qDASLvnt8N=CfEKKpB9YYhAtnKkWP5q_KEkLVm9cCL=-2g@mail.gmail.com> <CAFz-FYwBdi9-t1r+2i6X_zaZAuUuLWJtyHngysB70aqhkAnOGQ@mail.gmail.com> <CAGN7qDCHL9g8TsBFpFNQfu3Pjgf-KTRQavzz=QBs_M4H86aL8g@mail.gmail.com> <CAFz-FYyEKYyJYvTMXDJ1f+zmZpxSMpG26xxX37Ne2tDd9tq5Yg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309302310570.20189@ps20323.dreamhostps.com> On Mon, 30 Sep 2013, Dominic Mazzoni wrote: > > I don't think that drawCustomFocusRing should switch to the system focus > rectangle style just because that preference was set - it might look > horrible on a particular canvas. It's the whole point of the feature. Draw the focus ring the way the user needs it to be drawn, if there's a special need, otherwise, let me draw it my fancy hard-to-see way. > If the choice is ship drawCustomFocusRing with flaws or delay it until > the next revision so we can get it right, my vote is firmly for the > latter. I do not support shipping it as-is. I don't understand what the problem is with the current API, but I agree that if it's broken it should be fixed. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From chaals at yandex-team.ru Mon Sep 30 16:41:17 2013 From: chaals at yandex-team.ru (Charles McCathie Nevile) Date: Tue, 01 Oct 2013 01:41:17 +0200 Subject: [whatwg] Outline style to use for drawSystemFocusRing In-Reply-To: <alpine.DEB.2.00.1309302300540.20189@ps20323.dreamhostps.com> References: <CAFz-FYxS-sLLOMA2=5bj-aJ1bmsBq8w_4Rminw_JLCMnYaMfPw@mail.gmail.com> <alpine.DEB.2.00.1307292147040.27623@ps20323.dreamhostps.com> <CAGN7qDAaq8XnX1z_BbpLVhgE5m4j--b720ZuHSEzq_iN1es0=Q@mail.gmail.com> <alpine.DEB.2.00.1307300020510.27623@ps20323.dreamhostps.com> <CAGN7qDAjRPOQ25gQT+BY+sp8Y503_9KxTa1j2aZSGYU-9BmBVA@mail.gmail.com> <CAFz-FYzzPFU3g+fM+QGbEDAJ-3DSU2qGHY9R+heZRbAWVAN2rw@mail.gmail.com> <CAGN7qDDu3PNxK9PTVr09sqUc0FrOnXgRaQDwLXQ13BhH_=85Bw@mail.gmail.com> <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> <alpine.DEB.2.00.1309120051240.12199@ps20323.dreamhostps.com> <CAFz-FYwi6tQ7WcODc3MBC=6pM_=G5ZONe=nVSHLs5EGTiUjE=w@mail.gmail.com> <CAGN7qDDhuCSSbBtF6gLTUy06sKoNXub3hD6EcUCvKr4ojkzhMA@mail.gmail.com> <CAGN7qDASLvnt8N=CfEKKpB9YYhAtnKkWP5q_KEkLVm9cCL=-2g@mail.gmail.com> <CAFz-FYwBdi9-t1r+2i6X_zaZAuUuLWJtyHngysB70aqhkAnOGQ@mail.gmail.com> <alpine.DEB.2.00.1309302300540.20189@ps20323.dreamhostps.com> Message-ID: <op.w38z23pdy3oazb@chaals.local> On Tue, 01 Oct 2013 01:10:25 +0200, Ian Hickson <ian at hixie.ch> wrote: > On Mon, 30 Sep 2013, Rik Cabanier wrote: >> >> 'drawCustomFocusRing' returns a boolean that signals the author that he >> is supposed to draw the focus ring. If you want to rename it, then maybe >> 'needsFocusRing' is better. >> >> 'drawSystemFocusRing' could then be simplified to 'drawFocusRing' > > On Mon, 30 Sep 2013, Rik Cabanier wrote: >> >> Ian pointed out on IRC that 'drawCustomFocusRing' *could* draw if the >> user requested high contrast rings. (Since I prototyped it in Firefox >> which does not have this feature, I forgot about that case) >> >> In light of that, maybe it's OK to leave the spec as-is. ' >> notifyFocusLocation' is just as confusing... > > Yeah... The current name isn't great, but I don't know what would be > better (without making its name an essay or something). Right... > On Mon, 30 Sep 2013, Dominic Mazzoni wrote: >> >> Yes, but I'm arguing that the high contrast rings is not a good idea and >> we should drop that part of the spec. > > Some users have great trouble seeing the default focus rings. yeah. >> Once that part is gone (or once no browser has plans to implement that >> part), drawCustomFocusRing no longer makes sense. > > It's certainly true that if we don't want to support users with poor > vision, the API would be simpler. But I don't think that's an option. We > don't get to arbitrarily ignore some users. Yes, I hope not :) > But drawCustomFocusRing() does more than just draw high-contrast focus > rings. It also moves the magnification, moves the screen-reader focus, > etc. It does everything drawSystemFocusRing() does other than draw the > actual focus ring. So it seems that a real question is whether browsers prefer to deal with two APIs, or allow customisation of "the" focus ring. which comes down to a question of implementation strategy - do browsers rely on a system focus style, or draw it themselves, feeding from a system default style? >> Here's my alternative idea, though: how about calling it something like >> scrollFocusedObjectIntoView, and have the *primary* purpose of the API >> be to make the browser scroll the viewport, if needed to make sure that >> the bounding box of the path is visible, if that object is focused. The >> drawFocusRing spec would be modified to specify that scrolling the >> viewport is part of the spec, too. > > How would this differ from scrollPathIntoView() ? cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex chaals at yandex-team.ru Find more at http://yandex.com From dmazzoni at google.com Mon Sep 30 16:51:36 2013 From: dmazzoni at google.com (Dominic Mazzoni) Date: Mon, 30 Sep 2013 16:51:36 -0700 Subject: [whatwg] Outline style to use for drawSystemFocusRing In-Reply-To: <alpine.DEB.2.00.1309302310570.20189@ps20323.dreamhostps.com> References: <CAFz-FYxS-sLLOMA2=5bj-aJ1bmsBq8w_4Rminw_JLCMnYaMfPw@mail.gmail.com> <alpine.DEB.2.00.1307300020510.27623@ps20323.dreamhostps.com> <CAGN7qDAjRPOQ25gQT+BY+sp8Y503_9KxTa1j2aZSGYU-9BmBVA@mail.gmail.com> <CAFz-FYzzPFU3g+fM+QGbEDAJ-3DSU2qGHY9R+heZRbAWVAN2rw@mail.gmail.com> <CAGN7qDDu3PNxK9PTVr09sqUc0FrOnXgRaQDwLXQ13BhH_=85Bw@mail.gmail.com> <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> <alpine.DEB.2.00.1309120051240.12199@ps20323.dreamhostps.com> <CAFz-FYwi6tQ7WcODc3MBC=6pM_=G5ZONe=nVSHLs5EGTiUjE=w@mail.gmail.com> <CAGN7qDDhuCSSbBtF6gLTUy06sKoNXub3hD6EcUCvKr4ojkzhMA@mail.gmail.com> <CAGN7qDASLvnt8N=CfEKKpB9YYhAtnKkWP5q_KEkLVm9cCL=-2g@mail.gmail.com> <CAFz-FYwBdi9-t1r+2i6X_zaZAuUuLWJtyHngysB70aqhkAnOGQ@mail.gmail.com> <CAGN7qDCHL9g8TsBFpFNQfu3Pjgf-KTRQavzz=QBs_M4H86aL8g@mail.gmail.com> <CAFz-FYyEKYyJYvTMXDJ1f+zmZpxSMpG26xxX37Ne2tDd9tq5Yg@mail.gmail.com> <alpine.DEB.2.00.1309302310570.20189@ps20323.dreamhostps.com> Message-ID: <CAFz-FYxuYUg9ZLWkvORKOPsGjexRtFa9C2WsvN_b4Y-NQ_yE9A@mail.gmail.com> On Mon, Sep 30, 2013 at 4:12 PM, Ian Hickson <ian at hixie.ch> wrote: > > Some users have great trouble seeing the default focus rings. > ... > It's certainly true that if we don't want to support users with poor > vision, the API would be simpler. But I don't think that's an option. We > don't get to arbitrarily ignore some users. Of course not! I'm not arguing against supporting those users. The correct thing to do for those users is to use accessibility APIs to make the operating system aware of the focused object and its bounds. If users have ZoomText or MAGic installed, or if they're using VoiceOver or Orca, their assistive technology will draw its own focus ring *in addition* to the application's focus ring. No other application hides its focus ring just because, e.g., ZoomText is drawing a focus ring. The rest of the web doesn't do it. Why do we need it for canvas? On Mon, 30 Sep 2013, Dominic Mazzoni wrote: > > > > I don't think that drawCustomFocusRing should switch to the system focus > > rectangle style just because that preference was set - it might look > > horrible on a particular canvas. > > It's the whole point of the feature. Draw the focus ring the way the user > needs it to be drawn, if there's a special need, otherwise, let me draw it > my fancy hard-to-see way. > The problem is that there aren't existing operating system or browser settings that specifies that the user wants better focus rings. There are tools that draw additional focus rings, and preferences that control the appearance of the default focus ring, but no toggle that says *applications* should or shouldn't draw focus rings. Finally, as a meta-argument, if we really want a preference for custom focus rings, then wouldn't we want that for the rest of the web? If I'm building a custom form control and I need to choose a drawing style when focused, wouldn't I want to know if the user wanted custom focus rings, too? In other words, what makes this need canvas-specific? > How would this differ from scrollPathIntoView() ? It would take an element in fallback content as an argument. That would allow assistive technology to be notified. - Dominic From jrburke at gmail.com Mon Sep 30 17:27:18 2013 From: jrburke at gmail.com (James Burke) Date: Mon, 30 Sep 2013 17:27:18 -0700 Subject: [whatwg] Notifications: usage feedback In-Reply-To: <CAArhhishhjN4TnbXLicEV2fV7O77RY-r1M5Z1M-oJcsMzDOnoA@mail.gmail.com> References: <CAHgY_ifiJ-mjci7xAAasUTqM_jLVCzL9CwQuRJOe9LO8JbS=Gg@mail.gmail.com> <CAArhhishhjN4TnbXLicEV2fV7O77RY-r1M5Z1M-oJcsMzDOnoA@mail.gmail.com> Message-ID: <CAHgY_ifxZQQSvYfoJ==Ri5ZvG9N7Uu+Xu+yiQFarmmRycaSZ4g@mail.gmail.com> On Fri, Sep 27, 2013 at 12:54 AM, Andrew Wilson <atwilson at google.com> wrote: > So, I'm not entirely sure how many lessons taken from the FirefoxOS > implementation are applicable to the API for web pages in general, but I > agree that "what do we do if the user clicks on a notification after the > parent page has been closed" is a bit of an unsolved/unsolveable problem > with the current API. Hopefully the mobile focus of FirefoxOS points to likely issues for any browser on mobile. For example, I can see where it will be common for mobile browsers to do some sort of web page quiescence, even a full close, maybe just saving a screenshot of the tab, for memory concerns, even if the user still considers the tab "open". I expect the majority of browser use over time will fit into devices that fit the "mobile space" definition vs desktop space definition. > I dimly recall seeing an email thread proposing adding some kind of click > URL to a notification (and my search-fu is not strong enough to find a link > to it, sadly), which seems like it would address some of the issues you have > with the current API (encoding data that can be passed back to the app on a > notification click, even if the app has been closed in the meantime). The > solution I've seen implemented on the web (shutdown notifications when a web > page is closed) clearly doesn't work for a platform like FirefoxOS which > does memory management and app shutdown behind the scenes. An URL could work too (our hack right now is to attach data to the imageURL for the notification and read that data), but I still I prefer using a data object for the data of the notification. The notification object could have an URL associated with it, and the browser would open the URL if it did not already have a tab/process for it, then send a data message to it, but if the URL was already open, just send a data message to it with the notification object. In that approach the URL would not have querystring args, and the browser would match the URL to the URLs of existing opened tabs/apps, but without the query string or fragment ID to find a match. This would allow an already open page to handle multiple notification clicks via an entry point message handler discussed in the first post on this thread. In the cases of memory conscious browsers, it could rehydrate the tab that was currently tracked for that URL, and it would still work without needing to maintain closure state as compared to the notification.onclick/onclose route currently specified. James From cabanier at gmail.com Mon Sep 30 17:42:40 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Mon, 30 Sep 2013 17:42:40 -0700 Subject: [whatwg] Outline style to use for drawSystemFocusRing In-Reply-To: <CAFz-FYxuYUg9ZLWkvORKOPsGjexRtFa9C2WsvN_b4Y-NQ_yE9A@mail.gmail.com> References: <CAFz-FYxS-sLLOMA2=5bj-aJ1bmsBq8w_4Rminw_JLCMnYaMfPw@mail.gmail.com> <alpine.DEB.2.00.1307300020510.27623@ps20323.dreamhostps.com> <CAGN7qDAjRPOQ25gQT+BY+sp8Y503_9KxTa1j2aZSGYU-9BmBVA@mail.gmail.com> <CAFz-FYzzPFU3g+fM+QGbEDAJ-3DSU2qGHY9R+heZRbAWVAN2rw@mail.gmail.com> <CAGN7qDDu3PNxK9PTVr09sqUc0FrOnXgRaQDwLXQ13BhH_=85Bw@mail.gmail.com> <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> <alpine.DEB.2.00.1309120051240.12199@ps20323.dreamhostps.com> <CAFz-FYwi6tQ7WcODc3MBC=6pM_=G5ZONe=nVSHLs5EGTiUjE=w@mail.gmail.com> <CAGN7qDDhuCSSbBtF6gLTUy06sKoNXub3hD6EcUCvKr4ojkzhMA@mail.gmail.com> <CAGN7qDASLvnt8N=CfEKKpB9YYhAtnKkWP5q_KEkLVm9cCL=-2g@mail.gmail.com> <CAFz-FYwBdi9-t1r+2i6X_zaZAuUuLWJtyHngysB70aqhkAnOGQ@mail.gmail.com> <CAGN7qDCHL9g8TsBFpFNQfu3Pjgf-KTRQavzz=QBs_M4H86aL8g@mail.gmail.com> <CAFz-FYyEKYyJYvTMXDJ1f+zmZpxSMpG26xxX37Ne2tDd9tq5Yg@mail.gmail.com> <alpine.DEB.2.00.1309302310570.20189@ps20323.dreamhostps.com> <CAFz-FYxuYUg9ZLWkvORKOPsGjexRtFa9C2WsvN_b4Y-NQ_yE9A@mail.gmail.com> Message-ID: <CAGN7qDBewdTaAZXEDpmtwcwAPziuGQwrjg-UrmHeL4qPuhCoZg@mail.gmail.com> On Mon, Sep 30, 2013 at 4:51 PM, Dominic Mazzoni <dmazzoni at google.com>wrote: > On Mon, Sep 30, 2013 at 4:12 PM, Ian Hickson <ian at hixie.ch> wrote: > >> Some users have great trouble seeing the default focus rings. >> ... >> >> It's certainly true that if we don't want to support users with poor >> vision, the API would be simpler. But I don't think that's an option. We >> don't get to arbitrarily ignore some users. >> > > Of course not! I'm not arguing against supporting those users. The correct > thing to do for those users is to use accessibility APIs to make the > operating system aware of the focused object and its bounds. If users have > ZoomText or MAGic installed, or if they're using VoiceOver or Orca, their > assistive technology will draw its own focus ring *in addition* to the > application's focus ring. > > No other application hides its focus ring just because, e.g., ZoomText is > drawing a focus ring. The rest of the web doesn't do it. Why do we need it > for canvas? > Where does it say in the spec that if you have assistive technology enabled, focus rings should not be drawn? > > On Mon, 30 Sep 2013, Dominic Mazzoni wrote: >> > >> > I don't think that drawCustomFocusRing should switch to the system focus >> > rectangle style just because that preference was set - it might look >> > horrible on a particular canvas. >> >> It's the whole point of the feature. Draw the focus ring the way the user >> needs it to be drawn, if there's a special need, otherwise, let me draw it >> my fancy hard-to-see way. >> > > The problem is that there aren't existing operating system or browser > settings that specifies that the user wants better focus rings. There are > tools that draw additional focus rings, and preferences that control the > appearance of the default focus ring, but no toggle that says > *applications* should or shouldn't draw focus rings. > > Finally, as a meta-argument, if we really want a preference for custom > focus rings, then wouldn't we want that for the rest of the web? If I'm > building a custom form control and I need to choose a drawing style when > focused, wouldn't I want to know if the user wanted custom focus rings, > too? In other words, what makes this need canvas-specific? > > >> How would this differ from scrollPathIntoView() ? > > > It would take an element in fallback content as an argument. That would > allow assistive technology to be notified. > As Ian pointed out, the accessibility software could do that. Actually, I just tried this with my patched version of Firefox and your example: http://dmazzoni-google.github.io/canvas-focus-ring-demo/ If I tab into the hidden canvas elements, the browser automatically scrolls to the region. So, it seems that this is not needed. From dmazzoni at google.com Mon Sep 30 23:48:21 2013 From: dmazzoni at google.com (Dominic Mazzoni) Date: Mon, 30 Sep 2013 23:48:21 -0700 Subject: [whatwg] Outline style to use for drawSystemFocusRing In-Reply-To: <CAGN7qDBewdTaAZXEDpmtwcwAPziuGQwrjg-UrmHeL4qPuhCoZg@mail.gmail.com> References: <CAFz-FYxS-sLLOMA2=5bj-aJ1bmsBq8w_4Rminw_JLCMnYaMfPw@mail.gmail.com> <alpine.DEB.2.00.1307300020510.27623@ps20323.dreamhostps.com> <CAGN7qDAjRPOQ25gQT+BY+sp8Y503_9KxTa1j2aZSGYU-9BmBVA@mail.gmail.com> <CAFz-FYzzPFU3g+fM+QGbEDAJ-3DSU2qGHY9R+heZRbAWVAN2rw@mail.gmail.com> <CAGN7qDDu3PNxK9PTVr09sqUc0FrOnXgRaQDwLXQ13BhH_=85Bw@mail.gmail.com> <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> <alpine.DEB.2.00.1309120051240.12199@ps20323.dreamhostps.com> <CAFz-FYwi6tQ7WcODc3MBC=6pM_=G5ZONe=nVSHLs5EGTiUjE=w@mail.gmail.com> <CAGN7qDDhuCSSbBtF6gLTUy06sKoNXub3hD6EcUCvKr4ojkzhMA@mail.gmail.com> <CAGN7qDASLvnt8N=CfEKKpB9YYhAtnKkWP5q_KEkLVm9cCL=-2g@mail.gmail.com> <CAFz-FYwBdi9-t1r+2i6X_zaZAuUuLWJtyHngysB70aqhkAnOGQ@mail.gmail.com> <CAGN7qDCHL9g8TsBFpFNQfu3Pjgf-KTRQavzz=QBs_M4H86aL8g@mail.gmail.com> <CAFz-FYyEKYyJYvTMXDJ1f+zmZpxSMpG26xxX37Ne2tDd9tq5Yg@mail.gmail.com> <alpine.DEB.2.00.1309302310570.20189@ps20323.dreamhostps.com> <CAFz-FYxuYUg9ZLWkvORKOPsGjexRtFa9C2WsvN_b4Y-NQ_yE9A@mail.gmail.com> <CAGN7qDBewdTaAZXEDpmtwcwAPziuGQwrjg-UrmHeL4qPuhCoZg@mail.gmail.com> Message-ID: <CAFz-FYz57tqWj=mf0dE=1jHi09SXbPKhnHwyC76-XWdPpv6F_g@mail.gmail.com> On Mon, Sep 30, 2013 at 5:42 PM, Rik Cabanier <cabanier at gmail.com> wrote: > Where does it say in the spec that if you have assistive technology > enabled, focus rings should not be drawn? > if as a web author I call drawCustomFocusRing and it returns false, I'm not supposed to draw anything according to the spec. That's what doesn't make sense to me. It would take an element in fallback content as an argument. That would >> allow assistive technology to be notified. >> > > As Ian pointed out, the accessibility software could do that. > scrollPathIntoView can't be used to notify accessibility software of the focused object location as-is because it doesn't have an element to fire on, and it doesn't know if the scrolling is because of focus or not. If we added a canvas fallback element as a parameter to scrollPathIntoView, I don't think we'd need drawCustomFocusRing. From mnot at mnot.net Sun Sep 1 18:08:48 2013 From: mnot at mnot.net (Mark Nottingham) Date: Mon, 2 Sep 2013 11:08:48 +1000 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: <CADnb78hfULHEj3zmMGJe0iXj7O06tA9e8TwnkQ_TCm6Z-QK8iA@mail.gmail.com> References: <CADnb78jksF5RdfPK4Brcib=N-jYcf0YrO=o=fFz4ZLUqTgLUMg@mail.gmail.com> <414B89D4-9758-4E38-80C8-7C3630EA4971@mnot.net> <CADnb78hfULHEj3zmMGJe0iXj7O06tA9e8TwnkQ_TCm6Z-QK8iA@mail.gmail.com> Message-ID: <E459152A-A195-4EF1-8FEC-0A03140B93AE@mnot.net> On 29/08/2013, at 9:13 PM, Anne van Kesteren <annevk at annevk.nl> wrote: > * Resources that can contain subresources (HTML, CSS, JavaScript, > workers, ...) would need to have an outer and inner location. If you > have e.g. <a href="#test"> updating the address bar to > #path=test.html&id=test is somewhat magic. For <a href="other.html"> > it'd be pretty magic too. *sigh* good point. > * For origin comparison you'd have to look at the outer location. I kinda wonder if it should; if ZIP is really being used as a packaging format, the idea is to make it portable, right? So a ZIP should run just as well from the local filesystem (file://) as it should from the original Web site, or one it's copied to, or if it's just relocated to a different place. CORS should be set up properly, assumptions shouldn't be made about its context, etc. Just my .02, YMMV. Cheers, -- Mark Nottingham http://www.mnot.net/ From contact at nickshanks.com Mon Sep 2 06:04:34 2013 From: contact at nickshanks.com (Nicholas Shanks) Date: Mon, 2 Sep 2013 14:04:34 +0100 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: <CADnb78jksF5RdfPK4Brcib=N-jYcf0YrO=o=fFz4ZLUqTgLUMg@mail.gmail.com> References: <CADnb78jksF5RdfPK4Brcib=N-jYcf0YrO=o=fFz4ZLUqTgLUMg@mail.gmail.com> Message-ID: <CA+hEJVXSOEPti9oERoaVb83OWcrmckZFASvn8pzYmaZMXV2uqQ@mail.gmail.com> On 28 August 2013 14:32, Anne van Kesteren <annevk at annevk.nl> wrote: > We have thought of three approaches for zip URL design thus far: > > * Using a sub-scheme (zip) with a zip-path (after !): > zip:http://www.example.org/zip!image.gif > * Introducing a zip-path (after %!): http://www.example.org/zip%!image.gif > * Using media fragments: http://www.example.org/zip#path=image.gif Am I missing something? I assume you want to basically send a whole bunch of files down the pipe when any one of them is requested, not send the individual file's bytestream from a zip. If so, then why is this not acceptable: === <a href="http://website.example/game.webzip/load.html">Load Game</a> GET http://website.example/game.webzip/load.html Accept: application/webzip, */*;q=0.1 # UA supports looking inside zips 200 OK Content-Type: application/webzip Content-Location: /game.webzip # server knows to send zip -- vs. -- <a href="http://website.example/game.webzip/load.html">Load Game</a> GET http://website.example/game.webzip/load.html Accept: text/html, */*;q=0.1 # no support 200 OK Content-Type: text/html Content-Location: /game.webzip_files/load.html # server knows file resides elsewhere === HTTP server knows to send a zip file if UA supports a new content type. HTTP server also knows to send back the file from inside the zip (or an unzipped sibling directory to contain the file to serve) to clients that do not support the new mime type. This can be as simple as a mod_rewrite rule executed iff mod_webzip is not loaded. MIME type would only be requested in Accept header by supporting client if the path contained /\.webzip\// otherwise omitted. All relative URIs work as if the file was at the request URI. No multiple scheme hassles, no multiple fragment hassles. No special delimiters that might already be in use. The change in filename also means a concious action on part of the webmaster to allow access. As suggested, the file format can be a stricter form of zip that doesn't allow multiple file tables. The server would have to validate this before sending the file As suggested, the content types of resources in the zip would be determined from a list of file extensions defined by the spec. Anything else get's a default such as application/unknown. -- Nicholas. From jaffathecake at gmail.com Tue Sep 3 03:45:47 2013 From: jaffathecake at gmail.com (Jake Archibald) Date: Tue, 3 Sep 2013 11:45:47 +0100 Subject: [whatwg] Script preloading In-Reply-To: <179BF344-B282-4445-AB2B-5D467D32258D@apple.com> References: <Pine.LNX.4.64.1307091607110.24681@ps20323.dreamhostps.com> <CA+c2ei-ywCwWHNC6SfWA8CxB4XTbh=hMA3j8K0=tspwtQB3SiA@mail.gmail.com> <DDDE638B-B515-43DE-A0EB-AB20CC73FE1D@gmail.com> <CA+c2ei8pT5s+2z-xPqz5x8sn2gGZD=uGB7FH9JcddE5xOpvVag@mail.gmail.com> <E742ACB2-B2AC-4D77-B7AA-43B3625FBBE9@gmail.com> <CA+c2ei-+xCmm6gW45-s72XUjond5VF4TkwTdcY5jZ6dkZUsUuA@mail.gmail.com> <alpine.DEB.2.00.1308212259080.27209@ps20323.dreamhostps.com> <CACj=BEitGcV2WaYzzxWgnO-=YMfJkR4PsKfkQwrDNjRbYEHb0g@mail.gmail.com> <179BF344-B282-4445-AB2B-5D467D32258D@apple.com> Message-ID: <CAJ5xic_99kMCN9nC2da09YLQQsfzxmrbZ06aqawac16N145NsA@mail.gmail.com> On 31 August 2013 00:04, Ryosuke Niwa <rniwa at apple.com> wrote: > It'll be much harder to implement a new dependency API that replies on CSS > selectors if we care about the performance at all. > Where does the performance issue come from? It would only need to be resolved once on node creation or insertion into the document (the latter of the two). It's only used for execution, downloads can still be triggered without resolving the selectors (eg, by a pre-scanner). From annevk at annevk.nl Tue Sep 3 05:49:15 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Tue, 3 Sep 2013 13:49:15 +0100 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: <CA+hEJVXSOEPti9oERoaVb83OWcrmckZFASvn8pzYmaZMXV2uqQ@mail.gmail.com> References: <CADnb78jksF5RdfPK4Brcib=N-jYcf0YrO=o=fFz4ZLUqTgLUMg@mail.gmail.com> <CA+hEJVXSOEPti9oERoaVb83OWcrmckZFASvn8pzYmaZMXV2uqQ@mail.gmail.com> Message-ID: <CADnb78hmtBeW03MkmpFogcZNGgGXYSLkHoP16fU43ZCd=OJFkA@mail.gmail.com> On Mon, Sep 2, 2013 at 2:04 PM, Nicholas Shanks <contact at nickshanks.com> wrote: > Am I missing something? I assume you want to basically send a whole > bunch of files down the pipe when any one of them is requested, not > send the individual file's bytestream from a zip. If so, then why is > this not acceptable: > > === > <a href="http://website.example/game.webzip/load.html">Load Game</a> > > GET http://website.example/game.webzip/load.html > Accept: application/webzip, */*;q=0.1 # UA supports looking inside zips > > 200 OK > Content-Type: application/webzip > Content-Location: /game.webzip # server knows to send zip > > -- vs. -- > > <a href="http://website.example/game.webzip/load.html">Load Game</a> > > GET http://website.example/game.webzip/load.html > Accept: text/html, */*;q=0.1 # no support > > 200 OK > Content-Type: text/html > Content-Location: /game.webzip_files/load.html # server knows file > resides elsewhere > === This is a pretty interesting suggestion, but I think the setup is too complicated. Even setting a simple header such as Access-Control-Allow-Origin: * is a problem. -- http://annevankesteren.nl/ From rniwa at apple.com Tue Sep 3 11:27:44 2013 From: rniwa at apple.com (Ryosuke Niwa) Date: Tue, 03 Sep 2013 11:27:44 -0700 Subject: [whatwg] Script preloading In-Reply-To: <CAJ5xic_99kMCN9nC2da09YLQQsfzxmrbZ06aqawac16N145NsA@mail.gmail.com> References: <Pine.LNX.4.64.1307091607110.24681@ps20323.dreamhostps.com> <CA+c2ei-ywCwWHNC6SfWA8CxB4XTbh=hMA3j8K0=tspwtQB3SiA@mail.gmail.com> <DDDE638B-B515-43DE-A0EB-AB20CC73FE1D@gmail.com> <CA+c2ei8pT5s+2z-xPqz5x8sn2gGZD=uGB7FH9JcddE5xOpvVag@mail.gmail.com> <E742ACB2-B2AC-4D77-B7AA-43B3625FBBE9@gmail.com> <CA+c2ei-+xCmm6gW45-s72XUjond5VF4TkwTdcY5jZ6dkZUsUuA@mail.gmail.com> <alpine.DEB.2.00.1308212259080.27209@ps20323.dreamhostps.com> <CACj=BEitGcV2WaYzzxWgnO-=YMfJkR4PsKfkQwrDNjRbYEHb0g@mail.gmail.com> <179BF344-B282-4445-AB2B-5D467D32258D@apple.com> <CAJ5xic_99kMCN9nC2da09YLQQsfzxmrbZ06aqawac16N145NsA@mail.gmail.com> Message-ID: <C7FE4CCA-19EA-4544-B14B-19295C4DB9ED@apple.com> On Sep 3, 2013, at 3:45 AM, Jake Archibald <jaffathecake at gmail.com> wrote: > On 31 August 2013 00:04, Ryosuke Niwa <rniwa at apple.com> wrote: > >> It'll be much harder to implement a new dependency API that replies on CSS >> selectors if we care about the performance at all. >> > > Where does the performance issue come from? It would only need to be > resolved once on node creation or insertion into the document (the latter > of the two). It's only used for execution, downloads can still be triggered > without resolving the selectors (eg, by a pre-scanner). >From the fact selector matching is slow. I'm opposed to adding selector dependency unless there is a very important use case that can't be addressed by referring to a script by an element id or a script filename. - R. Niwa From bzbarsky at MIT.EDU Tue Sep 3 12:42:54 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Tue, 03 Sep 2013 15:42:54 -0400 Subject: [whatwg] Script preloading In-Reply-To: <C7FE4CCA-19EA-4544-B14B-19295C4DB9ED@apple.com> References: <Pine.LNX.4.64.1307091607110.24681@ps20323.dreamhostps.com> <CA+c2ei-ywCwWHNC6SfWA8CxB4XTbh=hMA3j8K0=tspwtQB3SiA@mail.gmail.com> <DDDE638B-B515-43DE-A0EB-AB20CC73FE1D@gmail.com> <CA+c2ei8pT5s+2z-xPqz5x8sn2gGZD=uGB7FH9JcddE5xOpvVag@mail.gmail.com> <E742ACB2-B2AC-4D77-B7AA-43B3625FBBE9@gmail.com> <CA+c2ei-+xCmm6gW45-s72XUjond5VF4TkwTdcY5jZ6dkZUsUuA@mail.gmail.com> <alpine.DEB.2.00.1308212259080.27209@ps20323.dreamhostps.com> <CACj=BEitGcV2WaYzzxWgnO-=YMfJkR4PsKfkQwrDNjRbYEHb0g@mail.gmail.com> <179BF344-B282-4445-AB2B-5D467D32258D@apple.com> <CAJ5xic_99kMCN9nC2da09YLQQsfzxmrbZ06aqawac16N145NsA@mail.gmail.com> <C7FE4CCA-19EA-4544-B14B-19295C4DB9ED@apple.com> Message-ID: <52263BBE.60506@mit.edu> On 9/3/13 2:27 PM, Ryosuke Niwa wrote: > From the fact selector matching is slow. Hold on. Back up. Selector matching can't be all that "slow" per se: browsers do it a _lot_. Do you mean doing the equivalent of document.querySelectorAll can be slow? -Boris From ian at hixie.ch Tue Sep 3 13:44:40 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 3 Sep 2013 20:44:40 +0000 (UTC) Subject: [whatwg] Global script clean-up jobs and "spin the event loop" In-Reply-To: <CABirCh_je2oVbYbbniZB+AMR2wphihxuhCMhH00tXWuQ=p3nTA@mail.gmail.com> References: <CABirCh_je2oVbYbbniZB+AMR2wphihxuhCMhH00tXWuQ=p3nTA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309032043540.7443@ps20323.dreamhostps.com> On Tue, 28 May 2013, Glenn Maynard wrote: > > "Jump to a code entry-point" essentially maintains a stack of entry > scripts, to determine the "outermost" script in order to know whether to > run the global clean-up jobs. This assumes that this algorithm will > always be entered and exited as a stack: an invocation of the algorithm > must always complete after any later invocations. > > Does this hold even in the face of multiple nested invocations of "spin > the event loop" algorithm? That algorithm doesn't seem to try to > guarantee any kind of stack-like behavior. I've fixed this, but I haven't tested to see what browsers actually do in this case. (This can only happen, as far as I can tell, in nested showModalDialog() loops that happen to resume out-of-order. I suspect in reality browsers won't let you do this, which would make this moot?) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 3 13:51:56 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 3 Sep 2013 20:51:56 +0000 (UTC) Subject: [whatwg] registerProtocolHandler - allow site to specify more info and do custom handling In-Reply-To: <BAY178-W6C1D8D1234C015E08F081BA910@phx.gbl> References: <BAY178-W956D2B97A1D4BEA24641FBA910@phx.gbl> <BAY178-W6C1D8D1234C015E08F081BA910@phx.gbl> Message-ID: <alpine.DEB.2.00.1309032047210.7443@ps20323.dreamhostps.com> On Thu, 30 May 2013, chris cargile wrote: > > there seems to be a limitation that either registerProtocolHanlder() > takes GET requests but not POST requests Since you are only ever sent a URL, this seems like the appropriate kind of request, no? On Thu, 30 May 2013, chris cargile wrote: > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=22022. I don't really understand the problem here. Can you elaborate? What problem are you trying to resolve? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 3 13:57:39 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 3 Sep 2013 20:57:39 +0000 (UTC) Subject: [whatwg] inputmode feedback In-Reply-To: <CA+c2ei_fzXqAs1=mCpiwn+A0+yEvRjf5d9iLFFbVzFQgBaEQiw@mail.gmail.com> References: <511BE988.7070208@lamouri.fr> <5130C9A1.2020200@lamouri.fr> <Pine.LNX.4.64.1306062055150.2772@ps20323.dreamhostps.com> <CA+c2ei_fzXqAs1=mCpiwn+A0+yEvRjf5d9iLFFbVzFQgBaEQiw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309032052370.7443@ps20323.dreamhostps.com> On Thu, 6 Jun 2013, Jonas Sicking wrote: > On Thu, Jun 6, 2013 at 2:08 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Fri, 15 Feb 2013, Jonas Sicking wrote: > >> > >> Using semantic names might give us the warm fuzzies, but is there > >> really any semantic use we will get out of these that we wouldn't by > >> using "lowercase", "titlecase" or "autocapitalized"? > > > > The reason I used the more "semantic" names is that the names like > > "lowercase", "titlecase" or "autocapitalized" aren't accurate. For > > example, you can hit shift in "lowercase" mode to get uppercase. You > > can have a "titlecase" mode that doesn't capitalise every word (e.g. > > it recognises the "van" in "van Kesteren"). A value that is explicitly > > for names can use a different dictionary than one that is just for > > capitalised text (e.g. derived from the user's contact list). And so > > on. > > > >> I take it verbatim and name would disable any spelling corrections, > >> and name would also titlecase? But the difference between text and > >> prose seems really hard to understand. > > > > In the spec, "verbatim" does not correction at all, e.g. passwords; > > "latin" is for human-to-computer communications, e.g. free-form text > > search fields, and would do spelling correction and automatically > > inserting spaces between words in swiping keyboards, etc; and > > "latin-prose" is intended for human-to-human communications, with > > aggressive automatic typing correction, e.g. text prediction and > > automatic capitalisation at the start of sentences. > > I think a really important question is if this is understandable to > authors. There's also a big risk that if these modes aren't noticeably > different in initial implementations, it will be hard to add such > differences later. I agree that those are concerns. I don't know how to resolve them. I'm certainly open to clearer names. I don't think "titlecase" is a better name, as it either implies that we only capitalise every first letter and forego much of the potential helpfulness that "latin-name" can provide. I don't think "autocapitalized" should imply "autocorrect" in the way that "latin-prose" should. "latin-prose" vs "latin-name" seem straight-forward enough; I agree that "latin" is confusing in that context, though once you explain that "latin" is the basis of "latin-prose" and "latin-name", I think it becomes clear. Other suggestions welcome. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 3 14:09:30 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 3 Sep 2013 21:09:30 +0000 (UTC) Subject: [whatwg] @generator-unable-to-provide-required-alt, figure with figcaption In-Reply-To: <0525D1DC-57F5-4F4C-838E-D7D280E9D984@prlbr.com> References: <CA+ri+VmGmZh2goTez1YpOce9C=WpoEdwH3ToV+X0owpnUeOVYQ@mail.gmail.com> <6D789473-22C6-48B1-BD55-1D375834178A@prlbr.com> <Pine.LNX.4.64.1306172040500.11139@ps20323.dreamhostps.com> <026D354F-5220-4F2B-823F-125249027E52@prlbr.com> <Pine.LNX.4.64.1306191743130.11139@ps20323.dreamhostps.com> <0525D1DC-57F5-4F4C-838E-D7D280E9D984@prlbr.com> Message-ID: <alpine.DEB.2.00.1309032059410.7443@ps20323.dreamhostps.com> On Sat, 8 Jun 2013, Jukka K. Korpela wrote: > 2013-06-08 0:13, Ian Hickson wrote: > > On Sun, 2 Jun 2013, Jukka K. Korpela wrote: > > > > > > The purpose presented is "to avoid markup generators from being > > > pressured into replacing the error of omitting the alt attribute > > > with the even more egregious error of providing phony alternative > > > text". This is rather speculative, and it seems to lead to various > > > attempts that are more or less self-contradictory. > > > > It's not that speculative, your e-mail is a response to a markup > > generator implementor who feels pressured in exactly this way! > > And who wrote that generator-unable-to-provide-required-alt is... > inadequate. Just because the solution is inadequate doesn't mean the problem isn't real. You were saying the problem wasn't real; I was pointing to a counterproof. I would be the first to agree that the spec isn't perfect. > > > Authors of generators always have the option of generating things like > > > alt="(an image)", which can hardly be worse than lack of alt attribute. > > > > It's worse because it prevents authors from being able to find images that > > are lacking good alternative text, and because it makes it less likely > > that future user agents will try to automatically figure out what the > > alternative text should be (since one is already provided). > > To a user, even ?(an image)? is better than lack of alt attribute I disagree. The lack of an alt attribute can be used by user agents to substitute the string "(an image)", in which case it is the same, or it can be used to do far more, e.g. image recognition, OCR, etc. This isn't academic, these technologies exist today. > which is what generator-unable-to-provide-required-alt really means To the non-validator user agent, that attribute means nothing. It's a non-conforming attribute with no semantics to any software outside content generators and conformance checkers. > To analyze which images lack good alternative texts, you need to look at > the images in their context. It?s just wrong to assume that they can be > identified using some simple automated analysis. If you don't write bad alternative text (like "(an image)"), but sometimes write no alternative text at all, then detecting images without good alternative text is the same as detecting images with no alternative text. Certainly, detecting images with present but bad alternative text is a much harder problem -- that's why we should discourage the use of bad alternative text such as "(an image)". > And future user agents won?t try to figure out what the alternative text > should be, any more than current browsers do such things. It is just > wishful thinking to expect such processing, and if browsers tried to do > such things, they would just mess things up. We are far closert to this than I think you realise. Try doing image searches in G+, for exmaple (assuming you have a lot of photographs in your G+ stream). Even with virtually no context, no captions, no incoming links from other pages, and so forth, G+ image search can return accurate results for searches like "house", "tree", "cat", and so forth. It's not at all a stretch to imagine the next stage of this technology is the ability to describe an image. It won't happen tomorrow, maybe not even next year, but HTML is likely to be with us for decades more. On Tue, 18 Jun 2013, Steve Faulkner wrote: > > > > >> > > > > >> <img src="..." title="image"> > > > > > > > > > > If you have a caption from the user (as opposed to replacement > > > > > text), then this is a perfectly valid option. It's as valid as > > > > > the <figure> case, and means the same thing. > > > > > > the above statement is bad advice: > > > > > > browsers map title to the accessible name in accessibility APIs when > > > alt is absent, so-- > > > > ...so the browsers are buggy. This is not unusual. File bugs. :-) > > Indeed, since you've demonstrated yourself able to write code, you > > could just go and fix the bugs directly. :-) > > This behavior doesn't appear to be due to a bug, its by design, the > title attribute is used as an accessible name of last resort for all > elements and its implemented pretty much in the same (interoperable) way > in all browsers. That doesn't mean it's not a bug. > > Writing specs for the lowest-common-denominator is not the way we'll > > get a usable, accessible Web. We might sometimes be forced to when > > there are compat requirements with massively deployed content that Web > > author are relying on that prevent certain behaviours from being > > fixed, but this really doesn't apply in the case of ATs, since the > > vast majority of authors have never tested how their pages work in > > ATs. > > I don't understand what you are saying here, can you elaborate? Which part is unclear? On Thu, 20 Jun 2013, Martin Janecke wrote: > >> > >> Unfortunately -- although its verbosity is there to prevent any > >> misunderstanding for its use -- it might leave the impression that a > >> generator writing > >> > >> <img src="..." generator-unable-to-provide-required-alt=""> > >> > >> is not as good as a generator writing > >> > >> <img src="..." alt="an image"> > > > > Indeed. I don't know of a way to fix that. It's always going to be the > > case that a generator doing the wrong thing in a way that is > > machine-readably indistinguishable from the right thing is more likely > > to look correct at a quick glance than a generator that is doing the > > wrong thing in a machine-detectable way. I don't know what we can do > > about that. > > > > I'm open to suggestions. > > I see. Unfortunately I do not have a better idea. If anyone does come up with one, please speak up! -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 3 14:38:35 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 3 Sep 2013 21:38:35 +0000 (UTC) Subject: [whatwg] Reconsidering how we deal with text track cues In-Reply-To: <CAHp8n2nBcRZV5mW3+wA2f=pBifF1rCd-T5+_BQLQ9mv4rhGkxQ@mail.gmail.com> References: <CAHp8n2mbuxm=2aOSMS2S_oa042gMkSCOMTrn5odA9+Tbpo902w@mail.gmail.com> <Pine.LNX.4.64.1306121700000.17279@ps20323.dreamhostps.com> <CAHp8n2m1AcFS3WmwwniYyz=yZZucKrhzPoTu=eCOPd57jav+Og@mail.gmail.com> <51BFCCA6.4080208@brendanlong.com> <CAHp8n2nBcRZV5mW3+wA2f=pBifF1rCd-T5+_BQLQ9mv4rhGkxQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309032112000.7443@ps20323.dreamhostps.com> On Wed, 12 Jun 2013, Brendan Long wrote: > On 06/11/2013 11:11 PM, Silvia Pfeiffer wrote: > > > > I suggest we rename WebVTTCue [1] to VTTCaptionCue and allow such cues > > only on tracks of kind={caption, subtitle}. > > Why VTTCaptionCue and not just HTMLCue? It seems like any cue that can > be rendered needs to be able to provide its content as HTML, and once we > have that, the browser shouldn't care where we got that HTML from. This premise seems quite wrong. Can you elaborate on why you think that? > Do we expect browsers to have special rendering rules for every caption > format? Each caption format _does_ have special rendering rules. > It seems like the most likely result would be that the browser vendors > just don't bother implementing anything besides WebVTT. That seems like a likely scenario, which seems fine. On Mon, 17 Jun 2013, Silvia Pfeiffer wrote: > On Thu, Jun 13, 2013 at 3:08 AM, Ian Hickson <ian at hixie.ch> wrote: > > On Wed, 12 Jun 2013, Silvia Pfeiffer wrote: > >> > >> As we continue to evolve the functionality of text tracks, we will > >> introduce more complex other structured content into cues and we will > >> want browsers to parse and interpret them. > > > > I think it's a mistake to try to solve problems before they exist. We > > don't know exactly what we'll be adding in the future, so we don't > > know what we'll need yet. > > I'm preparing to start specifying how to render chapters. There's > already been mention of need for a thumbnail image in chapters. > > I'll also have to specify how to "render" descriptions. Since the target > audience are blind and vision-impaired users, there will be a rendering > algorithm that includes speech synthesis. > > This is a problem I have to deal with now. I don't think the problems you describe here require any changes to the API or to the format, but maybe I'm missing something. (Images for chapters would, I guess, if you're not using the images from the video file, but why wouldn't you use those actual images?) > >> For example, I expect that once we have support for speech synthesis > >> in browsers [1], cues of kind descriptions will be voiced by speech > >> synthesis, and eventually we want to influence that speech synthesis > >> with markup (possibly a subpart of SSML [2] or some other simpler > >> markup that influences prosody). > > > > I think it's highly unlikely that we'll actually ever want that, but > > if we ever do, then we should fix the problem then. > > Rendering description cues with speech synthesis is 100% something that > is coming. Richer markup of description cues is then just the logical > next step - it won't be required now, but is certainly on the roadmap. > How likely it will be to be SSML is unclear - I'd much prefer a simpler > markup for WebVTT, too. I'm not even remotely convinced that speech synthesis in description cues needs any markup, let alone markup more elaborate than VTT already has. > >> All of these new cue settings would end up as new attributes on the > >> WebVTTCue object. This is a dangerous design path that we have taken. > > > > This is wrong on two points. One, there's nothing forcing a text track > > format to only generate one kind of object -- just like HTML generates > > different objects for different elements, WebVTT could generate > > different objects for different cues. > > Indeed, that's what I believe will be necessary. > > > Two, it's not dangerous to have an object with lots of fields. > > Why then do we then distinguish between a HTMLMediaElement, a > HTMLVideoElement and a HTMLAudioElement? What reasons make us create new > objects? It's just a matter of convenience. <video> and <audio> elements have different results, so they expose different APIs. They share almost the entirety of their API via their abstract superclass, HTMLMediaElement. > >> What we have done with WebVTT is actually two-fold: > >> 1. we have created a file format that serializes arbitrary content > >> that is time-synchronized with a media element. > >> 2. and we have created a simple caption/subtitle cue format. > >> > >> That both are called "WebVTT" is the cause of a lot of confusion and not > >> a good design approach. > > > > I think it's a mistake to view these as distinct. It's just one format. > > But as you're that spec's editor, that's your choice. :-) > > We've actually done more - we also have a chapter and a metadata cue format: > http://dev.w3.org/html5/webvtt/#dfn-webvtt-cue > > "WebVTT chapter title text is syntactically a subset of WebVTT cue > text, and WebVTT cue text is syntactically a subset of WebVTT metadata > text. Conformance checkers, when validating WebVTT files, may offer to > restrict all cues to only having WebVTT chapter title text or WebVTT > cue text as their cue payload; WebVTT metadata text cues are only > useful for scripted applications (using the metadata text track > kind)." > > They are already hierarchically defined upon each other (already when > you were the editor). > > They just aren't represented in objects in this way. I don't think the way you're viewing it is the right way to view it. IMHO there's just one format, it just can be used in various ways, just like HTML can be used for applications and documents and games, etc. Just like how HTML sometimes requires a <title> and sometimes does not, based on context, there are different contextual constraints on authoring VTT. But it's still just one format. > Thus, I suggest that a cue coming from a WebVTT file on a kind=chapter > track will be interpreted as a ChapterCue, on a kind=captions track as a > VTTCaptionsCue, and on a kind=metadata track as a MetadataCue. IMHO this doesn't make any sense. You don't create different objects for different elements in HTML based on whether the document was opened in an <iframe> or a top-level browsing context or whatever. The API doesn't, shouldn't, change based on context. It looks like I already said that, though: > > It would be like having a different DOM for an HTML file in an > > <iframe> and in a top-level browsing context. > > Contrast that to applying a different parsing and rendering algorithm > of the <iframe> depending on the parent element that it is put into, > which is what we are currently doing with WebVTTCue. No, we're parsing VTT the same in all cases. It's the conformance rules that change, and the rendering rules. Just like with HTML, where the rendering can changed e.g. based on the CSS of the page, or where the element is (e.g. an <h1> in a <body> vs one in three nested <section>s). > An alternative would be to create explicit <captiontrack>, > <descriptiontrack> etc elements, which was something that was under > discussion initially. IMHO the current state is fine as it is. > > You don't necessarily know, when parsing the WebVTT file or HTML file, > > what it's going to be used for. In the case of WebVTT, it could even > > change from one to another. > > I'd disallow changing the kind on a track. Content attributes can't be made read-only. Also, that seems artificial. Why would we do that? > >> Also, we separate out the WebVTT serialisation format syntax > >> specification from the cue syntax specification [2] and introduce > >> separate parsers [3] for the different cue syntax formats. The > >> rendering section [4] has already started distinguishing between cue > >> rendering for chapters and for captions/subtitles. This will easily > >> fit with the now separated cue syntax formats. > > > > This sounds like a lot of complication for no particularly good > > reason, but again, you're the editor. :-) > > This is work that has to be done even if we decide to only have a single > object represent all cues of a WebVTT file. No, you don't need separate parsers. There's just one parser, and the rendering rules are contextual, not based on anything about the cues. > The point of this email is to introduce a hierarchy of objects that > represent cues (or at least an agreement on when such new objects should > be created). We have a hiearchy. TextTrackCue is an abstract object that is defined in the HTML spec. VTTCue is the object used by VTT cues. I don't see any need for any others in HTML or VTT. > >> Doing this will make WebVTT and the TextTrack API extensible for new > >> cue formats, such as cues in SSML format, or ThumbnailCues, or > >> MidrollAdCues or whatnot else we may see necessary in the future. > > > > It's already plenty extensible enough. > > Right, you brought in the extensibility a few weeks ago by introducing > TextTrackCue as an abstract object and pushing all its extended > attributes into WebVTTCue, which is great. I'm just trying to come up > with the best scheme to make use of this extensibility, and I think > creating new objects makes more sense to be based on cue content than on > text track file mime type. I would recommend against using the extensibility. :-) On Mon, 17 Jun 2013, Brendan Long wrote: > > I don't think it's necessary to use the same language for authoring as > display though. Since we already have rules for rendering HTML, and > WebVTT seems to be a subset of HTML (with some special CSS rules, and > some shorthand tags), I think the easiest way to handle it would be to > translate WebVTT cues into HTML+CSS, then rely on the existing rendering > engine. VTT's rendering rules differ from basic CSS in some pretty important ways. In the ways that it is similar, it already reuses CSS infrastructure. There's not really any relationship with HTML, though. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From rniwa at apple.com Tue Sep 3 14:49:29 2013 From: rniwa at apple.com (Ryosuke Niwa) Date: Tue, 03 Sep 2013 14:49:29 -0700 Subject: [whatwg] Script preloading In-Reply-To: <alpine.DEB.2.00.1308212259080.27209@ps20323.dreamhostps.com> References: <Pine.LNX.4.64.1307091607110.24681@ps20323.dreamhostps.com> <CA+c2ei-ywCwWHNC6SfWA8CxB4XTbh=hMA3j8K0=tspwtQB3SiA@mail.gmail.com> <DDDE638B-B515-43DE-A0EB-AB20CC73FE1D@gmail.com> <CA+c2ei8pT5s+2z-xPqz5x8sn2gGZD=uGB7FH9JcddE5xOpvVag@mail.gmail.com> <E742ACB2-B2AC-4D77-B7AA-43B3625FBBE9@gmail.com> <CA+c2ei-+xCmm6gW45-s72XUjond5VF4TkwTdcY5jZ6dkZUsUuA@mail.gmail.com> <alpine.DEB.2.00.1308212259080.27209@ps20323.dreamhostps.com> Message-ID: <AD835154-3364-4FDC-B983-4167CA6271CA@apple.com> Original proposal: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-August/040664.html http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-August/040666.html In order to address use cases incDependencies and decDependencies satisfied, I'm going to add the following proposals: I make one more change that in order for a dependency specified in "needs" to be satisfied, "src" content attribute of the dependent script needs to match the value when the script finished running. e.g. myscript.src = null leaves any dependency on myscript unsatisfied. Also make "needs" IDL property take in any HTML element; e.g. adding an image element to "needs" makes the script wait until the corresponding image resource is loaded. On Aug 27, 2013, at 2:55 PM, Ian Hickson <ian at hixie.ch> wrote: > > First, let's get down to use cases. Kyle did a great job of describing > some key use cases: > > On Wed, 10 Jul 2013, Kyle Simpson wrote: >> >> [Use-case Q:] I am dynamically loading one of those social widgets that, >> upon load, automatically scans a page and renders social buttons. I need >> to be able to preload that script so it's ready to execute, but decide >> when I want it to run against the page. I don't want to wait for true >> on-demand loading, like when my user clicks a button, because of the >> loading delay that will be visible to the user, so I want to pre-load >> that script and have it waiting, ready at a moment's notice to say "it's >> ok to execute, do it now! now! now!". <script id="social" src="social-button.js" prefetch></script> <button onmouseover="document.scripts.social.execute()"> ... </button> >> [Use-case S:] One CMS plugin wants to load "A.js" and "B.js", where B >> relies on A. Both need to load in parallel (for performance), but A must >> execute before B executes. I don't control A and B, so changing them is >> not an option. This CMS plugin [wants] to wait for some >> user-interaction, such as a button click, before executing the code. We >> don't want there to be any big network-loading delay visible to the user >> between their click of the button and the running of that plugin's code. // CMS plugin 1 var A = E('script', { src: 'A.js', prefetch: true }); var B = E('script', { src: 'B.js', needs: 'A.js', prefetch: true }); document.body.append(A, B); function sawUserInteraction() { B.execute(); }; >> Another CMS plugin on this same page wants to load "A.js", "C.js", and >> "D.js". This plugin doesn't know or care that the other plugin also >> requests "A.js". It doesn't know if there is a script element in the >> page requesting it or not, and it doesn't want to looking for it. It >> just wants to ask for A as a pre-requisite to C and D. But C and D have >> no dependency on each other, only a shared dependency on A. C and D >> should be free to run ASAP (in whichever order), assuming that A has >> already run [once] some user-interaction that initiates the load of A, >> C, and D. This user interaction may be before the other plugin requested >> A, or after it requested A. // CMS plugin 2 var A = E('script', { src: 'A.js', prefetch: true }); var C = E('script', { src: 'C.js', needs: 'A.js', prefetch: true }); var D = E('script', { src: 'D.js', needs: 'A.js', prefetch: true }); document.body.append(A, C, D); function sawUserInteraction() { C.execute(); D.execute(); }; >> "A.js" can be requested relatively (via a <base> tag or just relative to >> document root) or absolutely, or it might be requested with the >> leading-// protocol-relative from, taking on whatever http or https >> protocol the page has, whereas other references to it may specify the >> prototcol. >> >> These plugins can't guarantee what ID's or classes they use are reliably >> unique without undue processing burden. > > [I've trimmed the text Kyle wrote here, but also implicit in his > description, as I understood it, was that A.js should only run once even > if both plugins tried to load it.] > >> [Use-case T:] I have two different calendar widgets. I want to pop one >> of them up when a user clicks a button. The user may never click the >> button, in which case I don't want the calendar widget to have ever >> executed to render. [...] <script id=calA src="a.js" prefetch></script> <script id=calB src="b.js" prefetch></script> <script> function showCalendar(which) { if (which == 'a') document.scripts.calA.execute(); else document.scripts.calB.execute(); } </script> Neither Ian's nor my proposal fallbacks gracefully here :( >> [Use-case U:] I have a set of script "A.js", "B.js", and "C.js". B >> relies on A, and C relies on B. So they need to execute strictly in that >> order. [Now], imagine they progressively render different parts of a >> widget. [...] I only want to execute A, B and C once all 3 are preloaded >> and ready to go. It's [...] about minimizing delays between them, for >> performance PERCEPTION. >> >> [For example, one of them might start playing a video, and another might >> introduce the <canvas> slides for that video. You want all of the >> relevant scripts to be run at once, so there's no point where the page >> has a <video> element but doesn't have the <canvas>.] <script src="A.js" prefetch></script> <script src="B.js" prefetch needs="A.js"></script> <script id=c src="C.js" prefetch needs="B.js"></script> <script> // when we need it... document.scripts.c.execute(); </script> > On Thu, 11 Jul 2013, Kyle Simpson wrote: >> >> [Use-case V:] you have a string of scripts ("A.js", "B.js", and "C.js") >> loading which constitute a dependency chain. A must run before B, which >> must run before C. However, if you detect an error in loading, you stop >> the rest of the executions (and preferably loading too!), since clearly >> dependencies will fail for further scripts, and the errors will just >> unnecessarily clutter the developer console log making it harder to >> debug. <script src="A.js" prefetch></script> <script src="B.js" prefetch needs="A.js"></script> <script id=c src="C.js" prefetch needs="B.js"></script> <script> onerror = function (message, source, lineno, colno, error) { // report error } // when we need it... document.scripts.c.execute(); </script> >> [Use-case W:] some developers have even requested to be able to stop the >> chain and prevent further executions if the script loads, but there's >> some compile-time syntax error or run-time error that happens during the >> execution. For them, it's not enough for B to simply finish loading >> successfully, but that it must fully execute without error. <script id=a src="A.js" whenneeded></script> <script src="B.js" whenneeded needs="A.js"></script> <script id=c src="C.js" whenneeded needs="B.js"></script> <script> function onAfailedToInitialize() { document.scripts.a.src = null; } // when we need it... document.scripts.c.execute(); </script> > On Sun, 14 Jul 2013, Kornel Lesi?ski wrote (trimmed): >> >> [Use-case X:] not all dependencies are JS files, e.g. authors use >> plugins to load template files, JSON, images, etc. <script src="deps.js" async></script> <script src="build.js" needs="deps.js"></script> // in deps.js: var me = document.currentScript; var image = new Image(); image.src = 'image.png'; currentScript.needs.add(image); >> [Use-case Y:] not all dependencies are usefully satisfied immediately >> after their JS file is loaded, e.g. some libraries may need asynchronous >> initialization. I don't intend to address use case but we could make it so that script element without src is an indefinite dependency as in: <script src="slowLoad.js" async></script> <script src="next.js" needs="slowLoad.js"></script> // in slowLoad.js: var me = document.currentScript; var dummyScript = document.createElement('script'); me.needs.add(dummyScript); me.incDependencies(); setTimeout(init, 1000); function init() { // ok, we're ready me.needs.remove(dummyScript); } >> [Use-case Z:] Another common kind of dependency scripts have is presence >> of certain element in the DOM, e.g. `dropdown-menu.js` may require `<nav >> id="menu">` to be in the document _and_ have its content fully parsed >> before the script can run. I guess we can somehow make needs.add take an id as well as a script name and a node? Or add a method like requireElementWithId as in: <script src="navi.js" async></script> // in nav.js: document.currentScript.requireElementWithId('menu'); - R. Niwa From silviapfeiffer1 at gmail.com Tue Sep 3 15:01:16 2013 From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer) Date: Wed, 4 Sep 2013 08:01:16 +1000 Subject: [whatwg] Reconsidering how we deal with text track cues In-Reply-To: <alpine.DEB.2.00.1309032112000.7443@ps20323.dreamhostps.com> References: <CAHp8n2mbuxm=2aOSMS2S_oa042gMkSCOMTrn5odA9+Tbpo902w@mail.gmail.com> <Pine.LNX.4.64.1306121700000.17279@ps20323.dreamhostps.com> <CAHp8n2m1AcFS3WmwwniYyz=yZZucKrhzPoTu=eCOPd57jav+Og@mail.gmail.com> <51BFCCA6.4080208@brendanlong.com> <CAHp8n2nBcRZV5mW3+wA2f=pBifF1rCd-T5+_BQLQ9mv4rhGkxQ@mail.gmail.com> <alpine.DEB.2.00.1309032112000.7443@ps20323.dreamhostps.com> Message-ID: <CAHp8n2kO7F_rDXQRrREFcB=L4_+TuvanNDkLC7W51JJasHYKmw@mail.gmail.com> On Wed, Sep 4, 2013 at 7:38 AM, Ian Hickson <ian at hixie.ch> wrote: > On Mon, 17 Jun 2013, Silvia Pfeiffer wrote: >> On Thu, Jun 13, 2013 at 3:08 AM, Ian Hickson <ian at hixie.ch> wrote: >> > On Wed, 12 Jun 2013, Silvia Pfeiffer wrote: >> >> >> >> As we continue to evolve the functionality of text tracks, we will >> >> introduce more complex other structured content into cues and we will >> >> want browsers to parse and interpret them. >> > >> > I think it's a mistake to try to solve problems before they exist. We >> > don't know exactly what we'll be adding in the future, so we don't >> > know what we'll need yet. >> >> I'm preparing to start specifying how to render chapters. There's >> already been mention of need for a thumbnail image in chapters. >> >> I'll also have to specify how to "render" descriptions. Since the target >> audience are blind and vision-impaired users, there will be a rendering >> algorithm that includes speech synthesis. >> >> This is a problem I have to deal with now. > > I don't think the problems you describe here require any changes to the > API or to the format, but maybe I'm missing something. (Images for > chapters would, I guess, if you're not using the images from the video > file, but why wouldn't you use those actual images?) It's possible that the chapter track author wants to use other images. The images in DVD chapters aren't always from the video either. Also, if you have a audio-only src in the <video> element, but you want to provide images for chapter navigation, then you'd provide them in the WebVTT file, probably as dataURLs. I've seen that done before. >> >> For example, I expect that once we have support for speech synthesis >> >> in browsers [1], cues of kind descriptions will be voiced by speech >> >> synthesis, and eventually we want to influence that speech synthesis >> >> with markup (possibly a subpart of SSML [2] or some other simpler >> >> markup that influences prosody). >> > >> > I think it's highly unlikely that we'll actually ever want that, but >> > if we ever do, then we should fix the problem then. >> >> Rendering description cues with speech synthesis is 100% something that >> is coming. Richer markup of description cues is then just the logical >> next step - it won't be required now, but is certainly on the roadmap. >> How likely it will be to be SSML is unclear - I'd much prefer a simpler >> markup for WebVTT, too. > > I'm not even remotely convinced that speech synthesis in description cues > needs any markup, let alone markup more elaborate than VTT already has. That would be good. I've been told though that synthesised speech does not convey enough prosodic and emotional content and that markup would help with that (see http://en.wikipedia.org/wiki/Speech_synthesis#Prosodics_and_emotional_content). Not a top priority though. >> >> What we have done with WebVTT is actually two-fold: >> >> 1. we have created a file format that serializes arbitrary content >> >> that is time-synchronized with a media element. >> >> 2. and we have created a simple caption/subtitle cue format. >> >> >> >> That both are called "WebVTT" is the cause of a lot of confusion and not >> >> a good design approach. >> > >> > I think it's a mistake to view these as distinct. It's just one format. >> > But as you're that spec's editor, that's your choice. :-) >> >> We've actually done more - we also have a chapter and a metadata cue format: >> http://dev.w3.org/html5/webvtt/#dfn-webvtt-cue >> >> "WebVTT chapter title text is syntactically a subset of WebVTT cue >> text, and WebVTT cue text is syntactically a subset of WebVTT metadata >> text. Conformance checkers, when validating WebVTT files, may offer to >> restrict all cues to only having WebVTT chapter title text or WebVTT >> cue text as their cue payload; WebVTT metadata text cues are only >> useful for scripted applications (using the metadata text track >> kind)." >> >> They are already hierarchically defined upon each other (already when >> you were the editor). >> >> They just aren't represented in objects in this way. > > I don't think the way you're viewing it is the right way to view it. IMHO > there's just one format, it just can be used in various ways, just like > HTML can be used for applications and documents and games, etc. Just like > how HTML sometimes requires a <title> and sometimes does not, based on > context, there are different contextual constraints on authoring VTT. But > it's still just one format. I've followed that view (you might have seen such a message on the W3C list). I'm expecting it will lead to interesting consequences, such as hyperlinks and dataURLs becoming part of WebVTT cue markup. But it is likely the easier route. Cheers, Silvia. From ian at hixie.ch Tue Sep 3 16:13:59 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 3 Sep 2013 23:13:59 +0000 (UTC) Subject: [whatwg] Challenging canvas.supportsContext In-Reply-To: <CAJTmd9q-eH8fnZSP5mr3kX-quyQcNXnyXTh5o_hX+MdfuXfrGQ@mail.gmail.com> References: <CAJTmd9rkwsjC+WDfLr7um0=h8Pvtg9JOJCRHzH4PhdbXjgpaaA@mail.gmail.com> <CAJTmd9q-eH8fnZSP5mr3kX-quyQcNXnyXTh5o_hX+MdfuXfrGQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309032240300.7443@ps20323.dreamhostps.com> The long and short of this is that I renamed "supportsContext()" to "probablySupportsContext()". It's already implemented in WebKit (and dino says he's going to rename it in the implementation also). Fundamentally, it addresses a need that none of the other proposals addressed: how to know whether or not you can expect to be able to do 3D. It's not 100% reliable, but then neither would actually attempting to create a context, because creating a context is so expensive on some platforms that some UAs are going to move to doing it lazily and so you're back to exactly the same level of reliability as this API. Plus, it'd be a lot more awkward as an API. On Wed, 19 Jun 2013, Benoit Jacob wrote: > > I'd like to question the usefulness of canvas.supportsContext. I tried to > think of an actual application use case for it, and couldn't find one. The use case is libraries like Modernizr that want to do feature detection up-front, but don't want a high performance hit on startup. > However, that only shifts the question to: what is the reason for them > to expose such APIs? In the end, I claim that the only thing that we > should recognize as a reason to add a feature to the HTML spec, is > *application* use cases. Oh well the use case for knowing whether or not 3D is supported on a particular device is straight-forward: you want to know which set of assets and logic to download and run. > So let's look at the naive application usage pattern for supportsContext: > > if (canvas.supportsContext("webgl")) { > context = canvas.getContext("webgl"); > } > > The problem is that the same can be achieved with just the getContext > call, and checking whether it succeeded. Suppose you have an app that has a 3D feature, but it's not immediately used upon startup. For example, a preview window that is displayed on request. You want to preload all the code to run the preview window, but you need to load different code based on whether the device can do 3D or not. So the use case is more: if (canvas.supportsContext("webgl")) load3DCode(); else load2DCode(); // 3D code: function run() { context = canvas.getContext("webgl"); // ... } You don't want to pay the cost of creating a throw-away 3D context on startup just to know which scripts to load. It defeats the whole point of not loading all the code up-front. > Outside of exceptional cases (out of memory...), the slow path in > getContext is the *success* case, and again, in that case a real > application would want to actually *use* that context. Not necessarily, as noted above. The <canvas> you're going to draw to might not even exist at the point you need to know if it's 3D or not. > Keep in mind that supportsContext can't guarantee that if it returns true, > then a subsequent getContext will succeed. Sure. getContext() can't guarantee that if it returns a context, the context will work forever, either. > The spec doesn't require it to, either. So if the existence of > supportsContext misleads application developers into no longer checking > for getContext failures, then we'll just have rendered canvas-using > applications a little bit more fragile. That's a risk, yes. > Another problem with supportsContext is that it's untestable, at least > when it returns true; it is spec-compliant to just implement it as > returning whether the JS interface for the required canvas context > exists, which is quite useless. That would indeed be useless. > Given such deep problems, I think that the usefulness bar for accepting > supportsContext into the spec should be quite high. The problem is that there's no alternative solution. On Wed, 19 Jun 2013, Tab Atkins Jr. wrote: > > This is missing the point. You don't want to wait until it's actually > time to create the context. Unless you torture your code flow, by the > time you're creating a context you should already know that the context > is supported. The knowledge of which context to use is most useful well > before that, when you're first entering the app. > > Plus, it doesn't matter how late you do the detection - if you do a > straight *detection* at all rather than an initialization (that is, if > you throw away the context you've just created for testing), you'll > still incur the start-up costs of spinning up a context. Doing that > early or late doesn't matter too much - it's bad either way. Indeed. > Like @supports, the supportsContext() method can be easy and reliable > with a very simple definition for "supports" - it returns true if > calling getContext() with the same arguments would return a context > rather than erroring, and false otherwise. No capacity for lying there > without breaking sites. At least, no capacity beyond the same one that getContext() has in the first place, namely that it might return a useful object that later stops working. On Wed, 19 Jun 2013, Kenneth Russell wrote: >> > Additionally, though, application developers wanted to be able to ask > questions like "is software rendering supported for WebGL": > > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-September/037232.html > > I think this second use case is valid. One could imagine a graphing or > charting library which would use low-power, software-rendered WebGL if > available, but otherwise would fall back to using > CanvasRenderingContext2D. Indeed. This is supported per the spec, assuming getContext() supports the relevant arguments. On Wed, 19 Jun 2013, Boris Zbarsky wrote: > > I see. For this use case, the current definition of supportsContext is > of limited utility, unless you make some assumptions about behavior that > the spec does not require.... I think what the spec requires is as close as one can get to those assumptions without requiring something that can't be implemented, no? On Wed, 19 Jun 2013, James Robinson wrote: > > What would a page using Modernizr (or other library) to feature detect > WebGL do if the supportsContext('webgl') call succeeds but the later > getContext('webgl') call fails? Presumably the same as if the first getContext('webgl') call succeeds today, but the next getContext('webgl') call fails. On Wed, 19 Jun 2013, Kenneth Russell wrote: > > supportsContext() can give a much more accurate answer than > !!window.WebGLRenderingContext. I can only speak for Chromium, but in > that browser, it can take into account factors such as whether the GPU > sub-process was able to start, whether WebGL is blacklisted on the > current card, whether WebGL is disabled on the current domain due to > previous GPU resets, and whether WebGL initialization succeeded on any > other page. All of these checks can be done without the heavyweight > operation of actually creating an OpenGL context. Yeah, it seems to me that the cases where probablySupportsContext() would return the wrong result are not that common. On Wed, 19 Jun 2013, Kenneth Russell wrote: > > Any application which has a complex set of fallback paths. For example, > > - Preference 1: supportsContext('webgl', { softwareRendered: true }) > - Preference 2: supportsContext('2d', { gpuAccelerated: true }) > - Preference 3: supportsContext('webgl', { softwareRendered: false }) > - Fallback: 2D canvas > > I agree that ideally, if supportsContext returns true then -- without > any other state changes that might affect supportsContext's result -- > getContext should return a valid rendering context. It's simply > impossible to guarantee this correspondence 100% of the time, but if > supportsContext's spec were tightened somehow, and conformance tests > were added which asserted consistent results between supportsContext and > getContext, would that address your concern? If there's a way to tighten up the requirements in the spec, please do let me know. I'm not sure what more to say there right now. On Wed, 19 Jun 2013, Tab Atkins Jr. wrote: > > It seems like this falls into the canPlayType() bucket, where you can > definitely give negatives, but your positives are at best hopeful. Maybe > we should just have it do the same thing, and return "maybe" or > "probably" rather than a boolean true? I renamed the method to try to make this clearer. On Wed, 19 Jun 2013, James Robinson wrote: > > var ctx = canvas.getContext('webgl', { 'allowSoftware': false}); > if (ctx) { > doPreference1(ctx); > return; > } > ctx = canvas.getContext('2d', {'allowSoftware': false}); > if (ctx) { > doPreference2(ctx); > // etc > > how could I simplify this code using supportsContext() ? "doPreference1()" and friends here are most likely to be "fetch the code, create the <canvas>es, create the contexts", etc. Getting the context from the feature test all the way to where it is first used seems like a lot of complexity. > It seems overwhelmingly likely that one of the state changes that might > affect the result will be attempting to instantiate a real context. Can you elaborate on this? > I don't see how supportsContext() could be as accurate as getContext() > without doing all of the work getContext() does. If it's not 100% > accurate, when is it useful? getContext() isn't 100% accurate either, and it's more expensive. On Wed, 19 Jun 2013, Benoit Jacob wrote: > > In Mozilla code, we fail WebGL context creation if any GL error occurs > during initialization, where we have to make a number of specific OpenGL > calls (e.g. querying many constants, enabling point sprites...). So it > is perfectly possible for WebGL specifically to fail on a given device > where OpenGL compositing works, without being specifically blacklisted, > and currently we can rely on these automatic checks rather than having > to curate a blacklist for these problems, which is very nice. You could bring these tests forward in the implementation, so that probablySupportsContext() itself doesn't have to do them, right? > Another way in which WebGL specifically can fail, is that some driver > bugs cause errors that we may want to ignore in our compositor code but > not in WebGL. To give an example, on many Vivante GPU drivers, which are > very common in Chinese mobile devices, the first eglMakeCurrent call on > a newly created context can return false without any actual EGL error > [1]. A browser may want to ignore this error in its compositor to be > able to run nonetheless on such devices, but without WebGL support. Wouldn't you know this before the call to getContext(), though? On Thu, 20 Jun 2013, Boris Zbarsky wrote: > On 6/19/13 6:04 PM, Kenneth Russell wrote: > > supportsContext() can give a much more accurate answer than > > !!window.WebGLRenderingContext. I can only speak for Chromium, but in > > that browser, it can take into account factors such as whether the GPU > > sub-process was able to start, whether WebGL is blacklisted on the > > current card, whether WebGL is disabled on the current domain due to > > previous GPU resets, and whether WebGL initialization succeeded on any > > other page. > > window.WebGLRenderingContext can take things like that into account too, > in Gecko. For what it's worth. Wouldn't checking for window.WebGLRenderingContext be just as unreliable then? I don't understand why it's ok to be able to test that, but why probablySupportsContext() wouldn't be ok. On Wed, 19 Jun 2013, Paul Irish wrote: > > On the Modernizr side, an old version did indeed create a context for > feature detection. For the past two years we have advocated the soft > `"WebGLRenderingContext" in window` test instead. There, of course, is > some gap between the results of that detect and how successful a > getContext call will be, but I don't have data those false positive > rates. Right, this would let you close that gap a bit. On Thu, 20 Jun 2013, Boris Zbarsky wrote: > > So that's an interesting question. Should UAs simply not have > window.WebGLRenderingContext in situations in which supportsContext > would return false? probablySupportsContext() takes arguments that affect the answer. (Also, the answer can vary over time.) On Wed, 19 Jun 2013, Boris Zbarsky wrote: > > > > Plus, it doesn't matter how late you do the detection - if you do a > > straight *detection* at all rather than an initialization (that is, if > > you throw away the context you've just created for testing) > > OK, but why are we making that assumption? I guess if people insist on > doing that, then we do in fact need something that will basically try to > guess whether getContext might succeed. Paul reported that this is common practice, for what it's worth. > > Like @supports, the supportsContext() method can be easy and reliable > > with a very simple definition for "supports" - it returns true if > > calling getContext() with the same arguments would return a context > > rather than erroring, and false otherwise. > > Just so we're clear, this is _not_ what supportsContext is specified to > do. As specced, it will return false if you know for a fact that > getContext would return null. It will return true if you think that > getContext might not return null. This means that a true return doesn't > really mean squat about what getContext will do. > > And the reason for that is that you can't tell whether getContext will > return null until you try to do it, given how getContext is specced. I'm happy to try to tighten this up if you have any suggestions. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From rniwa at apple.com Tue Sep 3 16:36:44 2013 From: rniwa at apple.com (Ryosuke Niwa) Date: Tue, 03 Sep 2013 16:36:44 -0700 Subject: [whatwg] Script preloading In-Reply-To: <AD835154-3364-4FDC-B983-4167CA6271CA@apple.com> References: <Pine.LNX.4.64.1307091607110.24681@ps20323.dreamhostps.com> <CA+c2ei-ywCwWHNC6SfWA8CxB4XTbh=hMA3j8K0=tspwtQB3SiA@mail.gmail.com> <DDDE638B-B515-43DE-A0EB-AB20CC73FE1D@gmail.com> <CA+c2ei8pT5s+2z-xPqz5x8sn2gGZD=uGB7FH9JcddE5xOpvVag@mail.gmail.com> <E742ACB2-B2AC-4D77-B7AA-43B3625FBBE9@gmail.com> <CA+c2ei-+xCmm6gW45-s72XUjond5VF4TkwTdcY5jZ6dkZUsUuA@mail.gmail.com> <alpine.DEB.2.00.1308212259080.27209@ps20323.dreamhostps.com> <AD835154-3364-4FDC-B983-4167CA6271CA@apple.com> Message-ID: <FAD2DACB-53C3-44D2-B0A9-BF3B6EB4A6AC@apple.com> Per IRC discussion, I misunderstood the timing at which these at which dependencies are executed. Now I agree it's desirable to have two values for when needed as proposed by Ian in the original e-mail. For other people following this thread's sake, a.js will execute immediately as soon as it's loaded in this example: <script src="a.js" whenneeded></script> <script id=b src="b.js" needs="a.js" whendeeded></script> // later document.scripts.b.execute(); whereas a.js doesn't get executed until b.js is loaded in this example: <script src="a.js" whenneeded=jit></script> <script id=b src="b.js" needs="a.js" whendeeded></script> // later document.scripts.b.execute(); - R. Niwa On Sep 3, 2013, at 2:49 PM, Ryosuke Niwa <rniwa at apple.com> wrote: > Original proposal: > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-August/040664.html > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-August/040666.html > > In order to address use cases incDependencies and decDependencies satisfied, I'm going to add the following proposals: > > I make one more change that in order for a dependency specified in "needs" to be satisfied, > "src" content attribute of the dependent script needs to match the value when the script finished running. > e.g. myscript.src = null leaves any dependency on myscript unsatisfied. > > Also make "needs" IDL property take in any HTML element; e.g. adding an image element to "needs" makes the script wait until the corresponding image resource is loaded. > > On Aug 27, 2013, at 2:55 PM, Ian Hickson <ian at hixie.ch> wrote: > >> >> First, let's get down to use cases. Kyle did a great job of describing >> some key use cases: >> >> On Wed, 10 Jul 2013, Kyle Simpson wrote: >>> >>> [Use-case Q:] I am dynamically loading one of those social widgets that, >>> upon load, automatically scans a page and renders social buttons. I need >>> to be able to preload that script so it's ready to execute, but decide >>> when I want it to run against the page. I don't want to wait for true >>> on-demand loading, like when my user clicks a button, because of the >>> loading delay that will be visible to the user, so I want to pre-load >>> that script and have it waiting, ready at a moment's notice to say "it's >>> ok to execute, do it now! now! now!". > > <script id="social" src="social-button.js" prefetch></script> > <button onmouseover="document.scripts.social.execute()"> ... </button> > >>> [Use-case S:] One CMS plugin wants to load "A.js" and "B.js", where B >>> relies on A. Both need to load in parallel (for performance), but A must >>> execute before B executes. I don't control A and B, so changing them is >>> not an option. This CMS plugin [wants] to wait for some >>> user-interaction, such as a button click, before executing the code. We >>> don't want there to be any big network-loading delay visible to the user >>> between their click of the button and the running of that plugin's code. > > // CMS plugin 1 > var A = E('script', { src: 'A.js', prefetch: true }); > var B = E('script', { src: 'B.js', needs: 'A.js', prefetch: true }); > document.body.append(A, B); > function sawUserInteraction() { > B.execute(); > }; > > >>> Another CMS plugin on this same page wants to load "A.js", "C.js", and >>> "D.js". This plugin doesn't know or care that the other plugin also >>> requests "A.js". It doesn't know if there is a script element in the >>> page requesting it or not, and it doesn't want to looking for it. It >>> just wants to ask for A as a pre-requisite to C and D. But C and D have >>> no dependency on each other, only a shared dependency on A. C and D >>> should be free to run ASAP (in whichever order), assuming that A has >>> already run [once] some user-interaction that initiates the load of A, >>> C, and D. This user interaction may be before the other plugin requested >>> A, or after it requested A. > > // CMS plugin 2 > var A = E('script', { src: 'A.js', prefetch: true }); > var C = E('script', { src: 'C.js', needs: 'A.js', prefetch: true }); > var D = E('script', { src: 'D.js', needs: 'A.js', prefetch: true }); > document.body.append(A, C, D); > function sawUserInteraction() { > C.execute(); > D.execute(); > }; > >>> "A.js" can be requested relatively (via a <base> tag or just relative to >>> document root) or absolutely, or it might be requested with the >>> leading-// protocol-relative from, taking on whatever http or https >>> protocol the page has, whereas other references to it may specify the >>> prototcol. >>> >>> These plugins can't guarantee what ID's or classes they use are reliably >>> unique without undue processing burden. >> >> [I've trimmed the text Kyle wrote here, but also implicit in his >> description, as I understood it, was that A.js should only run once even >> if both plugins tried to load it.] >> >>> [Use-case T:] I have two different calendar widgets. I want to pop one >>> of them up when a user clicks a button. The user may never click the >>> button, in which case I don't want the calendar widget to have ever >>> executed to render. [...] > > <script id=calA src="a.js" prefetch></script> > <script id=calB src="b.js" prefetch></script> > <script> > function showCalendar(which) { > if (which == 'a') > document.scripts.calA.execute(); > else > document.scripts.calB.execute(); > } > </script> > > Neither Ian's nor my proposal fallbacks gracefully here :( > >>> [Use-case U:] I have a set of script "A.js", "B.js", and "C.js". B >>> relies on A, and C relies on B. So they need to execute strictly in that >>> order. [Now], imagine they progressively render different parts of a >>> widget. [...] I only want to execute A, B and C once all 3 are preloaded >>> and ready to go. It's [...] about minimizing delays between them, for >>> performance PERCEPTION. >>> >>> [For example, one of them might start playing a video, and another might >>> introduce the <canvas> slides for that video. You want all of the >>> relevant scripts to be run at once, so there's no point where the page >>> has a <video> element but doesn't have the <canvas>.] > > <script src="A.js" prefetch></script> > <script src="B.js" prefetch needs="A.js"></script> > <script id=c src="C.js" prefetch needs="B.js"></script> > <script> > // when we need it... > document.scripts.c.execute(); > </script> > >> On Thu, 11 Jul 2013, Kyle Simpson wrote: >>> >>> [Use-case V:] you have a string of scripts ("A.js", "B.js", and "C.js") >>> loading which constitute a dependency chain. A must run before B, which >>> must run before C. However, if you detect an error in loading, you stop >>> the rest of the executions (and preferably loading too!), since clearly >>> dependencies will fail for further scripts, and the errors will just >>> unnecessarily clutter the developer console log making it harder to >>> debug. > > <script src="A.js" prefetch></script> > <script src="B.js" prefetch needs="A.js"></script> > <script id=c src="C.js" prefetch needs="B.js"></script> > <script> > onerror = function (message, source, lineno, colno, error) { > // report error > } > // when we need it... > document.scripts.c.execute(); > </script> > >>> [Use-case W:] some developers have even requested to be able to stop the >>> chain and prevent further executions if the script loads, but there's >>> some compile-time syntax error or run-time error that happens during the >>> execution. For them, it's not enough for B to simply finish loading >>> successfully, but that it must fully execute without error. > > <script id=a src="A.js" whenneeded></script> > <script src="B.js" whenneeded needs="A.js"></script> > <script id=c src="C.js" whenneeded needs="B.js"></script> > <script> > function onAfailedToInitialize() { > document.scripts.a.src = null; > } > // when we need it... > document.scripts.c.execute(); > </script> > >> On Sun, 14 Jul 2013, Kornel Lesi?ski wrote (trimmed): >>> >>> [Use-case X:] not all dependencies are JS files, e.g. authors use >>> plugins to load template files, JSON, images, etc. > > <script src="deps.js" async></script> > <script src="build.js" needs="deps.js"></script> > > // in deps.js: > var me = document.currentScript; > var image = new Image(); > image.src = 'image.png'; > currentScript.needs.add(image); > >>> [Use-case Y:] not all dependencies are usefully satisfied immediately >>> after their JS file is loaded, e.g. some libraries may need asynchronous >>> initialization. > > I don't intend to address use case but we could make it so that script element without src is an indefinite dependency as in: > > <script src="slowLoad.js" async></script> > <script src="next.js" needs="slowLoad.js"></script> > > // in slowLoad.js: > > var me = document.currentScript; > var dummyScript = document.createElement('script'); > me.needs.add(dummyScript); > me.incDependencies(); > setTimeout(init, 1000); > function init() { > // ok, we're ready > me.needs.remove(dummyScript); > } > >>> [Use-case Z:] Another common kind of dependency scripts have is presence >>> of certain element in the DOM, e.g. `dropdown-menu.js` may require `<nav >>> id="menu">` to be in the document _and_ have its content fully parsed >>> before the script can run. > > I guess we can somehow make needs.add take an id as well as a script name and a node? > Or add a method like requireElementWithId as in: > > <script src="navi.js" async></script> > // in nav.js: > document.currentScript.requireElementWithId('menu'); > > - R. Niwa > From willchan at chromium.org Tue Sep 3 17:01:11 2013 From: willchan at chromium.org (=?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?=) Date: Wed, 4 Sep 2013 08:01:11 +0800 Subject: [whatwg] Script preloading In-Reply-To: <Pine.LNX.4.64.1307091607110.24681@ps20323.dreamhostps.com> References: <Pine.LNX.4.64.1307091607110.24681@ps20323.dreamhostps.com> Message-ID: <CAA4WUYgXuL0Qcw0+3K53mm64i=o_qfVCMtvXMEyao5O83z7vsw@mail.gmail.com> Hello folks. Sorry for the late response to several comments in this mega-thread, I've mostly been traveling/vacationing for the past 2 months. A teammate asked me to look at this in case I had comments. I don't know web dev issues very well, so I'm going to restrain myself from offering many opinions about the new proposals other than wow, all this dependency stuff looks complicated, but maybe it's worth it? I'll keep to some observations from a networking performance perspective, in case it's relevant to the discussion: * Any advantages the preloader currently gives is probably only going to be magnified with HTTP/2. Browsers today will in key situations hold back lower priority resource loads, even after the resource has been discovered by the parser/preloader, in order to reduce network contention and prioritize resources. But with HTTP/2, the browser almost never has to do this since it can express the request priority in the HTTP/2 protocol itself, and let the server order responses appropriately. * <link rel=subresource> is great for resource discovery. Given the above observation, note that it has some deficiencies. Most obviously, it does not indicate the resource type. Browsers today can heuristically assign a priority based on the resource type (script/image/stylesheet/etc). Arguably, browsers could just use the filename extension as a hint to the resource type, and that'd get us most of the way there. In any case, Chromium, when it encounters <link rel=subresource> is going to assign the resource load the lowest priority level, and only when the parser encounters the actual resource via a <script> tag or something, will another resource load be issued with the "appropriate" priority. Almost all modern browsers will hold back low priority resource loads before first paint in order to get critical scripts and stylesheets in <head> ASAP without contention. Anything marked with <link rel=subresource> will be considered low priority and in all likelihood not requested early. Note that HTTP/2 currently does not support re-prioritization (and that feature is being debated), so that means that when the resource load for <link rel=subresource> gets issued over an HTTP/2 connection, it will have the lowest priority, which is probably undesirable. FWIW, I think <link rel=subresource> was a good initial start, but suffers from key weaknesses and should be thrown out and replaced. * Given current browser heuristics for resource prioritization based on resource type, all <script> resources will have the same priority. Within HTTP/1.X, that means you'll get some amount of parallelization based on the connection per host limit and what origins the script resources are hosted, and then get FIFO. New additions like lazyload attributes (and perhaps leveraging the defer attribute) may affect this. With HTTP/2, there is a very high (effectively infinite) parallelization limit. With prioritization, there's no contention across priority levels. But since script resources today generally all have the same priority, they will all contend and most naive servers are going to round robin the response bytes, which is the worst thing you could do with script resources, since current JS VMs do not incrementally process script resources, but process them as a whole. So round-robining all the response bytes will just push out start time of JS processing for all scripts, which is rather terrible. * Obviously, given what I've said above, some level of hinting of prioritization/dependency amongst scripts/resources within the web platform would be useful to the networking layer since the networking layer can much more effectively prioritize resources and thus mitigate network contention. If finer grained priority/dependency information isn't provided in the web platform, my browser's networking stack is likely going to have to, even with HTTP/2, do HTTP/1.X style contention mitigation by restricting parallelization within a priority level. Which is a shame since web developers probably think that with HTTP/2, they can have as many fine grained resources as they want. Cheers. On Wed, Jul 10, 2013 at 3:39 AM, Ian Hickson <ian at hixie.ch> wrote: > > A topic that regularly comes up is script loading. > > I sent an e-mail responding to related feedback last year, though it > didn't get any replies to the script loading parts of it: > > > http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0221.html > > It seems that people want something that: > > - Lets them download scripts but not execute them until needed. > - Lets them have multiple interdependent scripts and have the browser > manage their ordering. > - Do all this without having to modify existing scripts. > > I must admit to not really understanding these requirements (script > execution can be made more or less free if they are designed to just > expose some functions, for example, and it's trivial to set up a script > dependency mechanism for scripts to run each other in order, and there's > no reason browsers can't parse scripts off the main thread, etc). But > since everyone else seems to think these are issues, let's ignore that. > > The proposals I've seen so far for extending the spec's script preloading > mechanisms fall into two categories: > > - provide some more control over the mechanisms already there, e.g. > firing events at various times, adding attributes to make the script > loading algorithm work differently, or adding methods to trigger > particular parts of the algorithm under author control. > > - provide a layer above the current algorithm that provides strong > semantics, but that doesn't have much impact on the loading algorithm > itself. > > I'm very hesitant to do the first of these, because the algorithm is _so_ > complicated that adding anything else to it is just going to result in > bugs in browsers. There comes a point where an algorithm just becomes so > hard to accurately test that it's a lost cause. > > The second seems more feasible, though. > > Would something like this, based on proposals from a variety of people in > the past, work for your needs? > > 1. Add a "dependencies" attribute to <script> that can point to other > scripts to indicate that execution of this script should be delayed > until all other scripts that are (a) earlier in the tree order and (b) > identified by this attribute have executed. > > <script id="jquery" src="jquery.js" async></script> > <script id="shims" src="shims.js" async></script> > <script dependencies="shims jquery" src="myscript.js" async></script> > > This would download jquery.js, shims.js, and myscript.js ASAP, without > blocking anything else, and would then run jquery.js and shims.js ASAP, > in any order, and then once both have executed, it would execute > myscript.js. > > 2. Add an "whenneeded" boolean content attribute, a "markNeeded()" method, > and an internal "is-needed flag" (initially false) to the <script> > element. When a script is about to execute, if its whenneeded="" > attribute is set, but its "is-needed" flag is not, then delay > execution. Calling markNeeded() on a script that has a whenneeded > boolean but that has not executed yet first causes the markNeeded() > method on all the script's dependencies to be called, and then causes > this script to become ready to execute. > > <script id="jquery" src="jquery.js" async whenneeded></script> > <script id="shims" src="shims.js" async whenneeded></script> > <script id="myscript" dependencies="shims jquery" src="myscript.js" > async whenneeded></script> > > This would download jquery.js, shims.js, and myscript.js ASAP, and then > wait for further instructions. > > document.getElementById('myscript').markNeeded(); > > This would then cause the scripts to execute, first jquery.js and > shims.js (in any order), and then myscript.js. If any hadn't finished > downloading yet, it would first wait for that to finish. > > (We could make markNeeded() return a promise, too.) > > Is there a need for delaying the download of a script as well? (If so, we > could change whenneeded="" to have values, like whenneeded="execute" vs > whenneeded="download" or something.) > > Is there something this doesn't handle which it would need to handle? > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > From bzbarsky at MIT.EDU Tue Sep 3 17:47:04 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Tue, 03 Sep 2013 20:47:04 -0400 Subject: [whatwg] Challenging canvas.supportsContext In-Reply-To: <alpine.DEB.2.00.1309032240300.7443@ps20323.dreamhostps.com> References: <CAJTmd9rkwsjC+WDfLr7um0=h8Pvtg9JOJCRHzH4PhdbXjgpaaA@mail.gmail.com> <CAJTmd9q-eH8fnZSP5mr3kX-quyQcNXnyXTh5o_hX+MdfuXfrGQ@mail.gmail.com> <alpine.DEB.2.00.1309032240300.7443@ps20323.dreamhostps.com> Message-ID: <52268308.1090802@mit.edu> On 9/3/13 7:13 PM, Ian Hickson wrote: > Wouldn't checking for window.WebGLRenderingContext be just as unreliable > then? I don't understand why it's ok to be able to test that, but why > probablySupportsContext() wouldn't be ok. I'm a lot more OK with the "probablySupportsContext" naming than "supportsContext" here. -Boris From rniwa at apple.com Tue Sep 3 20:00:45 2013 From: rniwa at apple.com (Ryosuke Niwa) Date: Tue, 03 Sep 2013 20:00:45 -0700 Subject: [whatwg] Prioritizing subresources (Was Script preloading) In-Reply-To: <CAA4WUYgXuL0Qcw0+3K53mm64i=o_qfVCMtvXMEyao5O83z7vsw@mail.gmail.com> References: <Pine.LNX.4.64.1307091607110.24681@ps20323.dreamhostps.com> <CAA4WUYgXuL0Qcw0+3K53mm64i=o_qfVCMtvXMEyao5O83z7vsw@mail.gmail.com> Message-ID: <86A0181F-5695-4801-9254-D2B0E0CA5928@apple.com> On Sep 3, 2013, at 5:01 PM, William Chan (???) <willchan at chromium.org> wrote: > Hello folks. Sorry for the late response to several comments in this > mega-thread, I've mostly been traveling/vacationing for the past 2 months. > A teammate asked me to look at this in case I had comments. I don't know > web dev issues very well, so I'm going to restrain myself from offering > many opinions about the new proposals other than wow, all this dependency > stuff looks complicated, but maybe it's worth it? I'll keep to some > observations from a networking performance perspective, in case it's > relevant to the discussion: > > * Any advantages the preloader currently gives is probably only going to be > magnified with HTTP/2. Browsers today will in key situations hold back > lower priority resource loads, even after the resource has been discovered > by the parser/preloader, in order to reduce network contention and > prioritize resources. But with HTTP/2, the browser almost never has to do > this since it can express the request priority in the HTTP/2 protocol > itself, and let the server order responses appropriately. > * <link rel=subresource> is great for resource discovery. Given the above > observation, note that it has some deficiencies. Most obviously, it does > not indicate the resource type. Browsers today can heuristically assign a > priority based on the resource type (script/image/stylesheet/etc). > Arguably, browsers could just use the filename extension as a hint to the > resource type, and that'd get us most of the way there. In any case, > Chromium, when it encounters <link rel=subresource> is going to assign the > resource load the lowest priority level, and only when the parser > encounters the actual resource via a <script> tag or something, will > another resource load be issued with the "appropriate" priority. Almost all > modern browsers will hold back low priority resource loads before first > paint in order to get critical scripts and stylesheets in <head> ASAP > without contention. Anything marked with <link rel=subresource> will be > considered low priority and in all likelihood not requested early. Note > that HTTP/2 currently does not support re-prioritization (and that feature > is being debated), so that means that when the resource load for <link > rel=subresource> gets issued over an HTTP/2 connection, it will have the > lowest priority, which is probably undesirable. FWIW, I think <link > rel=subresource> was a good initial start, but suffers from key weaknesses > and should be thrown out and replaced. > * Given current browser heuristics for resource prioritization based on > resource type, all <script> resources will have the same priority. Within > HTTP/1.X, that means you'll get some amount of parallelization based on the > connection per host limit and what origins the script resources are hosted, > and then get FIFO. New additions like lazyload attributes (and perhaps > leveraging the defer attribute) may affect this. With HTTP/2, there is a > very high (effectively infinite) parallelization limit. With > prioritization, there's no contention across priority levels. But since > script resources today generally all have the same priority, they will all > contend and most naive servers are going to round robin the response bytes, > which is the worst thing you could do with script resources, since current > JS VMs do not incrementally process script resources, but process them as a > whole. So round-robining all the response bytes will just push out start > time of JS processing for all scripts, which is rather terrible. > * Obviously, given what I've said above, some level of hinting of > prioritization/dependency amongst scripts/resources within the web platform > would be useful to the networking layer since the networking layer can much > more effectively prioritize resources and thus mitigate network contention. > If finer grained priority/dependency information isn't provided in the web > platform, my browser's networking stack is likely going to have to, even > with HTTP/2, do HTTP/1.X style contention mitigation by restricting > parallelization within a priority level. Which is a shame since web > developers probably think that with HTTP/2, they can have as many fine > grained resources as they want. Why don't we simply add "priority" content attribute to link element then? <link rel=subresource href="high-priority-resource.js" priority="high"> <link rel=subresource href="low-priority-resource.js" priority="low"> But can we modify these priorities dynamically? I have one specific use case that requires this. Use case D: A web page wants to load and execute a script widget.js if the script is already cached in the browser. However, it wants to load other essential assets such as images first if it's not already in the cache except as long as the user had not started interacting with the parts of the page that require widget.js. i.e. it (loads and) executes the script immediately when and only when the script had already been cached or the user had started interacting with the parts of the page that requires the script. Otherwise, the script is loaded with a low priority. - R. Niwa From jkorpela at cs.tut.fi Tue Sep 3 22:30:03 2013 From: jkorpela at cs.tut.fi (Jukka K. Korpela) Date: Wed, 04 Sep 2013 08:30:03 +0300 Subject: [whatwg] @generator-unable-to-provide-required-alt, figure with figcaption In-Reply-To: <alpine.DEB.2.00.1309032059410.7443@ps20323.dreamhostps.com> References: <CA+ri+VmGmZh2goTez1YpOce9C=WpoEdwH3ToV+X0owpnUeOVYQ@mail.gmail.com> <6D789473-22C6-48B1-BD55-1D375834178A@prlbr.com> <Pine.LNX.4.64.1306172040500.11139@ps20323.dreamhostps.com> <026D354F-5220-4F2B-823F-125249027E52@prlbr.com> <Pine.LNX.4.64.1306191743130.11139@ps20323.dreamhostps.com> <0525D1DC-57F5-4F4C-838E-D7D280E9D984@prlbr.com> <alpine.DEB.2.00.1309032059410.7443@ps20323.dreamhostps.com> Message-ID: <5226C55B.5080603@cs.tut.fi> 2013-09-04 0:09, Ian Hickson wrote: >> To a user, even ?(an image)? is better than lack of alt attribute > > I disagree. The lack of an alt attribute can be used by user agents to > substitute the string "(an image)", in which case it is the same, or it > can be used to do far more, e.g. image recognition, OCR, etc. This isn't > academic, these technologies exist today. There is nothing that makes that makes that impossible, or more difficult, if the element has an alt attribute. If you mean that programs would actually do such things if and only if the alt attribute is absent, then this is very speculative. Let?s worry about that when browsers are actually capable and willing to do such things at all. There is an essential difference between lack of an alt attribute and a more or less generic value used for it, as in alt="(an image)" or in alt="(image: horse5)" (automatically generated e.g. from an image URL that ends with horse5.png) or in alt="(photo of Hixie)". Lack of the alt attribute says absolutely nothing about the image; it might represent a word as an image, or be pure decoration, or be so complicated that writing a textual alternative would be major challenge in content production. Someone who hears, says ?image ? horse five? at least gets some idea of what the image is about, and even ?an image? as opposite to whatever a speech browsers says about <img ... alt=""> is an improvement: the user can know that the author tried to find a textual replacement for the image but couldn't. > To the non-validator user agent, that attribute means nothing. It's a > non-conforming attribute with no semantics to any software outside content > generators and conformance checkers. It is presented as a non-conforming attribute that can be used to get a clean validation report, i.e. to make a validator report a document as valid, as conforming. This is grossly illogical and misleading. Anyone who uses a validator has the right to know whether the document is valid or not, to the extent that this can be programmatically determined. And it is, if the attribute is not valid. Here's a proposal: The character U+FFFC OBJECT REPLACEMENT CHARACTER, which is ?used as placeholder in text for an otherwise unspecified object? [the quote is from the code chart entry in the Unicode Standard] be used as the value of an alt attribute to indicate that it was not possible to write an adequate alternate text for the image. This typically means that the image comes from a source external to the system that generates the HTML document and the system cannot analyze it or otherwise find a suitable text replacement. You could even add a statement like this: User agents that present the value of an alt attribute to the user may express the value of U+FFFC using a generic expression like ?some image?. They may also apply technologies that process the image trying to recognize its content and then express the result suitably, e.g. ?an unrecognizable image? or ?an image of a horse? or (in the case of having recognized that the content is scannable as text) ?Hello?. ? It?s of course possible that people would then use alt="&#fffc;" to silence validators even when they could easily write real text there. But they can anyway use alt="" for such purposes if they want to. Yucca From willchan at chromium.org Tue Sep 3 23:06:56 2013 From: willchan at chromium.org (=?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?=) Date: Wed, 4 Sep 2013 14:06:56 +0800 Subject: [whatwg] Prioritizing subresources (Was Script preloading) In-Reply-To: <86A0181F-5695-4801-9254-D2B0E0CA5928@apple.com> References: <Pine.LNX.4.64.1307091607110.24681@ps20323.dreamhostps.com> <CAA4WUYgXuL0Qcw0+3K53mm64i=o_qfVCMtvXMEyao5O83z7vsw@mail.gmail.com> <86A0181F-5695-4801-9254-D2B0E0CA5928@apple.com> Message-ID: <CAA4WUYj-v4TKyFFUoq7mpmrccKoM6Ar2cq1+1vGdDAeu8tYzVw@mail.gmail.com> On Sep 3, 2013 8:00 PM, "Ryosuke Niwa" <rniwa at apple.com> wrote: > > On Sep 3, 2013, at 5:01 PM, William Chan (???) <willchan at chromium.org> wrote: > > > Hello folks. Sorry for the late response to several comments in this > > mega-thread, I've mostly been traveling/vacationing for the past 2 months. > > A teammate asked me to look at this in case I had comments. I don't know > > web dev issues very well, so I'm going to restrain myself from offering > > many opinions about the new proposals other than wow, all this dependency > > stuff looks complicated, but maybe it's worth it? I'll keep to some > > observations from a networking performance perspective, in case it's > > relevant to the discussion: > > > > * Any advantages the preloader currently gives is probably only going to be > > magnified with HTTP/2. Browsers today will in key situations hold back > > lower priority resource loads, even after the resource has been discovered > > by the parser/preloader, in order to reduce network contention and > > prioritize resources. But with HTTP/2, the browser almost never has to do > > this since it can express the request priority in the HTTP/2 protocol > > itself, and let the server order responses appropriately. > > * <link rel=subresource> is great for resource discovery. Given the above > > observation, note that it has some deficiencies. Most obviously, it does > > not indicate the resource type. Browsers today can heuristically assign a > > priority based on the resource type (script/image/stylesheet/etc). > > Arguably, browsers could just use the filename extension as a hint to the > > resource type, and that'd get us most of the way there. In any case, > > Chromium, when it encounters <link rel=subresource> is going to assign the > > resource load the lowest priority level, and only when the parser > > encounters the actual resource via a <script> tag or something, will > > another resource load be issued with the "appropriate" priority. Almost all > > modern browsers will hold back low priority resource loads before first > > paint in order to get critical scripts and stylesheets in <head> ASAP > > without contention. Anything marked with <link rel=subresource> will be > > considered low priority and in all likelihood not requested early. Note > > that HTTP/2 currently does not support re-prioritization (and that feature > > is being debated), so that means that when the resource load for <link > > rel=subresource> gets issued over an HTTP/2 connection, it will have the > > lowest priority, which is probably undesirable. FWIW, I think <link > > rel=subresource> was a good initial start, but suffers from key weaknesses > > and should be thrown out and replaced. > > * Given current browser heuristics for resource prioritization based on > > resource type, all <script> resources will have the same priority. Within > > HTTP/1.X, that means you'll get some amount of parallelization based on the > > connection per host limit and what origins the script resources are hosted, > > and then get FIFO. New additions like lazyload attributes (and perhaps > > leveraging the defer attribute) may affect this. With HTTP/2, there is a > > very high (effectively infinite) parallelization limit. With > > prioritization, there's no contention across priority levels. But since > > script resources today generally all have the same priority, they will all > > contend and most naive servers are going to round robin the response bytes, > > which is the worst thing you could do with script resources, since current > > JS VMs do not incrementally process script resources, but process them as a > > whole. So round-robining all the response bytes will just push out start > > time of JS processing for all scripts, which is rather terrible. > > * Obviously, given what I've said above, some level of hinting of > > prioritization/dependency amongst scripts/resources within the web platform > > would be useful to the networking layer since the networking layer can much > > more effectively prioritize resources and thus mitigate network contention. > > If finer grained priority/dependency information isn't provided in the web > > platform, my browser's networking stack is likely going to have to, even > > with HTTP/2, do HTTP/1.X style contention mitigation by restricting > > parallelization within a priority level. Which is a shame since web > > developers probably think that with HTTP/2, they can have as many fine > > grained resources as they want. > > Why don't we simply add "priority" content attribute to link element then? > > <link rel=subresource href="high-priority-resource.js" priority="high"> > <link rel=subresource href="low-priority-resource.js" priority="low"> Sorry Ryosuke, I had too much scotch and can't think through your other use case. This specific proposal is a no go from my perspective though because many pages have components from different authors. I trust a single author to use the appropriate relative priority for all the resources he/she controls. Your proposal seems to imply absolute priorities, which I think is a mistake. I don't want a third party ads widget to have high priority even if they request it. I don't mind giving third parties the ability to "nice" the priority of their resource loads. This is why demoting priority based on defer/a sync/lazyload seems reasonable to me. PS: relative values work fine within defined contexts. I think iframes and web components may be appropriate contextual boundaries. > > > But can we modify these priorities dynamically? I have one specific use case that requires this. > > Use case D: > A web page wants to load and execute a script widget.js if the script is already cached in the browser. However, it wants to load other essential assets such as images first if it's not already in the cache except as long as the user had not started interacting with the parts of the page that require widget.js. > > i.e. it (loads and) executes the script immediately when and only when the script had already been cached or the user had started interacting with the parts of the page that requires the script. Otherwise, the script is loaded with a low priority. > > - R. Niwa > From annevk at annevk.nl Wed Sep 4 04:36:15 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Wed, 4 Sep 2013 12:36:15 +0100 Subject: [whatwg] Encoding: lone surrogates and utf-8, utf-16be, and utf-16le encoders Message-ID: <CADnb78h1uDpShv=JFEbX9hh=A47vr6_5=qeTbyWuKOstmG9RJA@mail.gmail.com> The way the utf-8, utf-16be, and utf-16le encoders are written is that they accept code points (not code units). If the code points are in the surrogate range, they raise an error. That seems problematic. Encoders for utf-8 and utf-16be, and utf-16le are assumed to be safe, because you typically forget about lone surrogates. The API deals with this by having the [EnsureUTF16] flag which converts lone surrogates into U+FFFD. So by the time code points hit the encoder they're no longer in the lone surrogate range. Gecko however has not implemented this for utf-16be and utf-16be, but has for utf-8. (Or maybe the utf-8 encoder is better.) For now I'll assume this is a bug in Gecko. I can see several options for potentially improving this setup, but I need some feedback before going there: 1. Require Unicode scalar value input for encoders, and guarantee it as decoder output. 2. Change the utf-8, utf-16be, and utf-16le encoders to emit the byte sequence for U+FFFD rather than raise an error for input in the lone surrogate range. This would simplify the API and other callers to the utf-8, utf-16be, and utf-16le encoders as they no longer need to worry about them terminating with failure. 3. Move towards defining the entire platform in terms of 16-bit code units and forget about the nicer theoretical model of Unicode scalar values. -- http://annevankesteren.nl/ From jackalmage at gmail.com Wed Sep 4 11:38:44 2013 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Wed, 4 Sep 2013 11:38:44 -0700 Subject: [whatwg] Encoding: lone surrogates and utf-8, utf-16be, and utf-16le encoders In-Reply-To: <CADnb78h1uDpShv=JFEbX9hh=A47vr6_5=qeTbyWuKOstmG9RJA@mail.gmail.com> References: <CADnb78h1uDpShv=JFEbX9hh=A47vr6_5=qeTbyWuKOstmG9RJA@mail.gmail.com> Message-ID: <CAAWBYDBHrPqOCCde4ALGbW+Hf27-JN8pQ9rR1YiY4A5mx8yVGQ@mail.gmail.com> On Wed, Sep 4, 2013 at 4:36 AM, Anne van Kesteren <annevk at annevk.nl> wrote: > The way the utf-8, utf-16be, and utf-16le encoders are written is that > they accept code points (not code units). If the code points are in > the surrogate range, they raise an error. > > That seems problematic. Encoders for utf-8 and utf-16be, and utf-16le > are assumed to be safe, because you typically forget about lone > surrogates. > > The API deals with this by having the [EnsureUTF16] flag which > converts lone surrogates into U+FFFD. So by the time code points hit > the encoder they're no longer in the lone surrogate range. > > Gecko however has not implemented this for utf-16be and utf-16be, but > has for utf-8. (Or maybe the utf-8 encoder is better.) For now I'll > assume this is a bug in Gecko. > > > I can see several options for potentially improving this setup, but I > need some feedback before going there: > > 1. Require Unicode scalar value input for encoders, and guarantee it > as decoder output. > 2. Change the utf-8, utf-16be, and utf-16le encoders to emit the byte > sequence for U+FFFD rather than raise an error for input in the lone > surrogate range. This would simplify the API and other callers to the > utf-8, utf-16be, and utf-16le encoders as they no longer need to worry > about them terminating with failure. > 3. Move towards defining the entire platform in terms of 16-bit code > units and forget about the nicer theoretical model of Unicode scalar > values. I prefer option 2 - CSS is now defined to do the same thing when parsed (nulls, lone surrogates, and out-of-range codepoints are all converted to u+fffd). ~TJ From rniwa at apple.com Wed Sep 4 11:55:16 2013 From: rniwa at apple.com (Ryosuke Niwa) Date: Wed, 04 Sep 2013 11:55:16 -0700 Subject: [whatwg] Prioritizing subresources (Was Script preloading) In-Reply-To: <CAA4WUYj-v4TKyFFUoq7mpmrccKoM6Ar2cq1+1vGdDAeu8tYzVw@mail.gmail.com> References: <Pine.LNX.4.64.1307091607110.24681@ps20323.dreamhostps.com> <CAA4WUYgXuL0Qcw0+3K53mm64i=o_qfVCMtvXMEyao5O83z7vsw@mail.gmail.com> <86A0181F-5695-4801-9254-D2B0E0CA5928@apple.com> <CAA4WUYj-v4TKyFFUoq7mpmrccKoM6Ar2cq1+1vGdDAeu8tYzVw@mail.gmail.com> Message-ID: <12313853-5734-43E9-8C6C-B84E98BA7917@apple.com> On Sep 3, 2013, at 11:06 PM, William Chan (???) <willchan at chromium.org> wrote: > On Sep 3, 2013 8:00 PM, "Ryosuke Niwa" <rniwa at apple.com> wrote: > > > > On Sep 3, 2013, at 5:01 PM, William Chan (???) <willchan at chromium.org> wrote: > > > > > Hello folks. Sorry for the late response to several comments in this > > > mega-thread, I've mostly been traveling/vacationing for the past 2 months. > > > A teammate asked me to look at this in case I had comments. I don't know > > > web dev issues very well, so I'm going to restrain myself from offering > > > many opinions about the new proposals other than wow, all this dependency > > > stuff looks complicated, but maybe it's worth it? I'll keep to some > > > observations from a networking performance perspective, in case it's > > > relevant to the discussion: > > > > > > * Any advantages the preloader currently gives is probably only going to be > > > magnified with HTTP/2. Browsers today will in key situations hold back > > > lower priority resource loads, even after the resource has been discovered > > > by the parser/preloader, in order to reduce network contention and > > > prioritize resources. But with HTTP/2, the browser almost never has to do > > > this since it can express the request priority in the HTTP/2 protocol > > > itself, and let the server order responses appropriately. > > > * <link rel=subresource> is great for resource discovery. Given the above > > > observation, note that it has some deficiencies. Most obviously, it does > > > not indicate the resource type. Browsers today can heuristically assign a > > > priority based on the resource type (script/image/stylesheet/etc). > > > Arguably, browsers could just use the filename extension as a hint to the > > > resource type, and that'd get us most of the way there. In any case, > > > Chromium, when it encounters <link rel=subresource> is going to assign the > > > resource load the lowest priority level, and only when the parser > > > encounters the actual resource via a <script> tag or something, will > > > another resource load be issued with the "appropriate" priority. Almost all > > > modern browsers will hold back low priority resource loads before first > > > paint in order to get critical scripts and stylesheets in <head> ASAP > > > without contention. Anything marked with <link rel=subresource> will be > > > considered low priority and in all likelihood not requested early. Note > > > that HTTP/2 currently does not support re-prioritization (and that feature > > > is being debated), so that means that when the resource load for <link > > > rel=subresource> gets issued over an HTTP/2 connection, it will have the > > > lowest priority, which is probably undesirable. FWIW, I think <link > > > rel=subresource> was a good initial start, but suffers from key weaknesses > > > and should be thrown out and replaced. > > > * Given current browser heuristics for resource prioritization based on > > > resource type, all <script> resources will have the same priority. Within > > > HTTP/1.X, that means you'll get some amount of parallelization based on the > > > connection per host limit and what origins the script resources are hosted, > > > and then get FIFO. New additions like lazyload attributes (and perhaps > > > leveraging the defer attribute) may affect this. With HTTP/2, there is a > > > very high (effectively infinite) parallelization limit. With > > > prioritization, there's no contention across priority levels. But since > > > script resources today generally all have the same priority, they will all > > > contend and most naive servers are going to round robin the response bytes, > > > which is the worst thing you could do with script resources, since current > > > JS VMs do not incrementally process script resources, but process them as a > > > whole. So round-robining all the response bytes will just push out start > > > time of JS processing for all scripts, which is rather terrible. > > > * Obviously, given what I've said above, some level of hinting of > > > prioritization/dependency amongst scripts/resources within the web platform > > > would be useful to the networking layer since the networking layer can much > > > more effectively prioritize resources and thus mitigate network contention. > > > If finer grained priority/dependency information isn't provided in the web > > > platform, my browser's networking stack is likely going to have to, even > > > with HTTP/2, do HTTP/1.X style contention mitigation by restricting > > > parallelization within a priority level. Which is a shame since web > > > developers probably think that with HTTP/2, they can have as many fine > > > grained resources as they want. > > > > Why don't we simply add "priority" content attribute to link element then? > > > > <link rel=subresource href="high-priority-resource.js" priority="high"> > > <link rel=subresource href="low-priority-resource.js" priority="low"> > > Sorry Ryosuke, I had too much scotch and can't think through your other use case. This specific proposal is a no go from my perspective though because many pages have components from different authors. I trust a single author to use the appropriate relative priority for all the resources he/she controls. Your proposal seems to imply absolute priorities, which I think is a mistake. I don't want a third party ads widget to have high priority even if they request it. > If we're doing this, then priority needs to be relative per origin or per document so that you can't sabotage other websites or be sabotaged by thirdparty ads as you suggested. e.g. If all resources on a page has the priority "high", then it should behave as if all of them have the medium priority. > I don't mind giving third parties the ability to "nice" the priority of their resource loads. This is why demoting priority based on defer/a sync/lazyload seems reasonable to me. > Let me think about this more. - R. Niwa From oliver at apple.com Wed Sep 4 11:56:32 2013 From: oliver at apple.com (Oliver Hunt) Date: Wed, 04 Sep 2013 11:56:32 -0700 Subject: [whatwg] Structured Clone of Map and Set objects Message-ID: <69B3CEC1-06BD-4137-96A2-202BDE590EB9@apple.com> The current structured clone algorithm does not include support for the Map and Set types, so a developer would need to manually implement the serialisation and deserialisation. While this would not be impossible it does seem like it is an unnecessary inconvenience for a core type in ES6. The semantics of Map and Set are stable so unless someone objects i see no reason we should not amend the internal structured clone algorithm to specially handle Set and Map in addition to Array. To support cloning of Map and Set we will want to recursively call the structured clone algorithm on each key or key/value pair in the %SetData% or %MapData% internal arrays, and maintain the order of those entries (as the Map/Set ordering is well defined) --Oliver From annevk at annevk.nl Wed Sep 4 13:12:22 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Wed, 4 Sep 2013 21:12:22 +0100 Subject: [whatwg] Structured Clone of Map and Set objects In-Reply-To: <69B3CEC1-06BD-4137-96A2-202BDE590EB9@apple.com> References: <69B3CEC1-06BD-4137-96A2-202BDE590EB9@apple.com> Message-ID: <CADnb78gb0MTfFZ9C6Djcd61RG1M4Ur+MjRRprFZp4ntkCNrVnw@mail.gmail.com> On Wed, Sep 4, 2013 at 7:56 PM, Oliver Hunt <oliver at apple.com> wrote: > The current structured clone algorithm does not include support for the Map and Set types, so a developer would need to manually implement the serialisation and deserialisation. While this would not be impossible it does seem like it is an unnecessary inconvenience for a core type in ES6. I suggested this to TC39 a while back and I still think it's a good idea even though reception was lukewarm at best (the people replying didn't like to acknowledge the existence of this seemed like). They should define this as a primitive of the Object type and define which objects support it and how. The monkey patching we do now is not great. -- http://annevankesteren.nl/ From ian at hixie.ch Wed Sep 4 15:25:41 2013 From: ian at hixie.ch (Ian Hickson) Date: Wed, 4 Sep 2013 22:25:41 +0000 (UTC) Subject: [whatwg] Cross-Origin Cookies Sharing Proposal In-Reply-To: <9F8CE942-199E-4C01-A43C-7BA7C577BC01@gmail.com> References: <CAMBN-K4y891dJcAngvw0sBgPrpC0NFGGCuq0cL17=wrn+UB1oQ@mail.gmail.com> <20130621191948.71e3bbb9@desudesudesu> <CAMBN-K6sPJkxdc-EjTKDvX9ioBn5MDO0umtGUiDpKTHBuOetcw@mail.gmail.com> <CAE-+aYLCqeGJYL7JRs5-zXGg0jKG1hi14oeq2_dchb6788Lrmg@mail.gmail.com> <CAMBN-K5DMOQ5OYVq_hZ=ozjHCXu9gF3YE0nU=MNyQw+zDK6tjg@mail.gmail.com> <CAE-+aYKUSVz5inGQEvHtC3DfX6fS_ehAVor_9+MdG4cxp5YF4A@mail.gmail.com> <9F8CE942-199E-4C01-A43C-7BA7C577BC01@gmail.com> Message-ID: <alpine.DEB.2.00.1309041932060.7443@ps20323.dreamhostps.com> On Fri, 21 Jun 2013, Huan Du wrote: > > As privacy awareness becomes prevelant, the trend is that future > browsers are going to ban third-party Cookies by default. > > This is a good thing for users, but for giant internet companies, this > has no doubt increases the difficult and complexity of implementing user > session synchronization. > > Is it possible to, like Cross-Origin Resource Sharing, allow a site to > indicate which domains it would like to share Cookies with? Why would a user be ok with sharing cookies with these sites if they're not ok with sharing them otherwise? I don't really understand what the user threat model is here. On Fri, 21 Jun 2013, Nils Dagsson Moskopp wrote: > > I have a suspicion that the only thing that cannot be done easily > without cookies is tracking ? that is, pretending that a user has an > account, but ensuring that she has not made that choice consciously. That's pretty easy to do even without cookies or other storage mechanisms. You can fingerprint a user pretty precisely. On Sat, 22 Jun 2013, Huan Du wrote: > > There are 3 web sites in Alibaba at least: taobao.com, tmall.com, > etao.com. all of them are using a same account management system > including Sign up, Sign in. > > The requirement is simple for the account management system. when user A > signed in taobao.com, we expect A is signed in tmall.com and etao.com. Right. There are lots of cases such as this where third-party cookies (or a similar mechanism) are an integral part of the experience. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Sep 4 16:22:43 2013 From: ian at hixie.ch (Ian Hickson) Date: Wed, 4 Sep 2013 23:22:43 +0000 (UTC) Subject: [whatwg] Default draggable elements In-Reply-To: <CAF3XrKomVOe5tTuT6UheP8CwYNH9J+s4WQ7SW9ru+4Ta=39-Aw@mail.gmail.com> References: <CAF3XrKomVOe5tTuT6UheP8CwYNH9J+s4WQ7SW9ru+4Ta=39-Aw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309042322080.7443@ps20323.dreamhostps.com> On Thu, 11 Jul 2013, Daniel Cheng wrote: > Regarding elements that are draggable by default: > The spec says: > > img elements and a elements with an href attribute have their > > draggable attribute set to true by default. > > I've noticed that in IE and Firefox, an <object> tag embedding an image > also defaults to draggable. It does not default to draggable in > Blink/WebKit. Should the spec be amended to include this special case? Seems reasonable. Done. > Blink/WebKit also make input[image] elements default to draggable (no > other browser does this). I'm not really sure why, but can I confirm > that this won't be in the spec? I'd like to remove it from Blink at > least. Yeah, that seems bad since it's an interactive widget. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From dino at apple.com Wed Sep 4 16:50:10 2013 From: dino at apple.com (Dean Jackson) Date: Thu, 05 Sep 2013 09:50:10 +1000 Subject: [whatwg] Challenging canvas.supportsContext In-Reply-To: <52268308.1090802@mit.edu> References: <CAJTmd9rkwsjC+WDfLr7um0=h8Pvtg9JOJCRHzH4PhdbXjgpaaA@mail.gmail.com> <CAJTmd9q-eH8fnZSP5mr3kX-quyQcNXnyXTh5o_hX+MdfuXfrGQ@mail.gmail.com> <alpine.DEB.2.00.1309032240300.7443@ps20323.dreamhostps.com> <52268308.1090802@mit.edu> Message-ID: <D3D8AD28-A2F0-4A90-A156-42871ADD4FE4@apple.com> On 4 Sep 2013, at 10:47 am, Boris Zbarsky <bzbarsky at mit.edu> wrote: > On 9/3/13 7:13 PM, Ian Hickson wrote: >> Wouldn't checking for window.WebGLRenderingContext be just as unreliable >> then? I don't understand why it's ok to be able to test that, but why >> probablySupportsContext() wouldn't be ok. > > I'm a lot more OK with the "probablySupportsContext" naming than "supportsContext" here. I will update WebKit to probablySupportsContext asap. Dean From ian at hixie.ch Wed Sep 4 17:03:52 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 5 Sep 2013 00:03:52 +0000 (UTC) Subject: [whatwg] scrdoc and session history don't play along in the spec In-Reply-To: <51E0627C.9070705@mit.edu> References: <515EF14C.4070102@mit.edu> <CAJE5ia-WtbpbhvvuWixzah+YDdY-s_-c3kHG_pVe8J5bZa2YgQ@mail.gmail.com> <51C6FB2A.1010304@mit.edu> <CAJE5ia9WnYAZKjvmfh3KbcHN_xYKfmtfxuWQP-sYebxzTePwrQ@mail.gmail.com> <51C72C0C.5000605@mit.edu> <alpine.DEB.2.00.1307121914050.15729@ps20323.dreamhostps.com> <51E0627C.9070705@mit.edu> Message-ID: <alpine.DEB.2.00.1309042338120.7443@ps20323.dreamhostps.com> On Fri, 12 Jul 2013, Boris Zbarsky wrote: > On 7/12/13 3:39 PM, Ian Hickson wrote: > > That wasn't the intent. I've tried to clarify it. > > Hmm. It might help to make it clearer in > http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate > that "new resource" does not mean "URL". Maybe have some explicit thing > that represents the resource being navigated to (which might, for > example, consist of a (url, srcdoc data) pair or something along those > lines)? Yeah... I've thought about doing something like this several times (this is by far not the only part of the spec with this issue -- the word "resource" is in the spec over a thousand times). Fundamentally I'm not really sure what to do to define "resource" in a useful way here and elsewhere. I've added a note before the navigation algorithm, though. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Sep 4 17:07:43 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 5 Sep 2013 00:07:43 +0000 (UTC) Subject: [whatwg] Alignment of empty buttons In-Reply-To: <51E06313.8030105@mit.edu> References: <CAPTJ0XEA_NMAB41UHg1cXXmQTRsxg2zhd9LCuSS2b6R2ZBSVig@mail.gmail.com> <CAPTJ0XE1337+UqNC4D9gpuWO6QHQ7gHc+x8y08SYjCJmghzEag@mail.gmail.com> <51846106.2060403@mit.edu> <alpine.DEB.2.00.1307122007550.15729@ps20323.dreamhostps.com> <51E06313.8030105@mit.edu> Message-ID: <alpine.DEB.2.00.1309050004230.7443@ps20323.dreamhostps.com> On Fri, 12 Jul 2013, Boris Zbarsky wrote: > On 7/12/13 4:08 PM, Ian Hickson wrote: > > The HTML spec is pretty explicit about it not being: > > > > # When the button binding applies to a button element, the element is > > # expected to render as an 'inline-block' box rendered as a button whose > > # contents are the contents of the element. > > -- http://www.whatwg.org/specs/web-apps/current-work/#the-button-element-0 > > Hmm. Is that compatible with the sizing of absolutely positioned > buttons with "left:0; right: 0"? > > For that matter, what happens to buttons if their display style is > changed (e.g. to block)? As far as I can tell, browsers keep treating it as an inline-block box in those cases. Do you have a specific case in mind that isn't handled that way? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From bzbarsky at MIT.EDU Wed Sep 4 22:20:45 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Thu, 05 Sep 2013 01:20:45 -0400 Subject: [whatwg] Alignment of empty buttons In-Reply-To: <alpine.DEB.2.00.1309050004230.7443@ps20323.dreamhostps.com> References: <CAPTJ0XEA_NMAB41UHg1cXXmQTRsxg2zhd9LCuSS2b6R2ZBSVig@mail.gmail.com> <CAPTJ0XE1337+UqNC4D9gpuWO6QHQ7gHc+x8y08SYjCJmghzEag@mail.gmail.com> <51846106.2060403@mit.edu> <alpine.DEB.2.00.1307122007550.15729@ps20323.dreamhostps.com> <51E06313.8030105@mit.edu> <alpine.DEB.2.00.1309050004230.7443@ps20323.dreamhostps.com> Message-ID: <522814AD.8000901@mit.edu> On 9/4/13 8:07 PM, Ian Hickson wrote: > As far as I can tell, browsers keep treating it as an inline-block box in > those cases. OK, that works, I guess. That does mean that buttons are a replaced element, clearly, though... Something needs to spell that out. -Boris From slightlyoff at google.com Wed Sep 4 23:18:27 2013 From: slightlyoff at google.com (Alex Russell) Date: Wed, 4 Sep 2013 23:18:27 -0700 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: <CA+c2ei9yR7mqkHBSBXdcY9THP3zpSRfGUFwY-Oh8kBOP_y487Q@mail.gmail.com> References: <CADnb78jksF5RdfPK4Brcib=N-jYcf0YrO=o=fFz4ZLUqTgLUMg@mail.gmail.com> <521E1168.2040506@mit.edu> <CA+c2ei9yR7mqkHBSBXdcY9THP3zpSRfGUFwY-Oh8kBOP_y487Q@mail.gmail.com> Message-ID: <CANr5HFXoWf3VVB0XzTbZzmC=A9isHoVo3CAUSPLdeC=z+eqJqA@mail.gmail.com> On Wed, Aug 28, 2013 at 9:20 AM, Jonas Sicking <jonas at sicking.cc> wrote: > On Wed, Aug 28, 2013 at 8:04 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote: > > On 8/28/13 9:32 AM, Anne van Kesteren wrote: > >> > >> I'm not sure we need to consider sub-scheme if zip-path can work as > >> it's more complex and not very well thought out. E.g. imagine > >> view-source:zip:http://www.example.org/zip!test.html. > > > > > > What's the issue with that? Gecko supports that (with jar:, not zip:), > > fwiw. > > I have two concerns with the scheme-based approach. > > * It dramatically complicates origin handling. This is something we've > seen multiple times in gecko and something that I expect authors will > struggle with too. > > * It makes it impossible to have create a relative URL from inside the > zip file to refer to something on the same server but outside of the > zip file. Since anything outside of the zip file uses a different > scheme, it means that you have to use an absolute URL. Not even URLs > starting with "/" nor "//" can be used. Apologies for being late to the thread. Just wanted to agree with both of these points. This only seems valuable to me if we can do it in the context of http(s)://. > > 3) We have implementation experience with the "sub-scheme" approach and > we > > know it can work just fine (existence proof is jar: in Gecko). The main > > difficulty it introduces is that computing the origin needs to be done > via > > object accessors, not string-parsing... Do we have any implementation > > experience with "zip-path"-like approaches? > > I don't know about "can work just fine". Sure, if everyone does the > right thing, then it works. But we're having to strictly enforce that > no one does string parsing by hand and instead use URL objects and > Principal objects. Neither of which really are an option on the web > right now as all URL-related APIs use strings. > > > I don't think relative URIs should ever escape a zip archive (though I do > > appreciate the way that would let someone replace directories with > zipped-up > > versions of those directories). The reason for that is that allowing it > > sometimes but not others seems really weird to me, and it seems like we > > don't want to allow it for toplevel zip archives. > > Why not? > > / Jonas > From annevk at annevk.nl Thu Sep 5 01:26:10 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Thu, 5 Sep 2013 09:26:10 +0100 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: <CANr5HFXoWf3VVB0XzTbZzmC=A9isHoVo3CAUSPLdeC=z+eqJqA@mail.gmail.com> References: <CADnb78jksF5RdfPK4Brcib=N-jYcf0YrO=o=fFz4ZLUqTgLUMg@mail.gmail.com> <521E1168.2040506@mit.edu> <CA+c2ei9yR7mqkHBSBXdcY9THP3zpSRfGUFwY-Oh8kBOP_y487Q@mail.gmail.com> <CANr5HFXoWf3VVB0XzTbZzmC=A9isHoVo3CAUSPLdeC=z+eqJqA@mail.gmail.com> Message-ID: <CADnb78gxm0CdHrL8itKKug0Ovk5+MjSsRZfWyhqybcRZ9V_+nQ@mail.gmail.com> On Thu, Sep 5, 2013 at 7:18 AM, Alex Russell <slightlyoff at google.com> wrote: > On Wed, Aug 28, 2013 at 9:20 AM, Jonas Sicking <jonas at sicking.cc> wrote: >> I have two concerns with the scheme-based approach. >> >> * It dramatically complicates origin handling. This is something we've >> seen multiple times in gecko and something that I expect authors will >> struggle with too. >> >> * It makes it impossible to have create a relative URL from inside the >> zip file to refer to something on the same server but outside of the >> zip file. Since anything outside of the zip file uses a different >> scheme, it means that you have to use an absolute URL. Not even URLs >> starting with "/" nor "//" can be used. > > Apologies for being late to the thread. Just wanted to agree with both of > these points. This only seems valuable to me if we can do it in the context > of http(s)://. I don't see how that relates to the points. The sub-scheme approach still works with HTTP. Origin handling would be more complicated. Anyway, unless someone volunteers I'll write up a comparison of the various approaches in due course. Meanwhile, I'd still be very much interested in hearing implementer interest as without multi-vendor buy-in this whole exercise is futile. Mozillians appears in favor. Googlers appear somewhat reluctant, and everyone else is silent. -- http://annevankesteren.nl/ From annevk at annevk.nl Thu Sep 5 03:02:38 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Thu, 5 Sep 2013 11:02:38 +0100 Subject: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments In-Reply-To: <20130628201946.26920@gmx.com> References: <20130628201946.26920@gmx.com> Message-ID: <CADnb78jxE5B2KTYXj0QBv0GSoGddb=Gbxym5Cp5tYxm7zMG1aA@mail.gmail.com> On Fri, Jun 28, 2013 at 9:19 PM, Zirak A <zirak at mail.com> wrote: > Currently, a DocumentFragment only inherits from Node, and thus loses methods like getElementById. However, the Selector API (http://www.w3.org/TR/selectors-api/) defines querySelector and querySelectorAll on document fragments. > My proposal is to add getElementById (which makes sense, as the document fragment is a root node), getElementsByTagName (and its namespace-sensitive version), getElementsByClassName and getElementsByName - in short, all of the general selection methods available on the Document. Per http://dom.spec.whatwg.org/ this is the wrong forum for DOM. Having said that, our current plan is to rely on the Selectors API (2) and slowly move away from getElement* friends over time, as their return values are less than optimal. getElementById is an exception to this, but the hope is that .querySelector("#test") will be fast enough. If it turns out to be a problem, we should re-evaluate at that point. Concrete suggestions for new traversal APIs should be discussed on www-dom at w3.org or the DOM bug database until we decide the more appropriate forum is here, it'd be unfair to the existing community otherwise. If you think I should reply to any of the remainder of this thread please let me know, but I hope this general answer is sufficient. -- http://annevankesteren.nl/ From slightlyoff at google.com Thu Sep 5 08:02:26 2013 From: slightlyoff at google.com (Alex Russell) Date: Thu, 5 Sep 2013 08:02:26 -0700 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: <CADnb78gxm0CdHrL8itKKug0Ovk5+MjSsRZfWyhqybcRZ9V_+nQ@mail.gmail.com> References: <CADnb78jksF5RdfPK4Brcib=N-jYcf0YrO=o=fFz4ZLUqTgLUMg@mail.gmail.com> <521E1168.2040506@mit.edu> <CA+c2ei9yR7mqkHBSBXdcY9THP3zpSRfGUFwY-Oh8kBOP_y487Q@mail.gmail.com> <CANr5HFXoWf3VVB0XzTbZzmC=A9isHoVo3CAUSPLdeC=z+eqJqA@mail.gmail.com> <CADnb78gxm0CdHrL8itKKug0Ovk5+MjSsRZfWyhqybcRZ9V_+nQ@mail.gmail.com> Message-ID: <CANr5HFW5x9vHDSMnyHR4ob=E4MQRUhAKkRuBowf8wGJFy+LgZA@mail.gmail.com> I can't speak for all of Google, but I'm in favour. On 5 Sep 2013 01:26, "Anne van Kesteren" <annevk at annevk.nl> wrote: > On Thu, Sep 5, 2013 at 7:18 AM, Alex Russell <slightlyoff at google.com> > wrote: > > On Wed, Aug 28, 2013 at 9:20 AM, Jonas Sicking <jonas at sicking.cc> wrote: > >> I have two concerns with the scheme-based approach. > >> > >> * It dramatically complicates origin handling. This is something we've > >> seen multiple times in gecko and something that I expect authors will > >> struggle with too. > >> > >> * It makes it impossible to have create a relative URL from inside the > >> zip file to refer to something on the same server but outside of the > >> zip file. Since anything outside of the zip file uses a different > >> scheme, it means that you have to use an absolute URL. Not even URLs > >> starting with "/" nor "//" can be used. > > > > Apologies for being late to the thread. Just wanted to agree with both of > > these points. This only seems valuable to me if we can do it in the > context > > of http(s)://. > > I don't see how that relates to the points. The sub-scheme approach > still works with HTTP. Origin handling would be more complicated. > > Anyway, unless someone volunteers I'll write up a comparison of the > various approaches in due course. Meanwhile, I'd still be very much > interested in hearing implementer interest as without multi-vendor > buy-in this whole exercise is futile. Mozillians appears in favor. > Googlers appear somewhat reluctant, and everyone else is silent. > > > -- > http://annevankesteren.nl/ > From ian at hixie.ch Thu Sep 5 13:47:12 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 5 Sep 2013 20:47:12 +0000 (UTC) Subject: [whatwg] Alignment of empty buttons In-Reply-To: <522814AD.8000901@mit.edu> References: <CAPTJ0XEA_NMAB41UHg1cXXmQTRsxg2zhd9LCuSS2b6R2ZBSVig@mail.gmail.com> <CAPTJ0XE1337+UqNC4D9gpuWO6QHQ7gHc+x8y08SYjCJmghzEag@mail.gmail.com> <51846106.2060403@mit.edu> <alpine.DEB.2.00.1307122007550.15729@ps20323.dreamhostps.com> <51E06313.8030105@mit.edu> <alpine.DEB.2.00.1309050004230.7443@ps20323.dreamhostps.com> <522814AD.8000901@mit.edu> Message-ID: <alpine.DEB.2.00.1309052044160.22377@ps20323.dreamhostps.com> On Thu, 5 Sep 2013, Boris Zbarsky wrote: > On 9/4/13 8:07 PM, Ian Hickson wrote: > > As far as I can tell, browsers keep treating it as an inline-block box > > in those cases. > > OK, that works, I guess. That does mean that buttons are a replaced > element, clearly, though... Something needs to spell that out. In what sense? The definition of "replaced element" here: http://www.w3.org/TR/CSS2/conform.html#replaced-element ...doesn't seem to apply to <button>. The rendering of <button> is very much in CSS' scope, no? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jackalmage at gmail.com Thu Sep 5 13:52:19 2013 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Thu, 5 Sep 2013 13:52:19 -0700 Subject: [whatwg] Alignment of empty buttons In-Reply-To: <alpine.DEB.2.00.1309052044160.22377@ps20323.dreamhostps.com> References: <CAPTJ0XEA_NMAB41UHg1cXXmQTRsxg2zhd9LCuSS2b6R2ZBSVig@mail.gmail.com> <CAPTJ0XE1337+UqNC4D9gpuWO6QHQ7gHc+x8y08SYjCJmghzEag@mail.gmail.com> <51846106.2060403@mit.edu> <alpine.DEB.2.00.1307122007550.15729@ps20323.dreamhostps.com> <51E06313.8030105@mit.edu> <alpine.DEB.2.00.1309050004230.7443@ps20323.dreamhostps.com> <522814AD.8000901@mit.edu> <alpine.DEB.2.00.1309052044160.22377@ps20323.dreamhostps.com> Message-ID: <CAAWBYDDSFKb4W6pU6KKNc5Po6X0d=Fj3G0Vji5wDe7UmmcA+tw@mail.gmail.com> On Thu, Sep 5, 2013 at 1:47 PM, Ian Hickson <ian at hixie.ch> wrote: > On Thu, 5 Sep 2013, Boris Zbarsky wrote: >> On 9/4/13 8:07 PM, Ian Hickson wrote: >> > As far as I can tell, browsers keep treating it as an inline-block box >> > in those cases. >> >> OK, that works, I guess. That does mean that buttons are a replaced >> element, clearly, though... Something needs to spell that out. > > In what sense? > > The definition of "replaced element" here: > > http://www.w3.org/TR/CSS2/conform.html#replaced-element > > ...doesn't seem to apply to <button>. The rendering of <button> is very > much in CSS' scope, no? Technically, no, buttons are still replaced elements. In practice, buttons are pretty much stock CSS elements across all user agents, and we should probably standardize that. ~TJ From ian at hixie.ch Thu Sep 5 13:59:45 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 5 Sep 2013 20:59:45 +0000 (UTC) Subject: [whatwg] Adding 2D Canvas features In-Reply-To: <CAK-G-KVLsECC4cETFYdcPyoqigaaoRhUxcezhMG3jZc2fAViRg@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <51D12692.4030002@artspark.co.jp> <CAK-G-KVLsECC4cETFYdcPyoqigaaoRhUxcezhMG3jZc2fAViRg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309052049070.7443@ps20323.dreamhostps.com> On Fri, 28 Jun 2013, Tom Wiltzius wrote: > > The only major Canvas2D features being actively developed in Chromium > right now are: > > - having a canvas context "alpha" attribute > - text decoration > - compositing and blending > - canvas access in workers > > (easily referenced from http://www.chromestatus.com/features) > > It is concerning to me that the list of other unimplemented features > that aren't being worked on could block the standardization of the above > (all of which have been discussed on this list at one point, but not all > of which are in the spec yet). > > How can we help reconcile this discrepancy? My goal is for the spec to match the browsers as closely as possible while providing direction for the next set of new features. >From my point of view, therefore, there's two ways to reconcile this discrepancy: either the browsers implement what's in the spec, or the spec changes to drop the things that aren't getting implemented. On Fri, 28 Jun 2013, Benoit Jacob wrote: > > Has the Canvas 2D community considered a WebGL-like model to the > introduction of additional features? > > By "the WebGL model", I mean: > - Define a core feature set that's conservative and limited, but > consistently implemented by all browsers. Enforce consistent support for > it by an exhaustive conformance test suite. That's the model we're trying to follow. > - Let any additional feature be an "extension". The goal is for there to be none of these. > - Consider, similar to WebGL, further tightening this process by letting > any new feature start at "draft" status and wait a bit before being > "approved". That doesn't work. Nobody cares if something is approved or not -- they'll use it if it works and it's what they want. Once people use it, it's not going anywhere, and the spec is de-facto frozen. > Typically, the difference that this makes is that "draft" extensions > would be exposed by browsers only "behind a flag" (a browser option > that's not enabled by default). Prerequisites for "approval" would > include: having been implemented and stable for some time, and being > covered by a conformance test. You can't tell if something is stable until people are using it, so hiding features behind a flag, once their implementation is complete, doesn't help. On Fri, 28 Jun 2013, Rik Cabanier wrote: > > If you can get them into 2 stable browsers, I'm very sure that Ian will add > it to the specification. > It seems that Ian is mostly concerned that we're adding more and more > features to the document but they are not being worked on. This makes the > WHATWG spec less useful since you can't tell what's implemented or not. (It > also makes a lot of useless work for Ian if he has to cut it later.) Precisely. > I think what's needed is that the person who proposes a feature and gets > it accepted on the mailing list, also needs to follow up and coordinate > with the browsers so it actually gets implemented. Certainly a one-browser feature is no good, specced or not. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From foolistbar at googlemail.com Thu Sep 5 15:08:04 2013 From: foolistbar at googlemail.com (Geoffrey Sneddon) Date: Thu, 05 Sep 2013 15:08:04 -0700 Subject: [whatwg] Parse errors for invalid characters Message-ID: <522900C4.2050409@googlemail.com> The phrasing content section states: > Text nodes and attribute values must consist of Unicode characters, must not contain U+0000 characters, must not contain permanently undefined Unicode characters (noncharacters), and must not contain control characters other than space characters. This specification includes extra constraints on the exact value of Text nodes and attribute values depending on their precise context. And the pre-processing the input-stream section states: > Any occurrences of any characters in the ranges U+0001 to U+0008, U+000E to U+001F, U+007F to U+009F, U+FDD0 to U+FDEF, and characters U+000B, U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, U+2FFFE, U+2FFFF, U+3FFFE, U+3FFFF, U+4FFFE, U+4FFFF, U+5FFFE, U+5FFFF, U+6FFFE, U+6FFFF, U+7FFFE, U+7FFFF, U+8FFFE, U+8FFFF, U+9FFFE, U+9FFFF, U+AFFFE, U+AFFFF, U+BFFFE, U+BFFFF, U+CFFFE, U+CFFFF, U+DFFFE, U+DFFFF, U+EFFFE, U+EFFFF, U+FFFFE, U+FFFFF, U+10FFFE, and U+10FFFF are parse errors. These are all control characters or permanently undefined Unicode characters (noncharacters). Note the first uses "Unicode characters", the second "characters" ? the former excludes surrogates as a conformance requirement. Note that every disallowed non-surrogate character is a parse error. Therefore, it would make sense to make surrogates parse errors. It should be noted that they can only occur in the input stream if they come from script (as they cannot be decoded from the input byte stream as the decoders will never emit a surrogate). /Geoffrey. From simon.sarris at gmail.com Thu Sep 5 15:19:30 2013 From: simon.sarris at gmail.com (Simon Sarris) Date: Thu, 5 Sep 2013 18:19:30 -0400 Subject: [whatwg] Adding 2D Canvas features In-Reply-To: <alpine.DEB.2.00.1309052049070.7443@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <51D12692.4030002@artspark.co.jp> <CAK-G-KVLsECC4cETFYdcPyoqigaaoRhUxcezhMG3jZc2fAViRg@mail.gmail.com> <alpine.DEB.2.00.1309052049070.7443@ps20323.dreamhostps.com> Message-ID: <CAA5isUYmMm9sHu=_Ybwmhw7GWfO+vRpP+8MdM_+OXKPCc+i4+Q@mail.gmail.com> Just FYI, Chrome now has a relatively new bug for "Canvas v5 API additions" that references all the missing features that some posters were concerned about. The default take from this bug report is that all of these are greenlighted to be worked on (no objections so far) https://code.google.com/p/chromium/issues/detail?id=281529 This bug is now (as of a few days ago) referenced at chromestatus.com under the Canvas feature's implementation status: http://www.chromestatus.com/features/5100084685438976 Simon From ian at hixie.ch Thu Sep 5 15:22:20 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 5 Sep 2013 22:22:20 +0000 (UTC) Subject: [whatwg] Blurry lines in 2D Canvas In-Reply-To: <CAGN7qDA8fe42MUR-Dt1sxtCnN=hPYLe6TcasSfjV+q+i-UmrjA@mail.gmail.com> References: <CAGN7qDAdABj2NCNcc53qDd23Twq2=999u0Sio-gEsBJURrpCcg@mail.gmail.com> <CAPeKFThd5HvtYFvokX=n7UR_Qs=wmqHy2vMFDoDs9y9Jd5jM=Q@mail.gmail.com> <CAGN7qDCOdadxurg5qp6q3UMygv0gjBNc5BoHOgtZKggD=5ppNQ@mail.gmail.com> <CABirCh_0orFzaZAUrtg3Z+Jg0LdSGMZxuapVdKZgigEdKJJVXQ@mail.gmail.com> <CAGN7qDDbS5Vy65SqiSdVtxgz8W9w+8WO3n=2H4wpSdkaQNLBCQ@mail.gmail.com> <CABirCh-NiwtSMzs5J5=cqazNYGAKufA3s1Lz1cW-6YvhGbt8pg@mail.gmail.com> <CAGN7qDBqXxY-aWmb3kWwxXh=rfD1BfHCEiESs9yHiFkpxkPFig@mail.gmail.com> <CABirCh9RSb0SEMsqy9KHEV77h7s04hgq7G6evCYLFRM10Kh+1A@mail.gmail.com> <CAGN7qDA8fe42MUR-Dt1sxtCnN=hPYLe6TcasSfjV+q+i-UmrjA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309052119410.7443@ps20323.dreamhostps.com> On Tue, 23 Jul 2013, Rik Cabanier wrote: > > we've noticed that if you draw lines in canvas or SVG, they always end > up blurry. For instance see this fiddle: http://jsfiddle.net/V92Gn/128/ Not always, only if you don't draw the line aligned with the pixel grid (e.g. you draw a diagonal line, or a horizontal or vertical line that isn't centered in the middle of pixels on the pixels grid, or a horizontal or vertical line whose width isn't an integral number of pixels, etc). The options, on a pixel grid display, are: - don't honour the position precisely -- this leads to very ugly artifacts when animating (lines jerk around), and basically means that the graphics aren't accurate. - instead of describing the shapes as vectors, describe them using programs that can adapt to the position and size they're being drawn at, such that they automatically snap to the pixel grid in a pretty fashion -- this is what fonts do. - try to trick the eye by using anti-aliasing when things don't line up exactly on the pixel grid. The first two really aren't plausible options for <canvas>. On Wed, 24 Jul 2013, Kornel Lesi?ski wrote: > > For 1-pixel lines it could be fixed by allowing authors to specify that > path should be stroked with lines aligned to inside/outside of the path > (which is a useful feature on its own). https://www.w3.org/Bugs/Public/show_bug.cgi?id=22674 On Tue, 23 Jul 2013, Rik Cabanier wrote: > > Sure, but how can we fix this? What is there to fix? The options above are basically the only options. You can't not do one of them -- there's no way to draw a crisp line that isn't pixel aligned. There's no pixels there. Similarly, there's no way to draw a line that's neither horizontal nor vertical yet is crisp and doesn't look jaggy. The pixels are squares, they don't rotate on modern pixel displays. On Wed, 24 Jul 2013, Kornel Lesi?ski wrote: > > Should arc() and bezier curves also be snapped? What if you want a line > that touches the curve? That's precisely the problem with snapping -- it is far worse than antialiasing. You can't draw precise shapes if you have snapping. On Wed, 24 Jul 2013, Dirk Schulze wrote: > > Means implementations would need to take viewport, transformations of > the document, transformations on elements in the DOM hierarchy, zoom > level, aspect ratio of the canvas, position of the canvas in the > document, transformations in the canvas and device pixel resolution into > account to snap lines to the correct position on the individual device, > right?Otherwise it sounds to be hard to guarantee that you don't see > antialiased strokes and lines might snap more then just one device > pixel. This would also be a problem for aligning shapes to each other in > the canvas I guess. What happens on the next transformation after a > drawing operation. Say you draw a line that was snapped to the grid and > then you do scale(1.1, 1.1). Shall the implementation redraw the canvas? > After all it is an pixel image. A vector based drawing format would be > better suited for such a task. Indeed. On Sat, 10 Aug 2013, Rik Cabanier wrote: > > I was wondering if this is something that happens in Flash as well. It > turns out that there's an option called "hinting: Keep stroke anchors on > full pixels to prevent blurry lines." There's a blog post on what this > does: > http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html > <http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html> > > I created an example (in flash sorry) that shows the feature: > http://cabanier.github.io/BlendExamples/pixelsnap/pixelsnap.html > 2 sets of strokes move across the screen and are also scaled. > > The top strokes behave like canvas does today. They start of blurry and > during the animation they slowly get ticker. For some reason it doesn't > look very smooth. > The bottom strokes have hinting turned on. They are sharp at the beginning > and during the animation they stay the same size until the internal stroke > width is large enough. At that point you see a 'jump'. > > I think canvas should have a similar feature... Can you elaborate on how exactly you would want this to work? How would you avoid the alignment and distortion problems when applying this to anything less trivial than a rectangle? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From cabanier at gmail.com Thu Sep 5 15:41:42 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Thu, 5 Sep 2013 15:41:42 -0700 Subject: [whatwg] Blurry lines in 2D Canvas In-Reply-To: <alpine.DEB.2.00.1309052119410.7443@ps20323.dreamhostps.com> References: <CAGN7qDAdABj2NCNcc53qDd23Twq2=999u0Sio-gEsBJURrpCcg@mail.gmail.com> <CAPeKFThd5HvtYFvokX=n7UR_Qs=wmqHy2vMFDoDs9y9Jd5jM=Q@mail.gmail.com> <CAGN7qDCOdadxurg5qp6q3UMygv0gjBNc5BoHOgtZKggD=5ppNQ@mail.gmail.com> <CABirCh_0orFzaZAUrtg3Z+Jg0LdSGMZxuapVdKZgigEdKJJVXQ@mail.gmail.com> <CAGN7qDDbS5Vy65SqiSdVtxgz8W9w+8WO3n=2H4wpSdkaQNLBCQ@mail.gmail.com> <CABirCh-NiwtSMzs5J5=cqazNYGAKufA3s1Lz1cW-6YvhGbt8pg@mail.gmail.com> <CAGN7qDBqXxY-aWmb3kWwxXh=rfD1BfHCEiESs9yHiFkpxkPFig@mail.gmail.com> <CABirCh9RSb0SEMsqy9KHEV77h7s04hgq7G6evCYLFRM10Kh+1A@mail.gmail.com> <CAGN7qDA8fe42MUR-Dt1sxtCnN=hPYLe6TcasSfjV+q+i-UmrjA@mail.gmail.com> <alpine.DEB.2.00.1309052119410.7443@ps20323.dreamhostps.com> Message-ID: <CAGN7qDC8hBPJc+HhRjgodkBAkhFEgJX0kAe=pMp9g3AnUm49Wg@mail.gmail.com> On Thu, Sep 5, 2013 at 3:22 PM, Ian Hickson <ian at hixie.ch> wrote: > On Tue, 23 Jul 2013, Rik Cabanier wrote: > > > > we've noticed that if you draw lines in canvas or SVG, they always end > > up blurry. For instance see this fiddle: http://jsfiddle.net/V92Gn/128/ > > Not always, only if you don't draw the line aligned with the pixel grid > (e.g. you draw a diagonal line, or a horizontal or vertical line that > isn't centered in the middle of pixels on the pixels grid, or a horizontal > or vertical line whose width isn't an integral number of pixels, etc). > > The options, on a pixel grid display, are: > > - don't honour the position precisely -- this leads to very ugly > artifacts when animating (lines jerk around), and basically means that > the graphics aren't accurate. > > - instead of describing the shapes as vectors, describe them using > programs that can adapt to the position and size they're being drawn > at, such that they automatically snap to the pixel grid in a pretty > fashion -- this is what fonts do. > > - try to trick the eye by using anti-aliasing when things don't line up > exactly on the pixel grid. > > The first two really aren't plausible options for <canvas>. > > > On Wed, 24 Jul 2013, Kornel Lesi?ski wrote: > > > > For 1-pixel lines it could be fixed by allowing authors to specify that > > path should be stroked with lines aligned to inside/outside of the path > > (which is a useful feature on its own). > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=22674 > > > On Tue, 23 Jul 2013, Rik Cabanier wrote: > > > > Sure, but how can we fix this? > > What is there to fix? The options above are basically the only options. > You can't not do one of them -- there's no way to draw a crisp line that > isn't pixel aligned. There's no pixels there. Similarly, there's no way to > draw a line that's neither horizontal nor vertical yet is crisp and > doesn't look jaggy. The pixels are squares, they don't rotate on modern > pixel displays. > > > On Wed, 24 Jul 2013, Kornel Lesi?ski wrote: > > > > Should arc() and bezier curves also be snapped? What if you want a line > > that touches the curve? > > That's precisely the problem with snapping -- it is far worse than > antialiasing. You can't draw precise shapes if you have snapping. > > > On Wed, 24 Jul 2013, Dirk Schulze wrote: > > > > Means implementations would need to take viewport, transformations of > > the document, transformations on elements in the DOM hierarchy, zoom > > level, aspect ratio of the canvas, position of the canvas in the > > document, transformations in the canvas and device pixel resolution into > > account to snap lines to the correct position on the individual device, > > right?Otherwise it sounds to be hard to guarantee that you don't see > > antialiased strokes and lines might snap more then just one device > > pixel. This would also be a problem for aligning shapes to each other in > > the canvas I guess. What happens on the next transformation after a > > drawing operation. Say you draw a line that was snapped to the grid and > > then you do scale(1.1, 1.1). Shall the implementation redraw the canvas? > > After all it is an pixel image. A vector based drawing format would be > > better suited for such a task. > > Indeed. > > > On Sat, 10 Aug 2013, Rik Cabanier wrote: > > > > I was wondering if this is something that happens in Flash as well. It > > turns out that there's an option called "hinting: Keep stroke anchors on > > full pixels to prevent blurry lines." There's a blog post on what this > > does: > > > http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html > > < > http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html > > > > > > I created an example (in flash sorry) that shows the feature: > > http://cabanier.github.io/BlendExamples/pixelsnap/pixelsnap.html > > 2 sets of strokes move across the screen and are also scaled. > > > > The top strokes behave like canvas does today. They start of blurry and > > during the animation they slowly get ticker. For some reason it doesn't > > look very smooth. > > The bottom strokes have hinting turned on. They are sharp at the > beginning > > and during the animation they stay the same size until the internal > stroke > > width is large enough. At that point you see a 'jump'. > > > > I think canvas should have a similar feature... > > Can you elaborate on how exactly you would want this to work? How would > you avoid the alignment and distortion problems when applying this to > anything less trivial than a rectangle? Basically, this would *just* move the control points and the width of paths so the strokes are always aligned to the pixel grid (This would take pixel density and transformations into account). After this, you would draw as usual. From barraclough at apple.com Thu Sep 5 15:45:55 2013 From: barraclough at apple.com (Gavin Barraclough) Date: Thu, 05 Sep 2013 15:45:55 -0700 Subject: [whatwg] [[GetOwnProperty]] for named properties of the Window object Message-ID: <52600B08-E2BB-4AA3-877E-797E1CF687BC@apple.com> Hi, I was wondering if anyone could help clarify expected behavior of [[GetOwnProperty]] for named properties of the Window object. (It looks like this falls across the HTML5 & WebIDL specs, apologies if this is the wrong place to ask). Per WebIDL?s definition of [Global] (http://dev.w3.org/2006/webapi/WebIDL/#Global) the named properties are exposed on a named properties object on the prototype chain. Per section 4.5.5.1 (http://dev.w3.org/2006/webapi/WebIDL/#named-properties-object) the [[GetOwnProperty]] implementation should return a descriptor with writable set to false, enumerable and configurable set to true. Firefox and Chrome both return descriptors from an object on the prototype chain per the spec, attributes of the value are configured differently, with enumerable set to false, writable and configurable set to true. There seem to be some compelling reasons to follow Firefox / Chrome (writable true seems more congruent with ECMA262 specified [[Put]], unless there is another mechanism I?m missing here, enumerable is odd since I don?t think the spec says anything about [[GetOwnPropertyNames]]),so I was hoping to better understand why the spec requires the behaviour it does (or whether I?m just following it incorrectly!) Many thanks, Gavin From cabanier at gmail.com Thu Sep 5 15:56:43 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Thu, 5 Sep 2013 15:56:43 -0700 Subject: [whatwg] Path API feedback In-Reply-To: <alpine.DEB.2.00.1308202232540.27209@ps20323.dreamhostps.com> References: <CAGN7qDATVtL08NLKvYsL+WVzGYn5fy3WxdQLQYqpB55NuhyL3g@mail.gmail.com> <Pine.LNX.4.64.1304260027360.3512@ps20323.dreamhostps.com> <CAGN7qDBcC7aPD1BcuDHbvMavfM3ez0CufFWgaLHcaPHBsuoNrA@mail.gmail.com> <alpine.DEB.2.00.1308202232540.27209@ps20323.dreamhostps.com> Message-ID: <CAGN7qDDXqyZt2gkmttoUps3qgEUiesBdpGmhotUhk4Ay6S_PVQ@mail.gmail.com> On Tue, Aug 20, 2013 at 3:36 PM, Ian Hickson <ian at hixie.ch> wrote: > On Fri, 26 Apr 2013, Rik Cabanier wrote: > > > > I think an author would expect that 'addPathByStrokingPath' and other > > path methods render as if you stroked/outlined directly on the canvas > > context. Same goes for 'addPath'. > > > > I believe very few people actually want the current behavior that's in > > the spec. > > I don't know how true that is. > > It seems logical to me that this: > > context.beginPath(); > context.rect(0,0,100,100); > context.rect(50,50,150,150); > context.fill(); > > ...should do the same as this: > > var p1 = new Path(); > p1.rect(0,0,100,100); > var p2 = new Path();s > p2.rect(50,50,150,150); > var p = new Path(); > p.addPath(p1); > p.addPath(p2); > context.fill(p); > > ...for any combination of path commands where I've put the rect()s. > Yes, that would be reasonable behavior since a path is just an aggregation of segments. The problem happens when you call fill or stroke multiple times. For instance: context.beginPath(); context.rect(0,0,100,100); context.fill(); context.beginPath(); context.rect(200,50,-150,150); context.fill(); Now I want to create a region that covers what was drawn. p1.rect(0,0,100,100); var p2 = new Path();s p2.rect(200,50,-150,150); var p = new Path(); p.addPath(p1); p.addPath(p2); 'p' won't describe the same area as what was filled. > > > > > I think the spec needs to mention that > > > > - sections of the path where both edges are filled should be removed > > > > - winding needs to be done so eofill and fill give the same result > > > > > > I've filed a bug for adding something like this: > > > > > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=21835 > > > > > > I'm not sure exactly what the algorithm should be (as we discussed on > > > IRC today), so if anyone has any input here, please don't hesitate to > > > comment. > > > > I can help if needed. I know the skia people are working on this as > > well. > > > > The algorithm is fairly straightforward to describe in prose. > > Implementation is very hard though... > > Please do add such help as comments on the bug, that would be very > helpful. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > From wiltzius at chromium.org Thu Sep 5 16:33:24 2013 From: wiltzius at chromium.org (Tom Wiltzius) Date: Thu, 5 Sep 2013 16:33:24 -0700 Subject: [whatwg] Adding 2D Canvas features In-Reply-To: <CAA5isUYmMm9sHu=_Ybwmhw7GWfO+vRpP+8MdM_+OXKPCc+i4+Q@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <51D12692.4030002@artspark.co.jp> <CAK-G-KVLsECC4cETFYdcPyoqigaaoRhUxcezhMG3jZc2fAViRg@mail.gmail.com> <alpine.DEB.2.00.1309052049070.7443@ps20323.dreamhostps.com> <CAA5isUYmMm9sHu=_Ybwmhw7GWfO+vRpP+8MdM_+OXKPCc+i4+Q@mail.gmail.com> Message-ID: <CAK-G-KUOzNXhRfZRTtmuYFHHcHDriSodcRmoORGqi4XhFevNuQ@mail.gmail.com> On Thu, Sep 5, 2013 at 3:19 PM, Simon Sarris <simon.sarris at gmail.com> wrote: > Just FYI, Chrome now has a relatively new bug for "Canvas v5 API > additions" that references all the missing features that some posters were > concerned about. > > The default take from this bug report is that all of these are > greenlighted to be worked on (no objections so far) > > https://code.google.com/p/chromium/issues/detail?id=281529 > > This bug is now (as of a few days ago) referenced at chromestatus.comunder the Canvas feature's implementation status: > > http://www.chromestatus.com/features/5100084685438976 > Yes, although that's probably somewhat misleading as the Chromium contributor who volunteered to help implement those is only human and it's a rather long list. I'll be working with him to prioritize, but it's not like suddenly these can all happen. Meanwhile this doesn't change the other Canvas2D-related work ongoing in the Chromium project, so we're still keen to see some new features added to the Canvas spec. Ian if it would help to identify items in the spec that Chromium doesn't intend to implement (at least any time soon), we can attempt to do so. > > > Simon > From jacob.benoit.1 at gmail.com Thu Sep 5 18:39:51 2013 From: jacob.benoit.1 at gmail.com (Benoit Jacob) Date: Thu, 5 Sep 2013 21:39:51 -0400 Subject: [whatwg] Challenging canvas.supportsContext In-Reply-To: <alpine.DEB.2.00.1309032240300.7443@ps20323.dreamhostps.com> References: <CAJTmd9rkwsjC+WDfLr7um0=h8Pvtg9JOJCRHzH4PhdbXjgpaaA@mail.gmail.com> <CAJTmd9q-eH8fnZSP5mr3kX-quyQcNXnyXTh5o_hX+MdfuXfrGQ@mail.gmail.com> <alpine.DEB.2.00.1309032240300.7443@ps20323.dreamhostps.com> Message-ID: <CAJTmd9q+Zyh=Fz3mRwBDBfy5q+mR5tVoNTv+rEtKJueQv2mfwg@mail.gmail.com> (I want to be clear that the long delay hinders my ability to continue this conversation. I'm just one regular Mozilla developer --- I'm not supposed to be spending a lot of time discussing the canvas standard, and right now, I can't really afford to. Back when I started this thread in june, I did have some time to invest in a long conversation on this. Right now I don't.) Some partial inline responses below. 2013/9/3 Ian Hickson <ian at hixie.ch> > > The long and short of this is that I renamed "supportsContext()" to > "probablySupportsContext()". It's already implemented in WebKit And that's the real cost of having accepted supportsContext too early in the HTML spec. > Fundamentally, it addresses a need that none of the other proposals > addressed: how to know whether or not you can expect to be able to do 3D. > It's not 100% reliable, but then neither would actually attempting to > create a context, because creating a context is so expensive on some > platforms that some UAs are going to move to doing it lazily > The only conformant way to do lazy context creation would be to have getContext return lost contexts, but given that only a tiny minority of real-world code cares about that concept, that's not going to be feasible in the foreseeable future. Maybe in a few years, optimistically. > > > On Wed, 19 Jun 2013, Benoit Jacob wrote: > > > > I'd like to question the usefulness of canvas.supportsContext. I tried to > > think of an actual application use case for it, and couldn't find one. > > The use case is libraries like Modernizr that want to do feature detection > up-front, but don't want a high performance hit on startup. > > > > However, that only shifts the question to: what is the reason for them > > to expose such APIs? In the end, I claim that the only thing that we > > should recognize as a reason to add a feature to the HTML spec, is > > *application* use cases. > > Oh well the use case for knowing whether or not 3D is supported on a > particular device is straight-forward: you want to know which set of > assets and logic to download and run. > Application developer wants things. But these are not necessarily good ideas, because they may not reflect how things really work. More below. > > > > So let's look at the naive application usage pattern for supportsContext: > > > > if (canvas.supportsContext("webgl")) { > > context = canvas.getContext("webgl"); > > } > > > > The problem is that the same can be achieved with just the getContext > > call, and checking whether it succeeded. > > Suppose you have an app that has a 3D feature, but it's not immediately > used upon startup. For example, a preview window that is displayed on > request. You want to preload all the code to run the preview window, but > you need to load different code based on whether the device can do 3D or > not. So the use case is more: > > if (canvas.supportsContext("webgl")) > load3DCode(); > else > load2DCode(); > > // 3D code: > function run() { > context = canvas.getContext("webgl"); > // ... > } > If now application developers call probablySupportsContext, it returns true, they start downloading the WebGL assets, but getContext("webgl") fails, their application startup experience will be wose, which will pressure browser developers to optimize the accuracy of probablySupportsContext, but that's going to be hard and unrewarding. So my best hope is that application developers don't use probablySupportsContext. Instead, they should do their actual getContext call --- the one creating the context that they will actually want to use --- right at the beginning of their application startup, and download the right assets based on the outcome of that getContext. The downside of course is that assets download becomes gated on getContext returning. But in practice that's not too bad: - Only the first getContext in a browser sessing can be really slow (say 100 ms), subsequent ones tend to take less than 5 ms --- not that much compared to the time to download big assets. - If any assets are shared between the two code paths, they can be downloaded first while getContext is running. > > You don't want to pay the cost of creating a throw-away 3D context on > startup just to know which scripts to load. It defeats the whole point of > not loading all the code up-front. > I'm not talking about having any throw-away 3d contexts just for testing. I understand that modernizr has an API that would force it to be implemented in that way. In my view, that makes it a bad API. There should be only one context, the one that we actually want to use. > > > > Outside of exceptional cases (out of memory...), the slow path in > > getContext is the *success* case, and again, in that case a real > > application would want to actually *use* that context. > > Not necessarily, as noted above. The <canvas> you're going to draw to > might not even exist at the point you need to know if it's 3D or not. > Precisely, that's my point: don't cater to the pathological use-a-separate-throwaway-context use case, instead assume that people are smart and that if the first getContext succeeds, they will use that context. > > > > Keep in mind that supportsContext can't guarantee that if it returns > true, > > then a subsequent getContext will succeed. > > Sure. getContext() can't guarantee that if it returns a context, the > context will work forever, either. > Indeed, there is some non-determinism inherent to how GPUs work. I'm just talking about not adding more non-determinism to it. > > > Given such deep problems, I think that the usefulness bar for accepting > > supportsContext into the spec should be quite high. > > The problem is that there's no alternative solution. > As I've been advocating, there is a more reasonable alternative which is not to have anything else than getContext. Benoit From bzbarsky at MIT.EDU Thu Sep 5 18:50:33 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Thu, 05 Sep 2013 21:50:33 -0400 Subject: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments In-Reply-To: <CADnb78jxE5B2KTYXj0QBv0GSoGddb=Gbxym5Cp5tYxm7zMG1aA@mail.gmail.com> References: <20130628201946.26920@gmx.com> <CADnb78jxE5B2KTYXj0QBv0GSoGddb=Gbxym5Cp5tYxm7zMG1aA@mail.gmail.com> Message-ID: <522934E9.5070603@mit.edu> On 9/5/13 6:02 AM, Anne van Kesteren wrote: > Having said that, our current plan is to rely on the Selectors API (2) In that case I think we need to add a function to the platform that CSS-escapes a string. Because right now, writing querySelector("#" + id) is a total footgun unless you control the id. In particular, if you're a library you're in trouble... > but the hope is that .querySelector("#test") will be fast > enough. As I explained in the thread, they have quite different behavior: getElementById takes the ID, but querySelector needs a CSS-escaped form of the ID. I'm happy to raise this point on www-dom if you want. Just let me know. -Boris From bzbarsky at MIT.EDU Thu Sep 5 18:57:37 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Thu, 05 Sep 2013 21:57:37 -0400 Subject: [whatwg] Alignment of empty buttons In-Reply-To: <alpine.DEB.2.00.1309052044160.22377@ps20323.dreamhostps.com> References: <CAPTJ0XEA_NMAB41UHg1cXXmQTRsxg2zhd9LCuSS2b6R2ZBSVig@mail.gmail.com> <CAPTJ0XE1337+UqNC4D9gpuWO6QHQ7gHc+x8y08SYjCJmghzEag@mail.gmail.com> <51846106.2060403@mit.edu> <alpine.DEB.2.00.1307122007550.15729@ps20323.dreamhostps.com> <51E06313.8030105@mit.edu> <alpine.DEB.2.00.1309050004230.7443@ps20323.dreamhostps.com> <522814AD.8000901@mit.edu> <alpine.DEB.2.00.1309052044160.22377@ps20323.dreamhostps.com> Message-ID: <52293691.90301@mit.edu> On 9/5/13 4:47 PM, Ian Hickson wrote: > In what sense? In the sense that if its computed display is "block" but its layout behavior is not that of a non-replaced block (CSS 2.1 section 10.3.3 and so forth), then it's clearly a replaced element with layout behavior defined by something other than CSS. > The definition of "replaced element" here: > > http://www.w3.org/TR/CSS2/conform.html#replaced-element > > ...doesn't seem to apply to <button>. The rendering of <button> is very > much in CSS' scope, no? Sure doesn't seem to be, since no UA actually renders <button style="display: block"> the way a CSS block renders; they do something totally different which is presumably covered by some other spec (e.g. HTML). -Boris From bzbarsky at MIT.EDU Thu Sep 5 19:15:34 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Thu, 05 Sep 2013 22:15:34 -0400 Subject: [whatwg] [[GetOwnProperty]] for named properties of the Window object In-Reply-To: <52600B08-E2BB-4AA3-877E-797E1CF687BC@apple.com> References: <52600B08-E2BB-4AA3-877E-797E1CF687BC@apple.com> Message-ID: <52293AC6.5020108@mit.edu> Ccing public-script-coord, since that's the right place for this discussion (because WebIDL is the relevant specification). On 9/5/13 6:45 PM, Gavin Barraclough wrote: > Firefox and Chrome both return descriptors from an object on the prototype chain per the spec Chrome doesn't quite follow the spec here, for what it's worth: it returns them from Window.prototype as far as I can tell, not from an actual named properties object. > attributes of the value are configured differently, with enumerable set to false, writable and configurable set to true. Current tip Firefox returns {"configurable":true,"enumerable":true,"writable":true} and enumerates the properties. Probably a change from https://bugzilla.mozilla.org/show_bug.cgi?id=895758 to align better with the spec in terms of the enumeration behavior. > There seem to be some compelling reasons to follow Firefox / Chrome (writable true seems more congruent with ECMA262 specified [[Put]] Indeed. I think the current setup in the spec would make window.foo not settable if <img id="foo"> exists.... That seems bad. > unless there is another mechanism I?m missing here, enumerable is odd since I don?t think the spec says anything about [[GetOwnPropertyNames]]) It doesn't, but it does talk about enumeration; see http://dev.w3.org/2006/webapi/WebIDL/#property-enumeration (whether that's applicable to the Named Properties Object is an interesting question). Granted, I would rather that were defined in terms of [[GetOwnPropertyNames]] on the relevant objects instead; that's what actually needs to happen under the hood anyway. > ,so I was hoping to better understand why the spec requires the behaviour it does (or whether I?m just following it incorrectly!) I think you're following it correctly; it's just buggy. ;) -Boris From kanghaol at oupeng.com Thu Sep 5 20:05:56 2013 From: kanghaol at oupeng.com (Kang-Hao (Kenny) Lu) Date: Fri, 06 Sep 2013 11:05:56 +0800 Subject: [whatwg] Parse errors for invalid characters In-Reply-To: <522900C4.2050409@googlemail.com> References: <522900C4.2050409@googlemail.com> Message-ID: <52294694.9080309@oupeng.com> (2013/09/06 6:08), Geoffrey Sneddon wrote: > The phrasing content section states: > >> Text nodes and attribute values must consist of Unicode characters, >> must not contain U+0000 characters, must not contain permanently >> undefined Unicode characters (noncharacters), and must not contain >> control characters other than space characters. This specification >> includes extra constraints on the exact value of Text nodes and >> attribute values depending on their precise context. > > And the pre-processing the input-stream section states: > >> Any occurrences of any characters in the ranges U+0001 to U+0008, >> U+000E to U+001F, U+007F to U+009F, U+FDD0 to U+FDEF, and characters >> U+000B, U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, U+2FFFE, U+2FFFF, U+3FFFE, >> U+3FFFF, U+4FFFE, U+4FFFF, U+5FFFE, U+5FFFF, U+6FFFE, U+6FFFF, >> U+7FFFE, U+7FFFF, U+8FFFE, U+8FFFF, U+9FFFE, U+9FFFF, U+AFFFE, >> U+AFFFF, U+BFFFE, U+BFFFF, U+CFFFE, U+CFFFF, U+DFFFE, U+DFFFF, >> U+EFFFE, U+EFFFF, U+FFFFE, U+FFFFF, U+10FFFE, and U+10FFFF are parse >> errors. These are all control characters or permanently undefined >> Unicode characters (noncharacters). > > Note the first uses "Unicode characters", the second "characters" ? the > former excludes surrogates as a conformance requirement. > > Note that every disallowed non-surrogate character is a parse error. Except U+0000 or am I missing something? > Therefore, it would make sense to make surrogates parse errors. > > It should be noted that they can only occur in the input stream if they > come from script (as they cannot be decoded from the input byte stream > as the decoders will never emit a surrogate). which means that this seems ... cubersome ... to implement in a conformance checker. Which reminds me, does # Conformance checkers must report at least one parse error # condition to the user if one or more parse error conditions exist # in the document and must not report parse error conditions if none # exist in the document. Conformance checkers may report more than # one parse error condition if more than one parse error condition # exists in the document. mean validator.nu and Firefox view source are non-conforming because they do nothing about document.write() ? I think we should exempt conformance checkers from scripts instead. Cheers, Kenny -- Web Specialist, Opera Sphinx Game Force, Oupeng Browser, Beijing Try Oupeng: http://www.oupeng.com/ From cabanier at gmail.com Thu Sep 5 20:48:54 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Thu, 5 Sep 2013 20:48:54 -0700 Subject: [whatwg] Stroking algorithm in Canvas 2d Message-ID: <CAGN7qDA-iib4SULW-JDf4_vpsyuxpg1m8AkXq=qgDtY1OkXahA@mail.gmail.com> All, we've looked over the algorithm in the Canvas spec that describes how strokes are computed. [1] We think that this section is making some incorrect assumptions. For instance, the dashes are calculated over the total lenght of all subpaths, but each subpath should be treated separately. It's also a bit strange that the spec is trying to describe how to stroke. For instance, it goes in minute detail on how dashes are applied but the hardest part of stroking ("inflating the paths in path perpendicular to the direction") is not described at all. Wouldn't it be better to remove all these steps and simply show the desired effect? If not, what would be the best way to fix the wording? The mailing list or a bug? 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#trace-a-path From annevk at annevk.nl Fri Sep 6 04:22:34 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Fri, 6 Sep 2013 12:22:34 +0100 Subject: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments In-Reply-To: <522934E9.5070603@mit.edu> References: <20130628201946.26920@gmx.com> <CADnb78jxE5B2KTYXj0QBv0GSoGddb=Gbxym5Cp5tYxm7zMG1aA@mail.gmail.com> <522934E9.5070603@mit.edu> Message-ID: <CADnb78iJVBVomf_hiWQOSHc6Umh+UwqjjwKLbathV54XFm3-uQ@mail.gmail.com> On Fri, Sep 6, 2013 at 2:50 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote: > In that case I think we need to add a function to the platform that > CSS-escapes a string. Maybe a thing for window.CSS? Simon? Such a function already exists in the wild btw: http://mothereff.in/css-escapes -- http://annevankesteren.nl/ From simonp at opera.com Fri Sep 6 05:20:01 2013 From: simonp at opera.com (Simon Pieters) Date: Fri, 06 Sep 2013 14:20:01 +0200 Subject: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments In-Reply-To: <CADnb78iJVBVomf_hiWQOSHc6Umh+UwqjjwKLbathV54XFm3-uQ@mail.gmail.com> References: <20130628201946.26920@gmx.com> <CADnb78jxE5B2KTYXj0QBv0GSoGddb=Gbxym5Cp5tYxm7zMG1aA@mail.gmail.com> <522934E9.5070603@mit.edu> <CADnb78iJVBVomf_hiWQOSHc6Umh+UwqjjwKLbathV54XFm3-uQ@mail.gmail.com> Message-ID: <op.w2zojngdidj3kv@simons-macbook-pro.local> On Fri, 06 Sep 2013 13:22:34 +0200, Anne van Kesteren <annevk at annevk.nl> wrote: > On Fri, Sep 6, 2013 at 2:50 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote: >> In that case I think we need to add a function to the platform that >> CSS-escapes a string. > > Maybe a thing for window.CSS? Simon? > > Such a function already exists in the wild btw: > http://mothereff.in/css-escapes So the use case is getting an element by id with an "untrusted" id as input, in an element or document fragment as opposed to the document? -- Simon Pieters Opera Software From scott.gonzalez at gmail.com Fri Sep 6 05:21:24 2013 From: scott.gonzalez at gmail.com (=?ISO-8859-1?Q?Scott_Gonz=E1lez?=) Date: Fri, 6 Sep 2013 08:21:24 -0400 Subject: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments In-Reply-To: <op.w2zojngdidj3kv@simons-macbook-pro.local> References: <20130628201946.26920@gmx.com> <CADnb78jxE5B2KTYXj0QBv0GSoGddb=Gbxym5Cp5tYxm7zMG1aA@mail.gmail.com> <522934E9.5070603@mit.edu> <CADnb78iJVBVomf_hiWQOSHc6Umh+UwqjjwKLbathV54XFm3-uQ@mail.gmail.com> <op.w2zojngdidj3kv@simons-macbook-pro.local> Message-ID: <CAO8i3iet-6D+j3Z=UQ6r7EHvxTW1PxSz1yiAEejwdf4ztVYCuA@mail.gmail.com> On Fri, Sep 6, 2013 at 8:20 AM, Simon Pieters <simonp at opera.com> wrote: > So the use case is getting an element by id with an "untrusted" id as > input, in an element or document fragment as opposed to the document? > Yes. Take the example of finding the input associated with a label: <label for="foo">foo</label> <input id="foo"> If you have a reference to the label and you want to find the input, you need to escape the value of the for attribute before querying. From simonp at opera.com Fri Sep 6 05:40:00 2013 From: simonp at opera.com (Simon Pieters) Date: Fri, 06 Sep 2013 14:40:00 +0200 Subject: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments In-Reply-To: <CAO8i3iet-6D+j3Z=UQ6r7EHvxTW1PxSz1yiAEejwdf4ztVYCuA@mail.gmail.com> References: <20130628201946.26920@gmx.com> <CADnb78jxE5B2KTYXj0QBv0GSoGddb=Gbxym5Cp5tYxm7zMG1aA@mail.gmail.com> <522934E9.5070603@mit.edu> <CADnb78iJVBVomf_hiWQOSHc6Umh+UwqjjwKLbathV54XFm3-uQ@mail.gmail.com> <op.w2zojngdidj3kv@simons-macbook-pro.local> <CAO8i3iet-6D+j3Z=UQ6r7EHvxTW1PxSz1yiAEejwdf4ztVYCuA@mail.gmail.com> Message-ID: <op.w2zpgyomidj3kv@simons-macbook-pro.local> On Fri, 06 Sep 2013 14:21:24 +0200, Scott Gonz?lez <scott.gonzalez at gmail.com> wrote: > On Fri, Sep 6, 2013 at 8:20 AM, Simon Pieters <simonp at opera.com> wrote: > >> So the use case is getting an element by id with an "untrusted" id as >> input, in an element or document fragment as opposed to the document? >> > > Yes. Take the example of finding the input associated with a label: > > <label for="foo">foo</label> > <input id="foo"> > > If you have a reference to the label and you want to find the input, you > need to escape the value of the for attribute before querying. In this example, are the elements in the document? -- Simon Pieters Opera Software From scott.gonzalez at gmail.com Fri Sep 6 05:43:14 2013 From: scott.gonzalez at gmail.com (=?ISO-8859-1?Q?Scott_Gonz=E1lez?=) Date: Fri, 6 Sep 2013 08:43:14 -0400 Subject: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments In-Reply-To: <op.w2zpgyomidj3kv@simons-macbook-pro.local> References: <20130628201946.26920@gmx.com> <CADnb78jxE5B2KTYXj0QBv0GSoGddb=Gbxym5Cp5tYxm7zMG1aA@mail.gmail.com> <522934E9.5070603@mit.edu> <CADnb78iJVBVomf_hiWQOSHc6Umh+UwqjjwKLbathV54XFm3-uQ@mail.gmail.com> <op.w2zojngdidj3kv@simons-macbook-pro.local> <CAO8i3iet-6D+j3Z=UQ6r7EHvxTW1PxSz1yiAEejwdf4ztVYCuA@mail.gmail.com> <op.w2zpgyomidj3kv@simons-macbook-pro.local> Message-ID: <CAO8i3ifim0vvaA_vG_FfjkkirWHUYB--MHrXidr54exFvd-FtA@mail.gmail.com> On Fri, Sep 6, 2013 at 8:40 AM, Simon Pieters <simonp at opera.com> wrote: > On Fri, 06 Sep 2013 14:21:24 +0200, Scott Gonz?lez < > scott.gonzalez at gmail.com> wrote: > >> Yes. Take the example of finding the input associated with a label: >> >> <label for="foo">foo</label> >> <input id="foo"> >> >> If you have a reference to the label and you want to find the input, you >> need to escape the value of the for attribute before querying. >> > > In this example, are the elements in the document? For jQuery, the answer tends to be "it doesn't matter." There are very few places where we treat in-document and out-of-document situations differently. From scott.gonzalez at gmail.com Fri Sep 6 05:47:56 2013 From: scott.gonzalez at gmail.com (=?ISO-8859-1?Q?Scott_Gonz=E1lez?=) Date: Fri, 6 Sep 2013 08:47:56 -0400 Subject: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments In-Reply-To: <CAAWBYDDi9s9+6v3RQfugDR=nRXrtV=7xZUBuFcMxUiU1+wN-cQ@mail.gmail.com> References: <20130628212857.262740@gmx.com> <CAAWBYDDi9s9+6v3RQfugDR=nRXrtV=7xZUBuFcMxUiU1+wN-cQ@mail.gmail.com> Message-ID: <CAO8i3icHF=MeWrzPGL2j2-tvfx4XauhdUQDKMZgKiy6pSjxj2w@mail.gmail.com> On Fri, Jun 28, 2013 at 6:51 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote: > On Fri, Jun 28, 2013 at 2:28 PM, Zirak A <zirak at mail.com> wrote: > > Besides my personal aversion towards selectors being in the DOM API, > there's > > also the simple fact that it makes sense for document fragments to have > these > > methods. > > That's far from obvious, given that I don't think it makes sense to > spread those obsolete methods around any further. They were already spread to ShadowRoot. Does anyone have a reference to that discussion that led to that decision? It seems like if they're being added to ShadowRoot, which inherits from DocumentFragment, we might as well just add them to DocumentFragment and be done with it. At least from a non-implementor's view that seems to make sense. From simonp at opera.com Fri Sep 6 05:59:06 2013 From: simonp at opera.com (Simon Pieters) Date: Fri, 06 Sep 2013 14:59:06 +0200 Subject: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments In-Reply-To: <CAO8i3ifim0vvaA_vG_FfjkkirWHUYB--MHrXidr54exFvd-FtA@mail.gmail.com> References: <20130628201946.26920@gmx.com> <CADnb78jxE5B2KTYXj0QBv0GSoGddb=Gbxym5Cp5tYxm7zMG1aA@mail.gmail.com> <522934E9.5070603@mit.edu> <CADnb78iJVBVomf_hiWQOSHc6Umh+UwqjjwKLbathV54XFm3-uQ@mail.gmail.com> <op.w2zojngdidj3kv@simons-macbook-pro.local> <CAO8i3iet-6D+j3Z=UQ6r7EHvxTW1PxSz1yiAEejwdf4ztVYCuA@mail.gmail.com> <op.w2zpgyomidj3kv@simons-macbook-pro.local> <CAO8i3ifim0vvaA_vG_FfjkkirWHUYB--MHrXidr54exFvd-FtA@mail.gmail.com> Message-ID: <op.w2zqcszwidj3kv@simons-macbook-pro.local> On Fri, 06 Sep 2013 14:43:14 +0200, Scott Gonz?lez <scott.gonzalez at gmail.com> wrote: > For jQuery, the answer tends to be "it doesn't matter." There are very > few > places where we treat in-document and out-of-document situations > differently. OK. There's http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#dom-label-control but it only works when in a document. Maybe that should be changed, though. -- Simon Pieters Opera Software From junov at google.com Fri Sep 6 07:11:57 2013 From: junov at google.com (Justin Novosad) Date: Fri, 6 Sep 2013 10:11:57 -0400 Subject: [whatwg] Stroking algorithm in Canvas 2d In-Reply-To: <CAGN7qDA-iib4SULW-JDf4_vpsyuxpg1m8AkXq=qgDtY1OkXahA@mail.gmail.com> References: <CAGN7qDA-iib4SULW-JDf4_vpsyuxpg1m8AkXq=qgDtY1OkXahA@mail.gmail.com> Message-ID: <CABpaAqQFx71oeoF3_vqCZnSqhnrVTMEgZzn8FYdM8QPnYHWZcQ@mail.gmail.com> On Thu, Sep 5, 2013 at 11:48 PM, Rik Cabanier <cabanier at gmail.com> wrote: > All, > > we've looked over the algorithm in the Canvas spec that describes how > strokes are computed. [1] > We think that this section is making some incorrect assumptions. For > instance, the dashes are calculated over the total lenght of all subpaths, > but each subpath should be treated separately. > Why? Don't we want there to be continuity in the dash pattern across joins? Especially considering that step 3 of the algorithm breaks all subpaths into elementary line segment subpaths. Or am I misunderstanding your comment? > It's also a bit strange that the spec is trying to describe how to stroke. > For instance, it goes in minute detail on how dashes are applied but the > hardest part of stroking ("inflating the paths in path perpendicular to the > direction") is not described at all. Wouldn't it be better to remove all > these steps and simply show the desired effect? > I agree. I think it would be clearer if the spec focused on what the expected output is. I see the current algorithm-based specification as unnecessarily challenging for implementors and web developers alike. The challenge for implementors is that this algorithm in unlikely to be implemented exactly as is since implementors will want to leverage services, respect constraints, and consider performance characteristics of the graphics APIs they are using. In other words, implementors are likely to have to figure-out alternate algorithms that produce equivalent results, which means they have to start by reverse-engineering the spec in order to figure-out what the desired output is. Reverse-engineering the spec is also necessary just for writing conformance tests. The algorithm in itself is still very useful as an example of how the spec could be implemented. FWIW, In general I have no issue with other parts of the spec that are specified as algorithms. It is just this one that I find particularly unwieldy. If not, what would be the best way to fix the wording? The mailing list or > a bug? > > 1: > > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#trace-a-path > From bzbarsky at MIT.EDU Fri Sep 6 07:42:47 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Fri, 06 Sep 2013 10:42:47 -0400 Subject: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments In-Reply-To: <op.w2zojngdidj3kv@simons-macbook-pro.local> References: <20130628201946.26920@gmx.com> <CADnb78jxE5B2KTYXj0QBv0GSoGddb=Gbxym5Cp5tYxm7zMG1aA@mail.gmail.com> <522934E9.5070603@mit.edu> <CADnb78iJVBVomf_hiWQOSHc6Umh+UwqjjwKLbathV54XFm3-uQ@mail.gmail.com> <op.w2zojngdidj3kv@simons-macbook-pro.local> Message-ID: <5229E9E7.3040404@mit.edu> On 9/6/13 8:20 AM, Simon Pieters wrote: > So the use case is getting an element by id with an "untrusted" id as > input, in an element or document fragment as opposed to the document? Or getting elements by tag name in a document fragment, for that matter (though "weird" chars in tag names are harder to produce; largely limited to leading digits). -Boris From cabanier at gmail.com Fri Sep 6 11:24:53 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Fri, 6 Sep 2013 11:24:53 -0700 Subject: [whatwg] Stroking algorithm in Canvas 2d In-Reply-To: <CABpaAqQFx71oeoF3_vqCZnSqhnrVTMEgZzn8FYdM8QPnYHWZcQ@mail.gmail.com> References: <CAGN7qDA-iib4SULW-JDf4_vpsyuxpg1m8AkXq=qgDtY1OkXahA@mail.gmail.com> <CABpaAqQFx71oeoF3_vqCZnSqhnrVTMEgZzn8FYdM8QPnYHWZcQ@mail.gmail.com> Message-ID: <CAGN7qDDwTbMuutK_C7QFCezA78rQtRCCaRjTL=FzBLqgUCUcSw@mail.gmail.com> On Fri, Sep 6, 2013 at 7:11 AM, Justin Novosad <junov at google.com> wrote: > > > > On Thu, Sep 5, 2013 at 11:48 PM, Rik Cabanier <cabanier at gmail.com> wrote: > >> All, >> >> we've looked over the algorithm in the Canvas spec that describes how >> strokes are computed. [1] >> We think that this section is making some incorrect assumptions. For >> instance, the dashes are calculated over the total lenght of all subpaths, >> but each subpath should be treated separately. >> > > Why? Don't we want there to be continuity in the dash pattern across > joins? Especially considering that step 3 of the algorithm breaks all > subpaths into elementary line segment subpaths. Or am I misunderstanding > your comment? > Maybe. The spec currently says: 1. Let width be the aggregate length of all the lines of all the subpaths in path, in coordinate space units. For dashing, each subpath should be treated separately. There shouldn't be a step that takes the total length of all subpaths. You are correct that dashing should result in a new series of subpaths that are then stroked (with joins and endcaps) usual. > >> It's also a bit strange that the spec is trying to describe how to stroke. >> For instance, it goes in minute detail on how dashes are applied but the >> hardest part of stroking ("inflating the paths in path perpendicular to >> the >> direction") is not described at all. Wouldn't it be better to remove all >> these steps and simply show the desired effect? >> > > I agree. I think it would be clearer if the spec focused on what the > expected output is. I see the current algorithm-based specification as > unnecessarily challenging for implementors and web developers alike. The > challenge for implementors is that this algorithm in unlikely to be > implemented exactly as is since implementors will want to leverage > services, respect constraints, and consider performance characteristics of > the graphics APIs they are using. In other words, implementors are likely > to have to figure-out alternate algorithms that produce equivalent results, > which means they have to start by reverse-engineering the spec in order to > figure-out what the desired output is. Reverse-engineering the spec is also > necessary just for writing conformance tests. The algorithm in itself is > still very useful as an example of how the spec could be implemented. > > FWIW, In general I have no issue with other parts of the spec that are > specified as algorithms. It is just this one that I find particularly > unwieldy. > > If not, what would be the best way to fix the wording? The mailing list or >> a bug? >> >> 1: >> >> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#trace-a-path >> > > From jackalmage at gmail.com Fri Sep 6 11:54:11 2013 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Fri, 6 Sep 2013 11:54:11 -0700 Subject: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments In-Reply-To: <CADnb78iJVBVomf_hiWQOSHc6Umh+UwqjjwKLbathV54XFm3-uQ@mail.gmail.com> References: <20130628201946.26920@gmx.com> <CADnb78jxE5B2KTYXj0QBv0GSoGddb=Gbxym5Cp5tYxm7zMG1aA@mail.gmail.com> <522934E9.5070603@mit.edu> <CADnb78iJVBVomf_hiWQOSHc6Umh+UwqjjwKLbathV54XFm3-uQ@mail.gmail.com> Message-ID: <CAAWBYDB4__DmZBKwfbS6+v3ADhJkODe-BtRcMAhjDdRrQResFQ@mail.gmail.com> On Fri, Sep 6, 2013 at 4:22 AM, Anne van Kesteren <annevk at annevk.nl> wrote: > On Fri, Sep 6, 2013 at 2:50 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote: >> In that case I think we need to add a function to the platform that >> CSS-escapes a string. > > Maybe a thing for window.CSS? Simon? Yeah, exposing window.CSS.escapeIdent(DOMString) would make sense. As noted, this is useful for ids, for tag names, and maybe even things like attribute names and values. ~TJ From danya.postfactum at gmail.com Fri Sep 6 23:23:06 2013 From: danya.postfactum at gmail.com (=?KOI8-R?B?5MHOycnMIOvP09TJzg==?=) Date: Sat, 7 Sep 2013 16:23:06 +1000 Subject: [whatwg] Should UA start dragging if [draggable] attr was set after mousedown? Message-ID: <CAGbmyKZ=so6h7+=vwOBGsD4jnb3zXZ6-9qQWgjemdfgzCjzvnw@mail.gmail.com> Hello. I am web developer. I contribute to the ACE (ace.ajax.org) project (web-based code editor). I faced with the issue that IE does not start dragging element if it's [draggable] attribute was set with some delay after mousedown event: element.draggable = false; > element.onmousedown = function() { > setTimeout(function(){ element.draggable = true }, 150); > }; Meanwhile, this works fine in other browsers. I tried to find this behavior to be defined by DND specification ( http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#dnd) but found nothing related. I reported the bug ( https://connect.microsoft.com/IE/feedback/details/799913/ie-8-11-ignores-draggable-attribute-when-set-after-mousedown-event-using-settimeout) but I am not sure this is really bug. May we we should add more specific explanation of DND initiatialization, to prevent such kind of misunderstanding? From foolistbar at googlemail.com Sat Sep 7 03:54:47 2013 From: foolistbar at googlemail.com (Geoffrey Sneddon) Date: Sat, 07 Sep 2013 11:54:47 +0100 Subject: [whatwg] Parse errors for invalid characters In-Reply-To: <52294694.9080309@oupeng.com> References: <522900C4.2050409@googlemail.com> <52294694.9080309@oupeng.com> Message-ID: <522B05F7.3070701@googlemail.com> On 06/09/2013 04:05, Kang-Hao (Kenny) Lu wrote: > (2013/09/06 6:08), Geoffrey Sneddon wrote: >> The phrasing content section states: >> >>> Text nodes and attribute values must consist of Unicode characters, >>> must not contain U+0000 characters, must not contain permanently >>> undefined Unicode characters (noncharacters), and must not contain >>> control characters other than space characters. This specification >>> includes extra constraints on the exact value of Text nodes and >>> attribute values depending on their precise context. >> >> And the pre-processing the input-stream section states: >> >>> Any occurrences of any characters in the ranges U+0001 to U+0008, >>> U+000E to U+001F, U+007F to U+009F, U+FDD0 to U+FDEF, and characters >>> U+000B, U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, U+2FFFE, U+2FFFF, U+3FFFE, >>> U+3FFFF, U+4FFFE, U+4FFFF, U+5FFFE, U+5FFFF, U+6FFFE, U+6FFFF, >>> U+7FFFE, U+7FFFF, U+8FFFE, U+8FFFF, U+9FFFE, U+9FFFF, U+AFFFE, >>> U+AFFFF, U+BFFFE, U+BFFFF, U+CFFFE, U+CFFFF, U+DFFFE, U+DFFFF, >>> U+EFFFE, U+EFFFF, U+FFFFE, U+FFFFF, U+10FFFE, and U+10FFFF are parse >>> errors. These are all control characters or permanently undefined >>> Unicode characters (noncharacters). >> >> Note the first uses "Unicode characters", the second "characters" ? the >> former excludes surrogates as a conformance requirement. >> >> Note that every disallowed non-surrogate character is a parse error. > > Except U+0000 or am I missing something? This is handled inline in the parser, as noted in the preprocessing section. It sometimes gets passed through as U+0000, sometimes gets changed to U+FFFD, sometimes gets ignored, but always creates a parser error. >> Therefore, it would make sense to make surrogates parse errors. >> >> It should be noted that they can only occur in the input stream if they >> come from script (as they cannot be decoded from the input byte stream >> as the decoders will never emit a surrogate). > > which means that this seems ... cubersome ... to implement in a > conformance checker. Which reminds me, does > > # Conformance checkers must report at least one parse error > # condition to the user if one or more parse error conditions exist > # in the document and must not report parse error conditions if none > # exist in the document. Conformance checkers may report more than > # one parse error condition if more than one parse error condition > # exists in the document. > > mean validator.nu and Firefox view source are non-conforming because > they do nothing about document.write() ? > > I think we should exempt conformance checkers from scripts instead. They already are. From the "Conformance classes" section: > Conformance checkers must check that the input document conforms when parsed without a browsing context (meaning that no scripts are run, and that the parser's scripting flag is disabled), and should also check that the input document conforms when parsed with a browsing context in which scripts execute, and that the scripts never cause non-conforming states to occur other than transiently during script execution itself. (This is only a "SHOULD" and not a "MUST" requirement because it has been proven to be impossible. [COMPUTABLE]) (I feel like pedanting and pointing out this is untrue ? it has not been proven impossible to do, it has been proven impossible to do in general. It wouldn't be that hard to design a conformance checker to check "<html><script>document.write("<p>")</script>".) On the other hand, a JS console can reasonably report parse errors from script, so the parse errors are still worthwhile to have. /Geoffrey. From simonp at opera.com Sat Sep 7 10:40:08 2013 From: simonp at opera.com (Simon Pieters) Date: Sat, 07 Sep 2013 19:40:08 +0200 Subject: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments In-Reply-To: <5229E9E7.3040404@mit.edu> References: <20130628201946.26920@gmx.com> <CADnb78jxE5B2KTYXj0QBv0GSoGddb=Gbxym5Cp5tYxm7zMG1aA@mail.gmail.com> <522934E9.5070603@mit.edu> <CADnb78iJVBVomf_hiWQOSHc6Umh+UwqjjwKLbathV54XFm3-uQ@mail.gmail.com> <op.w2zojngdidj3kv@simons-macbook-pro.local> <5229E9E7.3040404@mit.edu> Message-ID: <op.w21x0617idj3kv@simons-macbook-pro.local> On Fri, 06 Sep 2013 16:42:47 +0200, Boris Zbarsky <bzbarsky at mit.edu> wrote: > On 9/6/13 8:20 AM, Simon Pieters wrote: >> So the use case is getting an element by id with an "untrusted" id as >> input, in an element or document fragment as opposed to the document? > > Or getting elements by tag name in a document fragment, for that matter > (though "weird" chars in tag names are harder to produce; largely > limited to leading digits). Leading digits in tag names is not possible. Valid tag names in HTML/SVG/MathML all use non-weird chars. -- Simon Pieters Opera Software From kornel at geekhood.net Sun Sep 8 11:11:28 2013 From: kornel at geekhood.net (=?utf-8?B?S29ybmVsIExlc2nFhHNraQ==?=) Date: Sun, 08 Sep 2013 19:11:28 +0100 Subject: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments In-Reply-To: <op.w2zojngdidj3kv@simons-macbook-pro.local> References: <20130628201946.26920@gmx.com> <CADnb78jxE5B2KTYXj0QBv0GSoGddb=Gbxym5Cp5tYxm7zMG1aA@mail.gmail.com> <522934E9.5070603@mit.edu> <CADnb78iJVBVomf_hiWQOSHc6Umh+UwqjjwKLbathV54XFm3-uQ@mail.gmail.com> <op.w2zojngdidj3kv@simons-macbook-pro.local> Message-ID: <op.w23t5ef7te2ec8@aimac.local> On Fri, 06 Sep 2013 13:20:01 +0100, Simon Pieters <simonp at opera.com> wrote: >> Such a function already exists in the wild btw: >> http://mothereff.in/css-escapes > > So the use case is getting an element by id with an "untrusted" id as > input, in an element or document fragment as opposed to the document? I wouldn't call it "untrusted". It's needed to correctly find arbitrary ID. It's not too eccentric to have non-alphanumeric IDs. For example you need to use `[]` in form element name to receive multiple values in PHP, and it makes sense for form-generating libraries to use same name and ID. I don't understand "deprecation" of getElementById(). querySelector('#'+CSS.escapeIdent(id)) is significantly worse: less readable, slower (generates garbage strings) and error-prone (unescaped incorrect use is much easier than the correct use). It's like deprecating indexOf(), because properly-escaped regular expressions can do the same. getElementById() is a very well-known API. It's pretty convenient. It cannot be removed from the platform, so every browser already has to implement it and cost of exposing it on document fragments should be minimal. Maybe it's not "cool", but keeping it away from document fragments buys nothing, and just makes the platform less consistent. -- regards, Kornel From ian at hixie.ch Mon Sep 9 09:33:57 2013 From: ian at hixie.ch (Ian Hickson) Date: Mon, 9 Sep 2013 16:33:57 +0000 (UTC) Subject: [whatwg] Stroking algorithm in Canvas 2d In-Reply-To: <CAGN7qDA-iib4SULW-JDf4_vpsyuxpg1m8AkXq=qgDtY1OkXahA@mail.gmail.com> References: <CAGN7qDA-iib4SULW-JDf4_vpsyuxpg1m8AkXq=qgDtY1OkXahA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309091626010.12210@ps20323.dreamhostps.com> On Thu, 5 Sep 2013, Rik Cabanier wrote: > > we've looked over the algorithm in the Canvas spec that describes how > strokes are computed. [1] > We think that this section is making some incorrect assumptions. For > instance, the dashes are calculated over the total lenght of all subpaths, > but each subpath should be treated separately. That's intentional, otherwise if you stroke an already-dashed line, you get weird results. > It's also a bit strange that the spec is trying to describe how to stroke. It's trying to describe sufficient detail to get interoperable behaviour. > For instance, it goes in minute detail on how dashes are applied but the > hardest part of stroking ("inflating the paths in path perpendicular to the > direction") is not described at all. Is there any ambiguity in the part that's not described? > Wouldn't it be better to remove all these steps and simply show the > desired effect? Yes. I try to do this as much as possible, but whenever I can't figure out a way to describe something declaratively, I describe it imperatively instead. If you have a way to describe it that is as precise, covers all the same cases, yet is declarative, please don't hesitate to suggest it. I unfortunately find that describing things declaratively is usually only able to get one 90% of the way to a complete description. > If not, what would be the best way to fix the wording? What's wrong with the wording? > The mailing list or a bug? Either is fine and equivalent. (Don't do both, though, please!). -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From cabanier at gmail.com Mon Sep 9 12:56:07 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Mon, 9 Sep 2013 12:56:07 -0700 Subject: [whatwg] Stroking algorithm in Canvas 2d In-Reply-To: <alpine.DEB.2.00.1309091626010.12210@ps20323.dreamhostps.com> References: <CAGN7qDA-iib4SULW-JDf4_vpsyuxpg1m8AkXq=qgDtY1OkXahA@mail.gmail.com> <alpine.DEB.2.00.1309091626010.12210@ps20323.dreamhostps.com> Message-ID: <CAGN7qDDgfZmoZvj9JEwzM764LHWivn=nh_WyGfJOX7SdW31vvg@mail.gmail.com> On Mon, Sep 9, 2013 at 9:33 AM, Ian Hickson <ian at hixie.ch> wrote: > On Thu, 5 Sep 2013, Rik Cabanier wrote: > > > > we've looked over the algorithm in the Canvas spec that describes how > > strokes are computed. [1] > > We think that this section is making some incorrect assumptions. For > > instance, the dashes are calculated over the total lenght of all > subpaths, > > but each subpath should be treated separately. > > That's intentional, otherwise if you stroke an already-dashed line, you > get weird results. > As Stephan said, when would this happen? Are you thinking of a case where you did the dashing yourself and then dash/stroke it again? If so, that is expected to give different results. > > > > It's also a bit strange that the spec is trying to describe how to > stroke. > > It's trying to describe sufficient detail to get interoperable behaviour. > > > > For instance, it goes in minute detail on how dashes are applied but the > > hardest part of stroking ("inflating the paths in path perpendicular to > the > > direction") is not described at all. > > Is there any ambiguity in the part that's not described? > Yes. What is "inflating"? A stroked bezier curve is no longer a bezier and has to be calculated. > > > > Wouldn't it be better to remove all these steps and simply show the > > desired effect? > > Yes. I try to do this as much as possible, but whenever I can't figure out > a way to describe something declaratively, I describe it imperatively > instead. If you have a way to describe it that is as precise, covers all > the same cases, yet is declarative, please don't hesitate to suggest it. I > unfortunately find that describing things declaratively is usually only > able to get one 90% of the way to a complete description. > That's certainly reasonable. I looked at several graphics libraries (CoreGraphics, PDF, Postscript, D2D, Cairo) and none of them really say how they stroke. They just show the result of stroking and at best describe how dashing, joins and endcaps should look. Stephan and I can describe how stroking process but are not familiar with writing it down as normative text. > > > > If not, what would be the best way to fix the wording? > > What's wrong with the wording? > > > > The mailing list or a bug? > > Either is fine and equivalent. (Don't do both, though, please!). > :-) We'll continue this on the mailing list. That way it's more visible and people can chime in. From ian at hixie.ch Mon Sep 9 17:00:25 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Sep 2013 00:00:25 +0000 (UTC) Subject: [whatwg] High-density canvases In-Reply-To: <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> On Wed, 17 Jul 2013, Rik Cabanier wrote: > Ian wrote: > > > > The density aspect of this might be pointless, given the failure of > > getImageDataHD(); if we're dropping that one, I'll drop this one at > > the same time. > > Yes, please drop it since the HD methods are going away from the one > implementation. On Tue, 9 Jul 2013, Stephen White wrote: > > Conversely, if it helps to bring the spec closer to the implementations, > one thing we do not intend to implement in Chrome is the automatic > high-DPI canvas scaling (ie., auto-doubling of backing stores, > getImageDataHD(), putImageDataHD(), etc). > > I believe Apple has also announced that they are dropping support for > this in Safari 7. So my understanding is that the reason this feature failed is that there's existing content that assumes a 1:1 ratio, and having an automatic high-density mode was making some pages end up with canvases with four canvas pixels per CSS pixel (linearly) -- two from the browser making a native canvas, times two from the page scaling the canvas for high DPI displays. This is a factor of sixteen over a 1:1 canvas, a factor of four more than it should be for high DPI, and a big waste of resources. As much as sites do this manually, though, it's a huge pain in the neck to have to worry about pixel density when you're creating your canvas and drawing on it, especially if you're not drawing sprites on it. While we're talking about annoying things, there's also the annoyance that canvases tend to not take zoom into account (either density-affecting zoom like page zoom on desktop, or "transparent" zoom like pinch-zoom on mobile for non-mobile-optimised sites, which the site isn't supposed to know about): you have to remember to listen for onresize, and then manually blow away your canvas and recreate it at the right density and then squeeze it into place so that the coordinate space matches what your code is expecting while the <canvas> is actually sized for the display. There's also the issue of full-bleed canvases where every time the container changes, you have to remember to re-update the canvas coordinate space and repaint because otherwise your pretty page gets all warped. It would be nice to fix these all at once, and I think we can, by introducing a configuration option on getContext(), in the style of WebGL: getContext('2d', { density: 'autosize' }); This would trigger the following behaviour: When the context is created, and subsequently when the <canvas> changes size (e.g. due to being sized with CSS relative units and the element they're relative to changing), or when the display density changes size (e.g. due to page zoom), then: - the width and height of the canvas bitmaps get updated to match the new native size of the <canvas>, at native density. - the coordinate space of the canvas (context.width/context.height) gets updated to match the size of the <canvas> in CSS pixel units. - a 'resize' event gets fired at the <canvas>. We would dump the *HD versions of the methods, and make the regular ones go back to returning the actual raw pixels, since that would now work fine and still provide HD-quality content everywhere it's available. What do people think? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jackalmage at gmail.com Mon Sep 9 17:07:30 2013 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Mon, 9 Sep 2013 17:07:30 -0700 Subject: [whatwg] High-density canvases In-Reply-To: <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> Message-ID: <CAAWBYDCY-aCuZUDF+Snh25QNcS7ZkWFQGxgeMKW1MsYf0e_c+w@mail.gmail.com> On Mon, Sep 9, 2013 at 5:00 PM, Ian Hickson <ian at hixie.ch> wrote: > It would be nice to fix these all at once, and I think we can, by > introducing a configuration option on getContext(), in the style of WebGL: > > getContext('2d', { density: 'autosize' }); > > This would trigger the following behaviour: When the context is created, > and subsequently when the <canvas> changes size (e.g. due to being sized > with CSS relative units and the element they're relative to changing), or > when the display density changes size (e.g. due to page zoom), then: > > - the width and height of the canvas bitmaps get updated to match the > new native size of the <canvas>, at native density. > > - the coordinate space of the canvas (context.width/context.height) > gets updated to match the size of the <canvas> in CSS pixel units. > > - a 'resize' event gets fired at the <canvas>. > > We would dump the *HD versions of the methods, and make the regular ones > go back to returning the actual raw pixels, since that would now work fine > and still provide HD-quality content everywhere it's available. > > What do people think? Sounds reasonable to me. Firing a resize directly at the <canvas> is nice and convenient. ~TJ From dino at apple.com Mon Sep 9 17:18:09 2013 From: dino at apple.com (Dean Jackson) Date: Tue, 10 Sep 2013 10:18:09 +1000 Subject: [whatwg] High-density canvases In-Reply-To: <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> Message-ID: <5989691D-4430-4FA0-8E22-BCDD35CC5DC7@apple.com> On 10 Sep 2013, at 10:00 am, Ian Hickson <ian at hixie.ch> wrote: > On Wed, 17 Jul 2013, Rik Cabanier wrote: >> Ian wrote: >>> >>> The density aspect of this might be pointless, given the failure of >>> getImageDataHD(); if we're dropping that one, I'll drop this one at >>> the same time. >> >> Yes, please drop it since the HD methods are going away from the one >> implementation. > > On Tue, 9 Jul 2013, Stephen White wrote: >> >> Conversely, if it helps to bring the spec closer to the implementations, >> one thing we do not intend to implement in Chrome is the automatic >> high-DPI canvas scaling (ie., auto-doubling of backing stores, >> getImageDataHD(), putImageDataHD(), etc). >> >> I believe Apple has also announced that they are dropping support for >> this in Safari 7. > > So my understanding is that the reason this feature failed is that there's > existing content that assumes a 1:1 ratio, and having an automatic > high-density mode was making some pages end up with canvases with four > canvas pixels per CSS pixel (linearly) -- two from the browser making a > native canvas, times two from the page scaling the canvas for high DPI > displays. This is a factor of sixteen over a 1:1 canvas, a factor of four > more than it should be for high DPI, and a big waste of resources. It wasn?t just that. A lot of existing code did something like this: var pixels = ctx.getImageData(0, 0, canvas.width, canvas.height); for (var i = 0; i < canvas.width; i++) { for (var j = 0; j < canvas.height; j++) { pixels[j * canvas.width + i][0] = newRedValue; pixels[j * canvas.width + i][1] = newGreenValue; pixels[j * canvas.width + i][2] = newBlueValue; } } ctx.putImageData(?) i.e. no one read the spec that says you should check the width and height of the returned ImageData. Then there is toDataURL(). Should that return a full-sized bitmap? Then you need to be sure what you?re uploading it to will handle the larger size. Basically, there was pretty unanimous support from Web developers to ?just give us the damn pixels we asked for?, as well as Chrome and Mozilla suggesting they didn?t want to implement the auto-doubling. We (Safari) were in a position where we were requiring developers to write extra code just for us, as well as potentially breaking some (existing) content. > > As much as sites do this manually, though, it's a huge pain in the neck to > have to worry about pixel density when you're creating your canvas and > drawing on it, especially if you're not drawing sprites on it. > > While we're talking about annoying things, there's also the annoyance that > canvases tend to not take zoom into account (either density-affecting zoom > like page zoom on desktop, or "transparent" zoom like pinch-zoom on mobile > for non-mobile-optimised sites, which the site isn't supposed to know > about): you have to remember to listen for onresize, and then manually > blow away your canvas and recreate it at the right density and then > squeeze it into place so that the coordinate space matches what your code > is expecting while the <canvas> is actually sized for the display. Yes, but I think the developer is the one who best knows what size/quality her content requires. A great developer will do exactly as you suggest: constantly examine the rendered size of the canvas (taking into account pixel density and viewport/zoom). > > There's also the issue of full-bleed canvases where every time the > container changes, you have to remember to re-update the canvas coordinate > space and repaint because otherwise your pretty page gets all warped. > > It would be nice to fix these all at once, and I think we can, by > introducing a configuration option on getContext(), in the style of WebGL: > > getContext('2d', { density: 'autosize' }); > > This would trigger the following behaviour: When the context is created, > and subsequently when the <canvas> changes size (e.g. due to being sized > with CSS relative units and the element they're relative to changing), or > when the display density changes size (e.g. due to page zoom), then: > > - the width and height of the canvas bitmaps get updated to match the > new native size of the <canvas>, at native density. > > - the coordinate space of the canvas (context.width/context.height) > gets updated to match the size of the <canvas> in CSS pixel units. Note that this would reset the context, which would throw away the contents and context state. This might be exactly what you want though - put this attribute on a full-bleed canvas and resize your window -> everything disappears unless you implement the ?resize? event handler. > > - a 'resize' event gets fired at the <canvas>. > > We would dump the *HD versions of the methods, and make the regular ones > go back to returning the actual raw pixels, since that would now work fine > and still provide HD-quality content everywhere it's available. > > What do people think? This seems ok to me. I still worry we?ll get into a situation where developers will add density:?autosize? (in order to get the resizing behaviour) and NOT check the results of getImageData - everything will work fine if they never test on a high-dpi screen. Maybe there should be two attributes? Dean From ian at hixie.ch Mon Sep 9 17:31:44 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Sep 2013 00:31:44 +0000 (UTC) Subject: [whatwg] High-density canvases In-Reply-To: <5989691D-4430-4FA0-8E22-BCDD35CC5DC7@apple.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <5989691D-4430-4FA0-8E22-BCDD35CC5DC7@apple.com> Message-ID: <alpine.DEB.2.00.1309100021320.12210@ps20323.dreamhostps.com> On Tue, 10 Sep 2013, Dean Jackson wrote: > > > > So my understanding is that the reason this feature failed is that > > there's existing content that assumes a 1:1 ratio, and having an > > automatic high-density mode was making some pages end up with canvases > > with four canvas pixels per CSS pixel (linearly) -- two from the > > browser making a native canvas, times two from the page scaling the > > canvas for high DPI displays. This is a factor of sixteen over a 1:1 > > canvas, a factor of four more than it should be for high DPI, and a > > big waste of resources. > > It wasn?t just that. A lot of existing code did something like this: > > var pixels = ctx.getImageData(0, 0, canvas.width, canvas.height); > for (var i = 0; i < canvas.width; i++) { > for (var j = 0; j < canvas.height; j++) { > pixels[j * canvas.width + i][0] = newRedValue; > pixels[j * canvas.width + i][1] = newGreenValue; > pixels[j * canvas.width + i][2] = newBlueValue; > } > } > ctx.putImageData(?) > > i.e. no one read the spec that says you should check the width and > height of the returned ImageData. Per spec, that should work fine even in the current spec fiction of automatic high-density canvases, because getImageData() returns CSS-pixel level data (and the putImageData() call scales it up to native res). That's why we added the *HD methods. > Then there is toDataURL(). Should that return a full-sized bitmap? Per spec, it returns the low-res version, with toDataURLHD() for the full version. > Then you need to be sure what you?re uploading it to will handle the > larger size. Right, hence the two versions. > Basically, there was pretty unanimous support from Web developers to > ?just give us the damn pixels we asked for? Agreed. The proposal {density:'autosize'} seems to do that, while avoiding the back-compat issues that prevent the current spec fiction from working in practice. > > While we're talking about annoying things, there's also the annoyance > > that canvases tend to not take zoom into account (either > > density-affecting zoom like page zoom on desktop, or "transparent" > > zoom like pinch-zoom on mobile for non-mobile-optimised sites, which > > the site isn't supposed to know about): you have to remember to listen > > for onresize, and then manually blow away your canvas and recreate it > > at the right density and then squeeze it into place so that the > > coordinate space matches what your code is expecting while the > > <canvas> is actually sized for the display. > > Yes, but I think the developer is the one who best knows what > size/quality her content requires. > > A great developer will do exactly as you suggest: constantly examine the > rendered size of the canvas (taking into account pixel density and > viewport/zoom). Only because they have to. There's basically three cases that I can see: 1. People dealing only with low-density 96dpi graphics, who just want 96dpi canvases (CSS pixel = canvas pixel = coordinate space unit) and that's it. 2. People who want native resolution graphics. 3. People doing crazy complicated stuff. Currently we're supporting #3 and #1, with #1 being the default, and if you want #2 you have to actually do #3. There are authors (e.g. me, but I suspect it's actually a majority of the more casual authoring community) who want high-quality native-resolution graphics, but who don't want to have to jump through hoops to get them. > > This would trigger the following behaviour: When the context is > > created, and subsequently when the <canvas> changes size (e.g. due to > > being sized with CSS relative units and the element they're relative > > to changing), or when the display density changes size (e.g. due to > > page zoom), then: > > > > - the width and height of the canvas bitmaps get updated to match the > > new native size of the <canvas>, at native density. > > > > - the coordinate space of the canvas (context.width/context.height) > > gets updated to match the size of the <canvas> in CSS pixel units. > > Note that this would reset the context, which would throw away the > contents and context state. This might be exactly what you want though - > put this attribute on a full-bleed canvas and resize your window -> > everything disappears unless you implement the ?resize? event handler. Right, resetting the context would definitely be part of the deal. This mode would be specifically defined as a mode where you had to listen to onresize or your canvas would almost certainly get cleared sooner or later. In fact, we could go further, and say that canvases that aren't getting rendered at all (e.g. display:none, off-screen, background tab) can get cleared, with the deal being that next time you need to show the canvas you immediately get an onresize. The more things we have that trigger onresize, the more likely it is that authors won't forget to implement it. > > - a 'resize' event gets fired at the <canvas>. > > > > We would dump the *HD versions of the methods, and make the regular > > ones go back to returning the actual raw pixels, since that would now > > work fine and still provide HD-quality content everywhere it's > > available. > > > > What do people think? > > This seems ok to me. I still worry we?ll get into a situation where > developers will add density:?autosize? (in order to get the resizing > behaviour) and NOT check the results of getImageData - everything will > work fine if they never test on a high-dpi screen. Yeah, my suggestion, if we do this, would be to not do it until high density displays are even more widely available than now. This is mostly a convenience and performance-improving API, not a critical feature add. > Maybe there should be two attributes? What would the two attributes do? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From cabanier at gmail.com Mon Sep 9 17:48:24 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Mon, 9 Sep 2013 17:48:24 -0700 Subject: [whatwg] High-density canvases In-Reply-To: <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> Message-ID: <CAGN7qDC9-KLHa4+UcsLoowkxoCCPeAOutdKsBaz7y0EBmJEYGQ@mail.gmail.com> On Mon, Sep 9, 2013 at 5:00 PM, Ian Hickson <ian at hixie.ch> wrote: > On Wed, 17 Jul 2013, Rik Cabanier wrote: > > Ian wrote: > > > > > > The density aspect of this might be pointless, given the failure of > > > getImageDataHD(); if we're dropping that one, I'll drop this one at > > > the same time. > > > > Yes, please drop it since the HD methods are going away from the one > > implementation. > > On Tue, 9 Jul 2013, Stephen White wrote: > > > > Conversely, if it helps to bring the spec closer to the implementations, > > one thing we do not intend to implement in Chrome is the automatic > > high-DPI canvas scaling (ie., auto-doubling of backing stores, > > getImageDataHD(), putImageDataHD(), etc). > > > > I believe Apple has also announced that they are dropping support for > > this in Safari 7. > > So my understanding is that the reason this feature failed is that there's > existing content that assumes a 1:1 ratio, and having an automatic > high-density mode was making some pages end up with canvases with four > canvas pixels per CSS pixel (linearly) -- two from the browser making a > native canvas, times two from the page scaling the canvas for high DPI > displays. This is a factor of sixteen over a 1:1 canvas, a factor of four > more than it should be for high DPI, and a big waste of resources. > > As much as sites do this manually, though, it's a huge pain in the neck to > have to worry about pixel density when you're creating your canvas and > drawing on it, especially if you're not drawing sprites on it. > > While we're talking about annoying things, there's also the annoyance that > canvases tend to not take zoom into account (either density-affecting zoom > like page zoom on desktop, or "transparent" zoom like pinch-zoom on mobile > for non-mobile-optimised sites, which the site isn't supposed to know > about): you have to remember to listen for onresize, and then manually > blow away your canvas and recreate it at the right density and then > squeeze it into place so that the coordinate space matches what your code > is expecting while the <canvas> is actually sized for the display. > > There's also the issue of full-bleed canvases where every time the > container changes, you have to remember to re-update the canvas coordinate > space and repaint because otherwise your pretty page gets all warped. > > It would be nice to fix these all at once, and I think we can, by > introducing a configuration option on getContext(), in the style of WebGL: > > getContext('2d', { density: 'autosize' }); > > This would trigger the following behaviour: When the context is created, > and subsequently when the <canvas> changes size (e.g. due to being sized > with CSS relative units and the element they're relative to changing), or > when the display density changes size (e.g. due to page zoom), then: > > - the width and height of the canvas bitmaps get updated to match the > new native size of the <canvas>, at native density. > > - the coordinate space of the canvas (context.width/context.height) > gets updated to match the size of the <canvas> in CSS pixel units. > > - a 'resize' event gets fired at the <canvas>. > Will this workflow introduce flickering? > > We would dump the *HD versions of the methods, and make the regular ones > go back to returning the actual raw pixels, since that would now work fine > and still provide HD-quality content everywhere it's available. > > What do people think? > I'm unsure if these calls are really needed. An author can already do this today with a couple of lines of JS. By doing the actual resizing in the event handler, I believe flickering is avoided. I share Dean's worry that it will lead to bad redrawing if people don't test all scenarios that causes resizing. (Temporary canvases would also have to be resized manually) From ian at hixie.ch Mon Sep 9 21:34:28 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Sep 2013 04:34:28 +0000 (UTC) Subject: [whatwg] High-density canvases In-Reply-To: <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> Message-ID: <alpine.DEB.2.00.1309100433100.12210@ps20323.dreamhostps.com> On Tue, 10 Sep 2013, Ian Hickson wrote: > > It would be nice to fix these all at once, and I think we can, by > introducing a configuration option on getContext(), in the style of > WebGL: > > getContext('2d', { density: 'autosize' }); > > This would trigger the following behaviour: When the context is created, > and subsequently when the <canvas> changes size (e.g. due to being sized > with CSS relative units and the element they're relative to changing), > or when the display density changes size (e.g. due to page zoom), then: > > - the width and height of the canvas bitmaps get updated to match the > new native size of the <canvas>, at native density. > > - the coordinate space of the canvas (context.width/context.height) > gets updated to match the size of the <canvas> in CSS pixel units. > > - a 'resize' event gets fired at the <canvas>. > > We would dump the *HD versions of the methods, and make the regular ones > go back to returning the actual raw pixels, since that would now work > fine and still provide HD-quality content everywhere it's available. > > What do people think? Rik pointed out on IRC that it's common to have out-of-DOM canvases, e.g. for storing textures, which would need to track the density of the one in the DOM. I'd have to think about it in more detail, but in principle it seems some sort of slaving mechanism should be able to handle that too. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From senorblanco at chromium.org Tue Sep 10 07:14:40 2013 From: senorblanco at chromium.org (Stephen White) Date: Tue, 10 Sep 2013 10:14:40 -0400 Subject: [whatwg] High-density canvases In-Reply-To: <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> Message-ID: <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> For posterity, here were our objections to the original high-DPI canvas spec: - The API feels like a short-term hack to automagically do something that the developer may or may not want done (e.g., if the game/app was tuned for particular resolution, or for pixel-exact rendering) that we'll be stuck with in the web platform long after its short-term usefulness has expired - It doesn't scale well to non-integer devicePixelRatios - It is easy for developers to implement the above behaviour in JS if desired I think the new proposal addresses the first point, since it's opt-in. I don't think the second point is a problem, since [get|put]ImageData() will be back to manipulating exact backing store pixels, so no non-integer resizing will be required. The third point becomes moot. One question: now that some browsers are including browser zoom (page zoom) in window.devicePixelRatio, will/should the new proposal automatically cause a resize callback on page zoom, in order to preserve 1:1 device pixels? (Note that I think this is a problem with current JS-based implementations of canvas auto-scale as well, although perhaps there's a DOM event for this that you can listen to; I might just be showing my ignorance here.) Stephen On Mon, Sep 9, 2013 at 8:00 PM, Ian Hickson <ian at hixie.ch> wrote: > On Wed, 17 Jul 2013, Rik Cabanier wrote: > > Ian wrote: > > > > > > The density aspect of this might be pointless, given the failure of > > > getImageDataHD(); if we're dropping that one, I'll drop this one at > > > the same time. > > > > Yes, please drop it since the HD methods are going away from the one > > implementation. > > On Tue, 9 Jul 2013, Stephen White wrote: > > > > Conversely, if it helps to bring the spec closer to the implementations, > > one thing we do not intend to implement in Chrome is the automatic > > high-DPI canvas scaling (ie., auto-doubling of backing stores, > > getImageDataHD(), putImageDataHD(), etc). > > > > I believe Apple has also announced that they are dropping support for > > this in Safari 7. > > So my understanding is that the reason this feature failed is that there's > existing content that assumes a 1:1 ratio, and having an automatic > high-density mode was making some pages end up with canvases with four > canvas pixels per CSS pixel (linearly) -- two from the browser making a > native canvas, times two from the page scaling the canvas for high DPI > displays. This is a factor of sixteen over a 1:1 canvas, a factor of four > more than it should be for high DPI, and a big waste of resources. > > As much as sites do this manually, though, it's a huge pain in the neck to > have to worry about pixel density when you're creating your canvas and > drawing on it, especially if you're not drawing sprites on it. > > While we're talking about annoying things, there's also the annoyance that > canvases tend to not take zoom into account (either density-affecting zoom > like page zoom on desktop, or "transparent" zoom like pinch-zoom on mobile > for non-mobile-optimised sites, which the site isn't supposed to know > about): you have to remember to listen for onresize, and then manually > blow away your canvas and recreate it at the right density and then > squeeze it into place so that the coordinate space matches what your code > is expecting while the <canvas> is actually sized for the display. > > There's also the issue of full-bleed canvases where every time the > container changes, you have to remember to re-update the canvas coordinate > space and repaint because otherwise your pretty page gets all warped. > > It would be nice to fix these all at once, and I think we can, by > introducing a configuration option on getContext(), in the style of WebGL: > > getContext('2d', { density: 'autosize' }); > > This would trigger the following behaviour: When the context is created, > and subsequently when the <canvas> changes size (e.g. due to being sized > with CSS relative units and the element they're relative to changing), or > when the display density changes size (e.g. due to page zoom), then: > > - the width and height of the canvas bitmaps get updated to match the > new native size of the <canvas>, at native density. > > - the coordinate space of the canvas (context.width/context.height) > gets updated to match the size of the <canvas> in CSS pixel units. > > - a 'resize' event gets fired at the <canvas>. > > We would dump the *HD versions of the methods, and make the regular ones > go back to returning the actual raw pixels, since that would now work fine > and still provide HD-quality content everywhere it's available. > > What do people think? > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > From junov at google.com Tue Sep 10 07:44:33 2013 From: junov at google.com (Justin Novosad) Date: Tue, 10 Sep 2013 10:44:33 -0400 Subject: [whatwg] High-density canvases In-Reply-To: <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> Message-ID: <CABpaAqRc1y-G_Oh1JgNDFXSZ-7nYMHKX+GJxpenJ1R1-8W9nPg@mail.gmail.com> There is another closely related issue that's been discussed before: adding a redraw callback to 2d canvas. In the past we discussed this for solving the problem of recoverring from a gpu context loss, but it seems there may be better reasons to consider adding a redraw callback such as freeing memory consumed by canvas backing stores that are in background tabs, and re-building the content when needed. This discussion was revived in the past few days on the chromium graphics-dev mailing list: https://groups.google.com/a/chromium.org/forum/?fromgroups#!topic/graphics-dev/CQJXpXxO6dk The idea is still embryonic and we're brainstorming in this chromium issue: crbug.com/287823 I think that discussion should be merged with this thread because a resize event is another case where one may want to redraw. It would be great to solve all of these issues together. On Tue, Sep 10, 2013 at 10:14 AM, Stephen White <senorblanco at chromium.org>wrote: > For posterity, here were our objections to the original high-DPI canvas > spec: > > - The API feels like a short-term hack to automagically do something > that the developer may or may not want done (e.g., if the game/app was > tuned for particular resolution, or for pixel-exact rendering) that > we'll > be stuck with in the web platform long after its short-term usefulness > has > expired > - It doesn't scale well to non-integer devicePixelRatios > - It is easy for developers to implement the above behaviour in JS if > desired > > I think the new proposal addresses the first point, since it's opt-in. I > don't think the second point is a problem, since [get|put]ImageData() will > be back to manipulating exact backing store pixels, so no non-integer > resizing will be required. The third point becomes moot. > > One question: now that some browsers are including browser zoom (page zoom) > in window.devicePixelRatio, will/should the new proposal automatically > cause a resize callback on page zoom, in order to preserve 1:1 device > pixels? (Note that I think this is a problem with current JS-based > implementations of canvas auto-scale as well, although perhaps there's a > DOM event for this that you can listen to; I might just be showing my > ignorance here.) > > Stephen > > > On Mon, Sep 9, 2013 at 8:00 PM, Ian Hickson <ian at hixie.ch> wrote: > > > On Wed, 17 Jul 2013, Rik Cabanier wrote: > > > Ian wrote: > > > > > > > > The density aspect of this might be pointless, given the failure of > > > > getImageDataHD(); if we're dropping that one, I'll drop this one at > > > > the same time. > > > > > > Yes, please drop it since the HD methods are going away from the one > > > implementation. > > > > On Tue, 9 Jul 2013, Stephen White wrote: > > > > > > Conversely, if it helps to bring the spec closer to the > implementations, > > > one thing we do not intend to implement in Chrome is the automatic > > > high-DPI canvas scaling (ie., auto-doubling of backing stores, > > > getImageDataHD(), putImageDataHD(), etc). > > > > > > I believe Apple has also announced that they are dropping support for > > > this in Safari 7. > > > > So my understanding is that the reason this feature failed is that > there's > > existing content that assumes a 1:1 ratio, and having an automatic > > high-density mode was making some pages end up with canvases with four > > canvas pixels per CSS pixel (linearly) -- two from the browser making a > > native canvas, times two from the page scaling the canvas for high DPI > > displays. This is a factor of sixteen over a 1:1 canvas, a factor of four > > more than it should be for high DPI, and a big waste of resources. > > > > As much as sites do this manually, though, it's a huge pain in the neck > to > > have to worry about pixel density when you're creating your canvas and > > drawing on it, especially if you're not drawing sprites on it. > > > > While we're talking about annoying things, there's also the annoyance > that > > canvases tend to not take zoom into account (either density-affecting > zoom > > like page zoom on desktop, or "transparent" zoom like pinch-zoom on > mobile > > for non-mobile-optimised sites, which the site isn't supposed to know > > about): you have to remember to listen for onresize, and then manually > > blow away your canvas and recreate it at the right density and then > > squeeze it into place so that the coordinate space matches what your code > > is expecting while the <canvas> is actually sized for the display. > > > > There's also the issue of full-bleed canvases where every time the > > container changes, you have to remember to re-update the canvas > coordinate > > space and repaint because otherwise your pretty page gets all warped. > > > > It would be nice to fix these all at once, and I think we can, by > > introducing a configuration option on getContext(), in the style of > WebGL: > > > > getContext('2d', { density: 'autosize' }); > > > > This would trigger the following behaviour: When the context is created, > > and subsequently when the <canvas> changes size (e.g. due to being sized > > with CSS relative units and the element they're relative to changing), or > > when the display density changes size (e.g. due to page zoom), then: > > > > - the width and height of the canvas bitmaps get updated to match the > > new native size of the <canvas>, at native density. > > > > - the coordinate space of the canvas (context.width/context.height) > > gets updated to match the size of the <canvas> in CSS pixel units. > > > > - a 'resize' event gets fired at the <canvas>. > > > > We would dump the *HD versions of the methods, and make the regular ones > > go back to returning the actual raw pixels, since that would now work > fine > > and still provide HD-quality content everywhere it's available. > > > > What do people think? > > > > -- > > Ian Hickson U+1047E )\._.,--....,'``. fL > > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > > > From dino at apple.com Tue Sep 10 11:55:25 2013 From: dino at apple.com (Dean Jackson) Date: Wed, 11 Sep 2013 04:55:25 +1000 Subject: [whatwg] High-density canvases In-Reply-To: <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> Message-ID: <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> On 11 Sep 2013, at 12:14 am, Stephen White <senorblanco at chromium.org> wrote: > now that some browsers are including browser zoom (page zoom) in window.devicePixelRatio Ouch. Who is doing this and why? Dean From bzbarsky at MIT.EDU Tue Sep 10 12:02:33 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Tue, 10 Sep 2013 15:02:33 -0400 Subject: [whatwg] High-density canvases In-Reply-To: <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> Message-ID: <522F6CC9.6020405@mit.edu> On 9/10/13 2:55 PM, Dean Jackson wrote: > Ouch. Who is doing this and why? Any browser in which zoom changes the size of a CSS pixel, and because that's the definition of devicePixelRatio? -Boris From ian at hixie.ch Tue Sep 10 12:32:10 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Sep 2013 19:32:10 +0000 (UTC) Subject: [whatwg] High-density canvases In-Reply-To: <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> Message-ID: <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> On Wed, 11 Sep 2013, Dean Jackson wrote: > On 11 Sep 2013, at 12:14 am, Stephen White <senorblanco at chromium.org> > wrote: > > > > now that some browsers are including browser zoom (page zoom) in > > window.devicePixelRatio > > Ouch. Who is doing this and why? Why ouch? Actually what I really think we should do is also change the window.devicePixelRatio for pinch zoom. Combined with the suggestions for canvas, that would allow (as Rik pointed out on IRC) for high-quality canvas all the way zoomed in, and for cheap canvases when zoomed out. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 10 12:34:23 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Sep 2013 19:34:23 +0000 (UTC) Subject: [whatwg] URL resolution of fragment urls in html5 webapps In-Reply-To: <CAO9zZYOuSfkkGbqFWeeJ-gu1k0mZLFfnjrgkiweL+EN9aGGoiw@mail.gmail.com> References: <CAO9zZYMo79Dqn-EK8S0j-M9sNJeFEGQg_XgP6+fsszDmq5oDMQ@mail.gmail.com> <CANr5HFXkxQuiy+n1jDkd=jP92Wz=E0_BrGbo40A0xxjpbAw2dQ@mail.gmail.com> <CAO9zZYOuSfkkGbqFWeeJ-gu1k0mZLFfnjrgkiweL+EN9aGGoiw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309100013320.12199@ps20323.dreamhostps.com> On Tue, 9 Jul 2013, Igor Minar wrote: > > The current url resolution as described in the spec results in some > unhelpful behavior when the following combination of web technologies > are used in a client-side web app: > > - a combination of path-relative urls (<a > href="relative/url/to/somewhere">link</a>) and fragment/anchor urls (<a > href="#anchorUrl">link</a>) > - history.pushState - used for deep-linking > - base[href] - used to properly resolve the relative urls to the root of > the application in various deployment environments > > Once history.pushState is used to change location.href, the > path-relative urls resolve correctly as expected against the base[href], > but anchor urls that are only useful if resolved against the current > document.baseURI also unsurprisingly resolve against the base[href]. The fragment identifiers resolve that way before the pushState(), too. > This behavior makes them unsuitable for this kind of applications which > is a big loss in developers toolbox and in fact breaks existing web > features like svg that depend on anchor urls to reference nodes in the > current document. How do they work in SVG with a <base> with no pushState()? http://hixie.ch/tests/adhoc/svg/use/001-with-base.html In Safari and Firefox, the relative URLs, even in SVG, are affected by <base>, so again, it seems it's <base> that is relevant here, not pushState(). (In Chrome, some URLs are resolved locally and some not, which is wacked.) > Does anyone have thoughts on how one could build a client-side app that > can be deployed in various contexts without any special server-side > templating or build-time pre-processing? > > The base element looks like a perfect solution for this, if only it > didn't break anchor urls. Use only site-absolute URLs, and not <base>, and then everything will work fine, as far as I can tell. On Wed, 10 Jul 2013, Alex Russell wrote: > > Was just discussing this with Rafael, and it seems like the core issue > you're flagging is that if a document has a <base> element, all #anchor > navigations (which would otherwise be document relative) are now > full-page navigations to the URL specified in the <base>, not the > document's "natural" URL. Is that right? > > If so, we might be able give you some control over this in the > Navigation Controller (although it's not currently scoped as many folks > didn't want to contemplate in-document navigation for the time being). > > But perhaps we don't need to do that: is the current behavior the same > across browsers? If it's not, we might be able to change the spec. If it > is, it'll be harder. It seems pretty consistent. On Wed, 10 Jul 2013, Rafael Weinstein wrote: > > I'm curious: Is it useful to have fragment URL resolve against anything > other than the "display" url? I.e. when is the current behavior wrt > fragments appropriate. It's a good question. I thought the old IETF specs for URLs said you had to do otherwise, but nobody seems to have implemented that. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From dino at apple.com Tue Sep 10 12:45:13 2013 From: dino at apple.com (Dean Jackson) Date: Wed, 11 Sep 2013 05:45:13 +1000 Subject: [whatwg] High-density canvases In-Reply-To: <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> Message-ID: <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> On 11 Sep 2013, at 5:32 am, Ian Hickson <ian at hixie.ch> wrote: > On Wed, 11 Sep 2013, Dean Jackson wrote: >> On 11 Sep 2013, at 12:14 am, Stephen White <senorblanco at chromium.org> >> wrote: >>> >>> now that some browsers are including browser zoom (page zoom) in >>> window.devicePixelRatio >> >> Ouch. Who is doing this and why? > > Why ouch? Because we?ve always operated under the assumption that devicePixelRatio is the mapping from CSS px to device pixels at 1:1 scale/zoom, and that it is constant for a particular display. The only change content would see is if the window is dragged to/from a high resolution screen. There are other ways to query the page zoom. I fear this will break existing content. I don?t think we?d ever want to change the behaviour. Dean > > Actually what I really think we should do is also change the > window.devicePixelRatio for pinch zoom. Combined with the suggestions for > canvas, that would allow (as Rik pointed out on IRC) for high-quality > canvas all the way zoomed in, and for cheap canvases when zoomed out. From ian at hixie.ch Tue Sep 10 12:54:31 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Sep 2013 19:54:31 +0000 (UTC) Subject: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use In-Reply-To: <CADnb78iniuYkyc4cH+RECg1p=ANVQPMz_sod9_Q11C=YDN=ZXg@mail.gmail.com> References: <514A7477.6040905@mit.edu> <alpine.DEB.2.00.1307121809430.15729@ps20323.dreamhostps.com> <51E04C76.30200@mit.edu> <CAJE5ia_WTqejajPZVxf=cxTipvPyE=g0FWQfj-kJaj1tK583kw@mail.gmail.com> <51E04FDD.2080702@mit.edu> <CADnb78iniuYkyc4cH+RECg1p=ANVQPMz_sod9_Q11C=YDN=ZXg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309101934520.12199@ps20323.dreamhostps.com> On Fri, 12 Jul 2013, Boris Zbarsky wrote: > On 7/12/13 2:15 PM, Ian Hickson wrote: > > > > > > The "document's referrer" is not really defined anywhere in a useful > > > way that I can find. > > > > What's not useful about the way it's defined? It's set to a specific > > string. > > I couldn't find where it was normatively set to anything. It's normatively set in two places. For the about:blank Document, it's set (if necessary) here: # If the browsing context has a creator Document, then the browsing # context's Document's referrer must be set to the address of that creator # Document at the time of the browsing context's creation. -- http://whatwg.org/html#windows For regular Documents, it's set in the "Creating a new Document object" steps: # Set the document's referrer to the address of the resource from which # Request-URIs are obtained as determined when the fetch algorithm # obtained the resource, if that algorithm was used and determined such a # value; otherwise, set it to the empty string. -- http://whatwg.org/html#create-a-document-object These seem like the logical places for it to be set. Am I missing something? > > > In cases when the hostname is non-ASCII, the Referer header will > > > have it encoded in punycode. > > > > Is that defined anywhere? > > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36 which > defines it syntactically as a URI, which means that if you have an IRI > you have to convert it to an IRI before putting it in there. That's normatively imported by the HTML spec's "fetch" algorithm, so it's the case per HTML too. Specifically, HTML just says to generate the Referer header's value "as required by HTTP" using a particular URL as the input. > > That's correct per spec (assuming the punycoding is required > > anywhere). The latter two are set separately than document.referrer: > > > > http://whatwg.org/html/#set-the-document's-address > > The thing is, people are comparing origins from postMessage to origins > from document.referrer. See > <https://bugzilla.mozilla.org/show_bug.cgi?id=852796#c6>. Also see > <https://bugzilla.mozilla.org/show_bug.cgi?id=720331>. Well, then they'll be broken, I guess. (They'll break safe, though.) > Also, as a note, nothing above makes it particularly clear that "the URL > that was originally to be fetched" is not already punycode... Ah, well. It might be, depends on what the URL is. > > If other browsers don't match this, file bugs on them. :-) > > <shrug>. It probably won't do much good, but: > > http://code.google.com/p/chromium/issues/detail?id=259920&thanks=259920&ts=1373653828 > > https://bugs.webkit.org/show_bug.cgi?id=118611 Thanks. On Fri, 12 Jul 2013, Adam Barth wrote: > > I don't think we're likely to change this behavior. We always use > punycode for URLs except in the location bar. Why? On Fri, 12 Jul 2013, Boris Zbarsky wrote: > On 7/12/13 2:40 PM, Adam Barth wrote: > > Why not change Firefox to use punycode in window.location? > > If nothing else because that seems user-hostile (both to web developers > examining location values and users who are shown document.URL or > location.href in web pages). Yeah... On Fri, 12 Jul 2013, Anne van Kesteren wrote: > > But then we shouldn't garble pathname either and we do because we have > to. So I'm not sure that line of reasoning makes sense. I do think we > should offer some kind of conversion utility between the two. It is unfortunate that resolving URLs does that, it's true. But just because we're constrained here, why should we mess up domains also? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 10 13:13:02 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Sep 2013 20:13:02 +0000 (UTC) Subject: [whatwg] High-density canvases In-Reply-To: <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> Message-ID: <alpine.DEB.2.00.1309102011560.12210@ps20323.dreamhostps.com> On Wed, 11 Sep 2013, Dean Jackson wrote: > On 11 Sep 2013, at 5:32 am, Ian Hickson <ian at hixie.ch> wrote: > > On Wed, 11 Sep 2013, Dean Jackson wrote: > >> On 11 Sep 2013, at 12:14 am, Stephen White <senorblanco at chromium.org> > >> wrote: > >>> > >>> now that some browsers are including browser zoom (page zoom) in > >>> window.devicePixelRatio > >> > >> Ouch. Who is doing this and why? > > > > Why ouch? > > Because we?ve always operated under the assumption that devicePixelRatio > is the mapping from CSS px to device pixels at 1:1 scale/zoom, and that > it is constant for a particular display. The only change content would > see is if the window is dragged to/from a high resolution screen. > > There are other ways to query the page zoom. That seems broken... why would you want to hide the page zoom? > I fear this will break existing content. I don?t think we?d ever want to > change the behaviour. I guess we'll just have to treat devicePixelRatio as legacy and introduce a new value that's the real device:pixel ratio, then. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 10 13:14:06 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Sep 2013 20:14:06 +0000 (UTC) Subject: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use In-Reply-To: <alpine.DEB.2.00.1309101934520.12199@ps20323.dreamhostps.com> References: <514A7477.6040905@mit.edu> <alpine.DEB.2.00.1307121809430.15729@ps20323.dreamhostps.com> <51E04C76.30200@mit.edu> <CAJE5ia_WTqejajPZVxf=cxTipvPyE=g0FWQfj-kJaj1tK583kw@mail.gmail.com> <51E04FDD.2080702@mit.edu> <CADnb78iniuYkyc4cH+RECg1p=ANVQPMz_sod9_Q11C=YDN=ZXg@mail.gmail.com> <alpine.DEB.2.00.1309101934520.12199@ps20323.dreamhostps.com> Message-ID: <alpine.DEB.2.00.1309102013220.12210@ps20323.dreamhostps.com> On Tue, 10 Sep 2013, Ian Hickson wrote: > > > > > > > > In cases when the hostname is non-ASCII, the Referer header will > > > > have it encoded in punycode. > > > > > > Is that defined anywhere? > > > > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36 which > > defines it syntactically as a URI, which means that if you have an IRI > > you have to convert it to an IRI before putting it in there. > > That's normatively imported by the HTML spec's "fetch" algorithm, so > it's the case per HTML too. Specifically, HTML just says to generate the > Referer header's value "as required by HTTP" using a particular URL as > the input. Incidentally, Anne, fetch.spec.whatwg.org seems to have omitted the dependency on HTTP so this is broken there, if I'm not mistaken. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From dino at apple.com Tue Sep 10 13:22:51 2013 From: dino at apple.com (Dean Jackson) Date: Wed, 11 Sep 2013 06:22:51 +1000 Subject: [whatwg] High-density canvases In-Reply-To: <alpine.DEB.2.00.1309102011560.12210@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> <alpine.DEB.2.00.1309102011560.12210@ps20323.dreamhostps.com> Message-ID: <BBF7063D-027A-48C5-92CD-F5EF829BC800@apple.com> On 11 Sep 2013, at 6:13 am, Ian Hickson <ian at hixie.ch> wrote: > On Wed, 11 Sep 2013, Dean Jackson wrote: >> On 11 Sep 2013, at 5:32 am, Ian Hickson <ian at hixie.ch> wrote: >>> On Wed, 11 Sep 2013, Dean Jackson wrote: >>>> On 11 Sep 2013, at 12:14 am, Stephen White <senorblanco at chromium.org> >>>> wrote: >>>>> >>>>> now that some browsers are including browser zoom (page zoom) in >>>>> window.devicePixelRatio >>>> >>>> Ouch. Who is doing this and why? >>> >>> Why ouch? >> >> Because we?ve always operated under the assumption that devicePixelRatio >> is the mapping from CSS px to device pixels at 1:1 scale/zoom, and that >> it is constant for a particular display. The only change content would >> see is if the window is dragged to/from a high resolution screen. >> >> There are other ways to query the page zoom. > > That seems broken... why would you want to hide the page zoom? We don?t want to hide page zoom. I think there are two separate things a developer might want: - the number of actual pixels that correspond to 1 CSS px without zoom - the page zoom If you merge the two, then an unsuspecting developer might think that the user has zoomed in by 2x on an iPhone, and decide to make things smaller. Yes, that?s not necessarily great content, but it makes some sense. For most page content you don?t really care about the device:pixel ratio - text looks fine! For images, you should use the mechanisms we?ve developed (srcset and image-set). Now, I completely agree that there are going to be cases where you might want the image selected for srcset and image-set to respond to zoom. After all, there is no point loading a huge image if it is going to be 1x1 cm^2. But I think that?s separate from changing devicePixelRatio. >> I fear this will break existing content. I don?t think we?d ever want to >> change the behaviour. > > I guess we'll just have to treat devicePixelRatio as legacy and introduce > a new value that's the real device:pixel ratio, then. Indeed. I?m not opposed to exposing this. I am reluctant to change something that has behaved a particular way for a number of years. Meanwhile, back to canvas, why don?t we change canvas to be purely callback based, and pass in all the info a developer needs to decide what the best output should be? Put something like requestAnimationFrame into the canvas spec (although that is a bad name - it only sometimes is related to animation). That way you could even imagine a future where a single canvas could have multiple render targets (when printing you get an even higher resolution). Dean From cabanier at gmail.com Tue Sep 10 13:26:23 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 10 Sep 2013 13:26:23 -0700 Subject: [whatwg] High-density canvases In-Reply-To: <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> Message-ID: <CAGN7qDCC=8EZUpEmN=10tcWGU=8TPQ7rej+sOGhbPaWqqAjWRA@mail.gmail.com> On Tue, Sep 10, 2013 at 12:45 PM, Dean Jackson <dino at apple.com> wrote: > > On 11 Sep 2013, at 5:32 am, Ian Hickson <ian at hixie.ch> wrote: > > > On Wed, 11 Sep 2013, Dean Jackson wrote: > >> On 11 Sep 2013, at 12:14 am, Stephen White <senorblanco at chromium.org> > >> wrote: > >>> > >>> now that some browsers are including browser zoom (page zoom) in > >>> window.devicePixelRatio > >> > >> Ouch. Who is doing this and why? > > > > Why ouch? > > Because we?ve always operated under the assumption that devicePixelRatio > is the mapping from CSS px to device pixels at 1:1 scale/zoom, and that it > is constant for a particular display. The only change content would see is > if the window is dragged to/from a high resolution screen. > > There are other ways to query the page zoom. > > I fear this will break existing content. I don?t think we?d ever want to > change the behaviour. There's a thread on www-style: http://lists.w3.org/Archives/Public/www-style/2012Nov/0144.html It's been in firefox for a while and blink is going to ship it soon: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/RyUSi3zdumQ > > > > > > Actually what I really think we should do is also change the > > window.devicePixelRatio for pinch zoom. Combined with the suggestions for > > canvas, that would allow (as Rik pointed out on IRC) for high-quality > > canvas all the way zoomed in, and for cheap canvases when zoomed out > I believe pinch zoom should not change devicePixelRatio. It would be nice if there was a standard way to determine pinch zoom though and if the canvas could automatically resize. From bzbarsky at MIT.EDU Tue Sep 10 13:32:22 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Tue, 10 Sep 2013 16:32:22 -0400 Subject: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use In-Reply-To: <alpine.DEB.2.00.1309101934520.12199@ps20323.dreamhostps.com> References: <514A7477.6040905@mit.edu> <alpine.DEB.2.00.1307121809430.15729@ps20323.dreamhostps.com> <51E04C76.30200@mit.edu> <CAJE5ia_WTqejajPZVxf=cxTipvPyE=g0FWQfj-kJaj1tK583kw@mail.gmail.com> <51E04FDD.2080702@mit.edu> <CADnb78iniuYkyc4cH+RECg1p=ANVQPMz_sod9_Q11C=YDN=ZXg@mail.gmail.com> <alpine.DEB.2.00.1309101934520.12199@ps20323.dreamhostps.com> Message-ID: <522F81D6.1060909@mit.edu> On 9/10/13 3:54 PM, Ian Hickson wrote: > These seem like the logical places for it to be set. Am I missing > something? No, you're not. I was. > Well, then they'll be broken, I guess. (They'll break safe, though.) Well, the outcome is "user can't use site". (Which they care more about than whether the site is safe or not, too, though the safety bit is not relevant to the discussion per se.) > It might be, depends on what the URL is. Basically, if we want interop on this stuff we need to define which things get punycoded where and which things are stored as ACE instead and whatnot. :( -Boris From bzbarsky at MIT.EDU Tue Sep 10 13:33:02 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Tue, 10 Sep 2013 16:33:02 -0400 Subject: [whatwg] High-density canvases In-Reply-To: <alpine.DEB.2.00.1309102011560.12210@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> <alpine.DEB.2.00.1309102011560.12210@ps20323.dreamhostps.com> Message-ID: <522F81FE.3080708@mit.edu> On 9/10/13 4:13 PM, Ian Hickson wrote: > I guess we'll just have to treat devicePixelRatio as legacy and introduce > a new value that's the real device:pixel ratio, then. I would be interested in some data on what different UAs do with devicePixelRatio... -Boris From bzbarsky at MIT.EDU Tue Sep 10 13:36:06 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Tue, 10 Sep 2013 16:36:06 -0400 Subject: [whatwg] High-density canvases In-Reply-To: <BBF7063D-027A-48C5-92CD-F5EF829BC800@apple.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> <alpine.DEB.2.00.1309102011560.12210@ps20323.dreamhostps.com> <BBF7063D-027A-48C5-92CD-F5EF829BC800@apple.com> Message-ID: <522F82B6.7090605@mit.edu> On 9/10/13 4:22 PM, Dean Jackson wrote: > I think there are two separate things a developer might want: > > - the number of actual pixels that correspond to 1 CSS px without zoom What are the use cases for this, as opposed to "number of actual pixels that correspond to 1 CSS px"? And are you talking about the sort of zoom that changes layout (because it changes the number of CSS px per device px and hence changes font rasterization), or the sort that does not (which basically does a zoom without changing font metrics)? > - the page zoom Which one? > Indeed. I?m not opposed to exposing this. I am reluctant to change something that has behaved a particular way for a number of years. Shipping UAs already disagree on how devicePixelRatio works with zoom. They also disagree on how zoom behaves in general. -Boris From ian at hixie.ch Tue Sep 10 13:37:10 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Sep 2013 20:37:10 +0000 (UTC) Subject: [whatwg] High-density canvases In-Reply-To: <BBF7063D-027A-48C5-92CD-F5EF829BC800@apple.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> <alpine.DEB.2.00.1309102011560.12210@ps20323.dreamhostps.com> <BBF7063D-027A-48C5-92CD-F5EF829BC800@apple.com> Message-ID: <alpine.DEB.2.00.1309102032170.12210@ps20323.dreamhostps.com> On Wed, 11 Sep 2013, Dean Jackson wrote: > > I think there are two separate things a developer might want: > > - the number of actual pixels that correspond to 1 CSS px without zoom > - the page zoom Why? Exposing page zoom separately from device density seems like a fundamental abstraction failure. What's the difference between page zoom and native density? > If you merge the two, then an unsuspecting developer might think that > the user has zoomed in by 2x on an iPhone, and decide to make things > smaller. That's precisely why we should never make page zoom detectable. The entire point of zooming is that the author should _not_ make things smaller. Zooming should make CSS pixels bigger. Authors should always treat CSS pixels as the core unit, so if something should be 10 CSS pixels wide, then that's what the author should do. If the user happens to have zoomed in so that those 10 pixels are 30cm across, then that's what the user wants -- why would the author be able to override that? > Yes, that?s not necessarily great content, but it makes some sense. What sense does it make? > For most page content you don?t really care about the device:pixel ratio > - text looks fine! For images, you should use the mechanisms we?ve > developed (srcset and image-set). Well the context here is canvas, right? > Now, I completely agree that there are going to be cases where you might > want the image selected for srcset and image-set to respond to zoom. Not edge cases, they're pretty core cases. srcset="" should definitely be influenced by page zoom, there's no question there. Otherwise, users who zoom in will get low quality images, which defeats the whole point. > After all, there is no point loading a huge image if it is going to be > 1x1 cm^2. But I think that?s separate from changing devicePixelRatio. Why? > >> I fear this will break existing content. I don?t think we?d ever want > >> to change the behaviour. > > > > I guess we'll just have to treat devicePixelRatio as legacy and > > introduce a new value that's the real device:pixel ratio, then. > > Indeed. I?m not opposed to exposing this. I am reluctant to change > something that has behaved a particular way for a number of years. > > Meanwhile, back to canvas, why don?t we change canvas to be purely > callback based, and pass in all the info a developer needs to decide > what the best output should be? Put something like requestAnimationFrame > into the canvas spec (although that is a bad name - it only sometimes is > related to animation). That way you could even imagine a future where a > single canvas could have multiple render targets (when printing you get > an even higher resolution). I'm not really understanding what you're proposing here. Can you elaborate? What's the problem this is trying to solve? How would this work in a multi-worker environment? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 10 13:40:36 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Sep 2013 20:40:36 +0000 (UTC) Subject: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use In-Reply-To: <522F81D6.1060909@mit.edu> References: <514A7477.6040905@mit.edu> <alpine.DEB.2.00.1307121809430.15729@ps20323.dreamhostps.com> <51E04C76.30200@mit.edu> <CAJE5ia_WTqejajPZVxf=cxTipvPyE=g0FWQfj-kJaj1tK583kw@mail.gmail.com> <51E04FDD.2080702@mit.edu> <CADnb78iniuYkyc4cH+RECg1p=ANVQPMz_sod9_Q11C=YDN=ZXg@mail.gmail.com> <alpine.DEB.2.00.1309101934520.12199@ps20323.dreamhostps.com> <522F81D6.1060909@mit.edu> Message-ID: <alpine.DEB.2.00.1309102038110.12210@ps20323.dreamhostps.com> On Tue, 10 Sep 2013, Boris Zbarsky wrote: > On 9/10/13 3:54 PM, Ian Hickson wrote: > > > > > [some sites compare values that are always-punycoded domains with > > > values that can be full Unicode for security checks] > > > > Well, then they'll be broken, I guess. (They'll break safe, though.) > > Well, the outcome is "user can't use site". (Which they care more about > than whether the site is safe or not, too, though the safety bit is not > relevant to the discussion per se.) Do you have a concrete example I can look at here? I agree we should make this interoperable. > > It might be, depends on what the URL is. > > Basically, if we want interop on this stuff we need to define which > things get punycoded where and which things are stored as ACE instead > and whatnot. :( Agreed. I think we have (if it doesn't say to punycode, don't punycode; nothing ever unpunycodes). The current definitions might not be always what we want, but I think to the extent that they are not, we need to study concrete examples to see what we should do. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 10 14:22:12 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Sep 2013 21:22:12 +0000 (UTC) Subject: [whatwg] Forcing orientation in content In-Reply-To: <op.wz8k70f4te2ec8@aimac> References: <516F27BF.4060508@gmail.com> <alpine.DEB.2.00.1307121944480.15729@ps20323.dreamhostps.com> <420FE1A33AB14ACB9667D659D8F415D5@gmail.com> <op.wz8k70f4te2ec8@aimac> Message-ID: <alpine.DEB.2.00.1309102107450.12199@ps20323.dreamhostps.com> On Fri, 12 Jul 2013, Glenn Maynard wrote: > On Fri, Jul 12, 2013 at 2:45 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > Why? As a user on desktop, I can resize my window however I want, to > > be landscape or portrait. Why wouldn't I be allowed to do the same on > > any other device? > > In mobile accelerometer/gyro-based games, you don't want the user's > shifting the device around to cause the screen to change orientation > while they're playing. This means locking the current orientation, > though, rather than a specific orientation (for example, you'd probably > want to unlock it when the user is in a menu and not actually playing > the game). I could see locking the orientation in full-screen mode, sure (as Kornel suggested in a later e-mail, see below). > On Fri, Jul 12, 2013 at 7:07 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > Sure, some orientations might be better -- just like the HTML spec is > > more readable on a taller large screen than on a landscape phone > > screen -- but if the user wants to play the other way, it seems wrong > > to be able to prevent it. > > In practice, game developers are rarely willing to spend the time to > make their games work well in both portrait and landscape. That's certainly true, but the reality is that on the Web a web browser window might be any number of dimensions, so that's a problem you have to deal with regardless. > The Web solution is probably not to lock the display, though, but to > letterbox the display if the window's aspect ratio is too far off, as > with videos. Well, not so much letterbox as just fit in the given width, leaving a lot of space at the bottom (or centering vertically), sure. On Fri, 12 Jul 2013, Jonas Sicking wrote: > On Fri, Jul 12, 2013 at 12:45 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Thu, 18 Apr 2013, David Bruant wrote: > >> > >> Currently working on a web project where tablet support (iPad > >> especially) is important, I'm facing a need which apparently the > >> platform doesn't support. I would need to lock the screen in > >> landscape mode. > > > > Why? As a user on desktop, I can resize my window however I want, to > > be landscape or portrait. Why wouldn't I be allowed to do the same on > > any other device? > > If the content is sized better for portrait or landscape, then it's > generally good for the user if the mode is forced by the application. I disagree. The author doens't know better than I do what I want. > Otherwise the user will have to scroll, or will see content that is > smaller than it otherwise would be. Or rotate the device, which the user will have to do regardless if the application forces it. > Users can't always rotate the screen themselves to control this since > many times users disable screen rotation controlled by gravity. If the user disables it, the user can just as easily re-enable it... Also, if the user disabled it, I think it's even more of a reason not to rotate the display for the user. > Common cases when this is done is if they find that the screen too often > erratically rotates due to the user moving around the device. Another > scenario is if laying down with the device in bed in which case rotating > according to gravity will result in a screen that is off by 90 degrees > from the users orientation. Indeed. > The reason we don't do this on desktop systems is that desktop platforms > generally don't let the user adjust to an application rendering itself > sideways to fit in the current window size. On tablets and mobile > platforms, there is an established UI paradigm of simply rotating the > device when content renders itself sideways. A quite annoying UI paradigm... > If we don't provide webplatform support for setting orientation, content > will simply use things like CSS transformation to render itself > sideways. This results in a much poorer experience for the user since it > interacts poorly with for example gravitational orientation. I.e. the > user might see the content sideways, then rotate the device in order to > see the content correctly, resulting in the device then changing > rendering orientation. The page will then detect this and undo the > transformation. The result is a lot of back and forth which is > disruptive to the user. Any automatic rotation not under the control of the user, or locking of rotation not under the control of the user, is disruptive to the user. > Another problem that is likely to occur is authors accidentally applying > CSS transformation in on devices where the user can't reorient the > device. > > Not to mention that using CSS transformation will likely result in > content that has to use more javascript driven layout with all the > downsides that come with that. I'm certainly not advocating for authors manually rotating the content to be at 90 degrees to the device's native orientation. > By supporting pages setting the orientation we can put the user more in > charge by ignoring that orientation when appropriate. Such as on devices > where changing the orientation is bad, or when the user has explicitly > requested the orientation not to change. I'm confused as to what UI you are envisaging here. Would this be in addition to, or instead of, the native UI to prevent rotation? > In Firefox we have implemented the screen orientation spec > https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html That is unfortuate. I don't think that API puts the user first. (I also don't understand what it means in non-mobile environments. It seems very medium-specific, which is not very Webby.) > However I personally would like to see declarative support in addition > to the script API. Can you elaborate on what user problems we are solving here and what such a declarative mechanism would look like? On Mon, 15 Jul 2013, Roger H?gensen wrote: > On 2013-07-13 06:17, Glenn Maynard wrote: > > > > Changing orientation is disruptive. > > > > I can hardly imagine how obnoxious Web browsing would be on a mobile > > device, if every second page I navigated to decided to flip my device > > to a different orientation. This feels like the same sort of > > misfeature as allowing pages to resize the browser window: "best > > viewed in 800x600" (so we'll force it), "best viewed in portrait" (so > > we'll force it). > > I have a tablet here that does that with a few apps. And one of them > actually does it within itself during certain parts of the program. > > And I can testify it's annoying as hell. For those curious it was a > banking app. And the main menu is forced/locked. But the rest like > account activity etc. is not. And you can imagine how stupid it is when > you have to rotate the tablet each time you go back to the main menu. Indeed. > I find responsive and scalable design (so it looks good) on multiple > aspects ratios and multiple PPIs is a must for modern coding. I agree. It also seems to be the only way to actually make things work on some media, such as desktop windows, which can't be rotated yet can have any aspect ratio. On Sat, 13 Jul 2013, Tobie Langel wrote: > > It is not uncommon for mobile experiences to rely on the accelerometer > as an input mechanism, for example to control page scrolling (e.g. > Instapaper) or for gameplay. > > In such cases, auto-rotation of the viewport is completely disruptive to > the user's experience and needs to be inhibited. Sure, but that's an OS-level feature. > So this isn't so much about forcing orientation as it is about > inhibiting auto-rotation. This would only work if the page was already in the orientation the user wants, but how can we ensure that? > Your desktop comparison is inadequate, as there aren't comparable > auto-rotation mechanisms there. It would be equivalent to forcing a particular window size. On Mon, 15 Jul 2013, Kornel Lesi?ski wrote: > > Since specific, locked screen orientation is mostly needed in games, and > forced rotation is disruptive to other things on the screen (e.g. moving > buttons/addressbar to other physical edge of the screen), maybe it > should be tied to the Fullscreen API? > > element.requestFullscreen({orientation:'landscape', autorotation:false}) That makes sense to me. Anne? In any case, this seems to be out of scope of HTML, so I haven't added anything to the HTML spec. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 10 14:28:32 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Sep 2013 21:28:32 +0000 (UTC) Subject: [whatwg] scrdoc and session history don't play along in the spec In-Reply-To: <CA+c2ei-93BY=-9fGsie_c+q6=OWz3NA3HB9xLyGj2SLBi=OTXg@mail.gmail.com> References: <515EF14C.4070102@mit.edu> <CAJE5ia-WtbpbhvvuWixzah+YDdY-s_-c3kHG_pVe8J5bZa2YgQ@mail.gmail.com> <51C6FB2A.1010304@mit.edu> <CAJE5ia9WnYAZKjvmfh3KbcHN_xYKfmtfxuWQP-sYebxzTePwrQ@mail.gmail.com> <51C72C0C.5000605@mit.edu> <alpine.DEB.2.00.1307121914050.15729@ps20323.dreamhostps.com> <51E0627C.9070705@mit.edu> <CA+c2ei-93BY=-9fGsie_c+q6=OWz3NA3HB9xLyGj2SLBi=OTXg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309102122410.12199@ps20323.dreamhostps.com> On Fri, 12 Jul 2013, Jonas Sicking wrote: > > The algorithms in the spec are great when it comes to defining things > with high level of exactness. However they only work well when the > implementations of those algorithms actually look like the algorithms in > the spec. > > When they don't, the implementor has to read in all relevant algorithms > defined in the spec. Then map those algorithms into the semantics and > behavior they actually result in for the feature that the implementor is > working on implementing. Then map those semantics and behaviors into an > implementation that fits with existing code. Yeah. This is further complicated by the way all the implementations are implemented in ways that differ from each other, so that there's no way to write a single description that would be easy to understand for all vendors. I do sometimes actually try to follow one or the other browser's implementation, if I understand it well enough and it's clear enough. > Generally speaking, it would be easier if the spec defined the semantics > and the behaviors instead. Thereby avoiding having to do the initial > algorithms->behavior mapping. I agree. Unfortunately, it's really hard (for me) to describe behaviours like navigation in a declarative way while still covering all the edge cases. I'd be very happy to consider alternatives ways to describe the behaviours in the spec that are currently algorithmic in declarative ways, if anyone has any suggestions for how to do this. I do actually do it where possible. > Another fix would of course be to rewrite implementations to match the > algorithms and concepts in the spec more precisely. Though that's a > very risky undertaking for something like navigation since the spec > probably isn't getting all edge cases right. Yup. > Additionally the spec doesn't deal with all the situations that at least > Gecko has to deal with (desktop shortcuts being clicked. Bookmarklets > being clicked. Commandlines being executed. Addons. Etc) which means > that it might not be possible to get the two to align very well. Yup. > That said, I totally understand that it's very hard to define behavior > to the level of exactness that's currently there, without writing the > spec the way it's currently written. But I believe that this is what's > making the spec hard to read. What's making the spec hard to read is the same thing that makes the implementations hard to read. The topic in question is complicated. At the end of the day, there's a limit to how simply one can describe something that is fundamentally complicated. But as I said above, I'm very open to any suggestions. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 10 14:45:15 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Sep 2013 21:45:15 +0000 (UTC) Subject: [whatwg] Proposal: Media element - add attributes for discovery of playback rate support In-Reply-To: <CAEd8_SzCL+=ipSg5=_D30m+fE3kYky8mYfZbxh3cwG2SUn7CZA@mail.gmail.com> References: <m24nbtdv10.fsf@eoconnor.apple.com> <B7FD9B3C6E47A647A898FFE84DF32B953216A44A@xmb-rcd-x15.cisco.com> <CAG_kaUa9YQGzV6jJczEX90ze+3_LchXUHifS_WJB6Kc-q9cc3w@mail.gmail.com> <51E84C4F.7080900@brendanlong.com> <860226D3-29AC-4709-BB65-DEC36CF7C20E@apple.com> <51E864F3.2060701@brendanlong.com> <alpine.DEB.2.00.1307192108150.27623@ps20323.dreamhostps.com> <CAEd8_SzCL+=ipSg5=_D30m+fE3kYky8mYfZbxh3cwG2SUn7CZA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309102144130.12199@ps20323.dreamhostps.com> On Fri, 19 Jul 2013, Brendan Long wrote: > On Jul 19, 2013 3:14 PM, "Ian Hickson" <ian at hixie.ch> wrote: > > > > > > What if we added a "supportedPlaybackRates" attribute, which holds > > > an array of playback rates supported by the server, plus > > > (optionally) any rates the user agent can support due to the > > > currently buffered data (possibly requiring that the user agent have > > > enough data buffered to play at that speed for some amount of time). > > > > Wouldn't that be 0.0 .. Infinity, basically? > > I've been thinking about this more, and it seems like the buffered > attribute is enough for a JavaScript application to determine for itself > if it's safe to play faster. It does seem useful to expose the rates > supported by the server though, so an application can realize that it's > safe to play at those rates, even if there's not much buffered yet. How do browsers determine what speeds the server supports? IS that information in the protocol? I'd need to read more about this to figure out how to expose it. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From annevk at annevk.nl Tue Sep 10 15:10:22 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Tue, 10 Sep 2013 23:10:22 +0100 Subject: [whatwg] Forcing orientation in content In-Reply-To: <alpine.DEB.2.00.1309102107450.12199@ps20323.dreamhostps.com> References: <516F27BF.4060508@gmail.com> <alpine.DEB.2.00.1307121944480.15729@ps20323.dreamhostps.com> <420FE1A33AB14ACB9667D659D8F415D5@gmail.com> <op.wz8k70f4te2ec8@aimac> <alpine.DEB.2.00.1309102107450.12199@ps20323.dreamhostps.com> Message-ID: <CADnb78jSQJ8LJM6Qq0k1By2MPRWSucBdU0Oe5_OoHegvFgcWfA@mail.gmail.com> On Tue, Sep 10, 2013 at 10:22 PM, Ian Hickson <ian at hixie.ch> wrote: > On Mon, 15 Jul 2013, Kornel Lesi?ski wrote: >> Since specific, locked screen orientation is mostly needed in games, and >> forced rotation is disruptive to other things on the screen (e.g. moving >> buttons/addressbar to other physical edge of the screen), maybe it >> should be tied to the Fullscreen API? >> >> element.requestFullscreen({orientation:'landscape', autorotation:false}) > > That makes sense to me. Anne? Almost missed this! Filed: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23204 Implementer feedback welcome. -- http://annevankesteren.nl/ From tobie.langel at gmail.com Tue Sep 10 15:20:32 2013 From: tobie.langel at gmail.com (Tobie Langel) Date: Wed, 11 Sep 2013 00:20:32 +0200 Subject: [whatwg] Forcing orientation in content In-Reply-To: <alpine.DEB.2.00.1309102107450.12199@ps20323.dreamhostps.com> References: <516F27BF.4060508@gmail.com> <alpine.DEB.2.00.1307121944480.15729@ps20323.dreamhostps.com> <420FE1A33AB14ACB9667D659D8F415D5@gmail.com> <op.wz8k70f4te2ec8@aimac> <alpine.DEB.2.00.1309102107450.12199@ps20323.dreamhostps.com> Message-ID: <54FCF24DEB484FA8BA259B56D55DD661@gmail.com> On Tuesday, September 10, 2013 at 11:22 PM, Ian Hickson wrote: > On Sat, 13 Jul 2013, Tobie Langel wrote: > > It is not uncommon for mobile experiences to rely on the accelerometer > > as an input mechanism, for example to control page scrolling (e.g. > > Instapaper) or for gameplay. > > > > In such cases, auto-rotation of the viewport is completely disruptive to > > the user's experience and needs to be inhibited. > > Sure, but that's an OS-level feature. Arguably. Signaling auto-rotation inhibited requirements isn't, though. That's application-level. Auto-rotation inhibition needs to be automatic and scoped to the document. > > So this isn't so much about forcing orientation as it is about > > inhibiting auto-rotation. > > This would only work if the page was already in the orientation the user > wants, but how can we ensure that? The UA is free to provide whatever UI it wants to allow the user to enable/disable auto-rotation inhibition and/or pick a preferred orientation. From the use cases can be derived requirements for the content author to be able to signal to the UA the preference to inhibit auto-roation. Whether the UA decides to comply to this stated pref, allow its user to override it, etc. should be implementation-specific. > > Your desktop comparison is inadequate, as there aren't comparable > > auto-rotation mechanisms there. > > It would be equivalent to forcing a particular window size. No. A better analogy is the autoplay feature of video elements. Merely a hint that can be overridden by the user/UA. And frankly even that comparison is dodgy: playing a video doesn't have close to the discoverability and usability issues inhibiting auto-rotation at the OS level has. > On Mon, 15 Jul 2013, Kornel Lesi?ski wrote: > > Since specific, locked screen orientation is mostly needed in games, and > > forced rotation is disruptive to other things on the screen (e.g. moving > > buttons/addressbar to other physical edge of the screen), maybe it > > should be tied to the Fullscreen API? > > > > element.requestFullscreen({orientation:'landscape', autorotation:false}) > That makes sense to me. Anne? Agreed these requirements are generally tied to fullscreen/absence of browser-chrome context. Unfortunately, this is achieved using a variety of AP across implementations (e.g. iOS/Android?). So this proposition would only cater to those situation where the fullscreen API was used. --tobie From kornel at geekhood.net Tue Sep 10 16:02:21 2013 From: kornel at geekhood.net (=?utf-8?B?S29ybmVsIExlc2nFhHNraQ==?=) Date: Wed, 11 Sep 2013 00:02:21 +0100 Subject: [whatwg] High-density canvases In-Reply-To: <BBF7063D-027A-48C5-92CD-F5EF829BC800@apple.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> <alpine.DEB.2.00.1309102011560.12210@ps20323.dreamhostps.com> <BBF7063D-027A-48C5-92CD-F5EF829BC800@apple.com> Message-ID: <op.w27wx7bote2ec8@aimac.local> On Tue, 10 Sep 2013 21:22:51 +0100, Dean Jackson <dino at apple.com> wrote: > I think there are two separate things a developer might want: > > - the number of actual pixels that correspond to 1 CSS px without zoom > - the page zoom > > If you merge the two, then an unsuspecting developer might think that > the user has zoomed in by 2x on an iPhone, and decide to make things > smaller. Do you have an example of a page that does make things smaller to counter the zoom? Are you referring to some iPhone-specific workarounds (like position:fixed elements being problematic for zoom?) I assumed that sites which don't like being zoomed in would just block it via <meta viewport>. -- regards, Kornel From dmazzoni at google.com Tue Sep 10 16:19:15 2013 From: dmazzoni at google.com (Dominic Mazzoni) Date: Tue, 10 Sep 2013 16:19:15 -0700 Subject: [whatwg] Outline style to use for drawSystemFocusRing In-Reply-To: <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> References: <CAFz-FYxS-sLLOMA2=5bj-aJ1bmsBq8w_4Rminw_JLCMnYaMfPw@mail.gmail.com> <alpine.DEB.2.00.1307242308540.27623@ps20323.dreamhostps.com> <CAGN7qDCdCR1F-D9PtEKUcHkh5KdwKhum4vEAyUQ0VkLeeC+PCA@mail.gmail.com> <alpine.DEB.2.00.1307292147040.27623@ps20323.dreamhostps.com> <CAGN7qDAaq8XnX1z_BbpLVhgE5m4j--b720ZuHSEzq_iN1es0=Q@mail.gmail.com> <alpine.DEB.2.00.1307300020510.27623@ps20323.dreamhostps.com> <CAGN7qDAjRPOQ25gQT+BY+sp8Y503_9KxTa1j2aZSGYU-9BmBVA@mail.gmail.com> <CAFz-FYzzPFU3g+fM+QGbEDAJ-3DSU2qGHY9R+heZRbAWVAN2rw@mail.gmail.com> <CAGN7qDDu3PNxK9PTVr09sqUc0FrOnXgRaQDwLXQ13BhH_=85Bw@mail.gmail.com> <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> Message-ID: <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> We've finished implementing drawSystemFocusRing and drawCustomFocusRing in Chrome. Try it in Chrome 31 or higher (either canary or dev channel should work today). You'll need to go to chrome://flags and enable *experimental canvas features*, then restart the browser. Here's a demo I built that uses drawSystemFocusRing: http://dmazzoni-google.github.io/canvas-focus-ring-demo/ - Dominic From ian at hixie.ch Tue Sep 10 16:35:00 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Sep 2013 23:35:00 +0000 (UTC) Subject: [whatwg] Should <video controls> generate click events? In-Reply-To: <CAO9Q3iKwpDwFpxaQOBeeg7SQZJR+9rmAVbobF7QU7jcHcO7Uhg@mail.gmail.com> References: <op.wzbxjpiqsr6mfa@kirk> <alpine.DEB.2.00.1308062124340.9685@ps20323.dreamhostps.com> <CAO9Q3iJCXefD+cn+7zsWw6z19Hof5efO85zO=CAvG1GhjxYjGQ@mail.gmail.com> <CAO9Q3iKwpDwFpxaQOBeeg7SQZJR+9rmAVbobF7QU7jcHcO7Uhg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309102145290.12199@ps20323.dreamhostps.com> On Tue, 20 Aug 2013, Edward O'Connor wrote: > >>> > >>> [W]e do want users to be able to bring up the native controls via a > >>> context menu and be able to use them regardless of what the page > >>> does in its event handlers. So, I request that the spec be explicit > >>> that interacting with the video controls does not cause the normal > >>> script-visible events to be fired. > >[?] > >> I've made the spec say this is a valid (and recommended) > >> implemenation strategy. > > > > The change <http://html5.org/r/8134> looks good to me, thanks! > > I don't see why <video controls> should be any different than, say, > <button> here. If I install an event handler on an ancestor of an > element, I'm able to capture events and prevent the descendent element > from seeing them. It's more similar to clicking on a context menu (or indeed a menu bar) than clicking on a button, IMHO. Or like clicking on a control in the popup from <input type=file>. Or clicking in the colour wheel that pops up when you active an <input type=color> control. A <button> is an in-page control. A <video>'s controls are not an in-page control -- there's no in-page element for them, they might not even be positioned over the page (they could be on a palette that the user has dragged out of the page). Also, with <button> the UA and the page are working together. The UA renders the button and shows how it is being pressed; the author makes it do something. The case we're talking about here is where the user presses a button and both the user agent and the author want to do something (and the author has no way to know what the user agent wants to do, or what the user thinks will happen). > A UI which allows users to activate a control "regardless of what the > page does in its event handlers" is a general feature not specific to > media elements?and may be worth considering?but we shouldn't make a > one-off exception to the basic model of DOM events just for <video>. I agree that it's not specific to <video>, but I don't think we have to mention it for other things because it's only <video> where the spec suggests having such a UI model and where browsers have historically also fired an event. On Wed, 21 Aug 2013, Silvia Pfeiffer wrote: > > The paragraph added in <http://html5.org/r/8134> should probably be > restricted to the case where the default video controls have been > enabled by the user (e.g. through the context menu) rather than by the > Web page. It would indeed be bad if the Web page author, who is using > the default controls through a <video controls> attribute could not rely > on the events firing. Why? > IMHO, the example that Philip provided in http://people.opera.com/~** > philipj/click.html <http://people.opera.com/~philipj/click.html> is not > a realistic example of something a JS dev would do. Seem pretty reasonable to me. How else would you make the video play/pause when you click the video frame, yet also have UA controls? On Wed, 21 Aug 2013, Silvia Pfeiffer wrote: > > What I'm saying is that the idea that the JS developer controls > pause/play as well as exposes <video controls> is a far-fetched example. I don't see why. It's what I'd do. On Tue, 20 Aug 2013, Bob Lund wrote: > > What about a Web page that uses JS to control pause/play/etc based on > external messages, say from a WebSocket? The sender in this case acts as > a remote control. That seems unrelated to this issue, unless I'm missing something. On Tue, 20 Aug 2013, Rick Waldron wrote: > > Firefox actually implements click-to-play <video> by default. It's > unfortunate and all <video> interaction projects that I've worked on > directly or consulted for have been forced to include video surface > click -> event.preventDefault() calls to stop the behaviour. This may be > irrelevant to the current discussion, but I'm trying to get a better > understanding for the behavioural changes implied by this spec update, > so correction is highly desirable. The change wouldn't affect this as far as I can tell. We're talking about interaction with specific controls enabled by controls="" (or manually by the user). On Tue, 20 Aug 2013, Glenn Maynard wrote: > > It's the behavior users expect when watching videos, which is the case > <video> should optimize for. If you're doing something else where the > user interacts with the video in other ways, then it's expected that you > need to prevent this behavior explicitly. > > Unlike browser controls, this is visible to scripts and something that > affects authors, so this probably should be in the spec if it isn't. I'm not sure what you want in the spec here. Can you elaborate? On Wed, 21 Aug 2013, Robert O'Callahan wrote: > > Just to be clear, we only do click-to-play when the "controls" attribute > is set. So if that's causing problems for you, I guess you want most of > our built-in controls but not all of them? On Tue, 20 Aug 2013, Rick Waldron wrote: > > Also, at the time, the surface click to play was non-standard and > incredibly annoying because it just "showed up" as someone's pet feature > in Firefox. (I'm still not sure if it's a "standard" feature, I can't > find anything in the spec about it, but I could've just missed it) It's not documented in the spec, but it seems reasonable. Should we make this an explicit activation behaviour for the <video> element if it has a controls="" attribute? On Wed, 21 Aug 2013, Robert O'Callahan wrote: > > I think you basically have to assume that if you specify "controls" then > the controls may accept clicks anywhere in the video element. There's > nothing in the spec to say that the controls must be restricted to a bar > of a certain height at the bottom of the element. True, but there _is_ something now that says that if the browser considers it the user interacting with a control, that there shouldn't be events sent to the page. It's either a control (no events), or an activation behaviour (click events, can be canceled by preventDefault()). On Wed, 21 Aug 2013, Silvia Pfeiffer wrote: > > Indeed. As a JS dev you make a choice: either you roll your own, or you > don't. > > If you roll your own, you write the JS to handle the clicks from the > controls and do video.pause() and video.play() yourself. > > If you don't roll your own, you write <video controls> and you expect > the browser to handle pausing/playing. You don't do what Philip's demo ( > http://people.opera.com/~philipj/click.html) does: handle pause and play > toggling in JS. Because the browser already does that for you. I think doing both is perfectly reasonable, especially since we don't define an explicit activation behaviour currently. > This is why I am saying: Philip's example is not a typical use case. It > only happens when the developer made the choice to roll their own, but > the user activates the default controls (e.g. through the context menu) > as well. This can't happen on YouTube, because YouTube hide away the > context menu on the video element. There's no way for a page to definitely prevent the user from enabling these controls. A browser could always have some other way to enable them, or allow access to the context menu regardless, etc. > However, the patch has a wider implication: namely that the User agent > will suppress all user interaction events from the browser-provided > video controls. I.e. if the user clicks on the play button, no click > event is raised on the video element and the elements that the video > element is in. That's what Edward is objecting to - and I agree. Why do you object? What sense is there in sending the event to the page? On Tue, 20 Aug 2013, Rick Waldron wrote: > > Thank you, this is the clarification I was looking for in my previous > inquiries. Given this explanation, I absolutely object to any change > (such as this) that will effectively cripple the interaction > "programmability" of <video> elements. There are commercial products > that have been developed and are being developed that rely on the > ability to add listeners for events that occur on the <video controls> > as part of reach and engagement data collection, eg. Did the user click > the Play button on the video and watch it all the way through? Did they > click Pause? Did they drag to seek? How can you tell what they clicked? On Wed, 21 Aug 2013, Simon Pieters wrote: > > Just listen for the 'play', 'paused', 'seeked', 'ended' etc events for > this. The change doesn't cripple the <video> API at all. Listening for > 'click' doesn't tell you whether the user clicked play or pause or > seeked or none of those, so it's quite useless for that purpose. Indeed. On Tue, 20 Aug 2013, Peter Occil wrote: > > I'm afraid this example doesn't work well in Firefox and Google Chrome. > It affects not only the video itself but also the browser-provided > controls, and in Firefox it seems to interfere with those controls. I > think that at most the click-to-play behavior should only affect the > video itself, not the buttons or other controls (for this to work, this > would require hit-testing to see if the video or a control was clicked, > and only override the default behavior if the video itself was clicked; > the hit-testing, though, will be browser-specific and may require > defining a new method in the spec). In this way, the video controls > would remain unaffected or be specially handled in a different way. > Another -- less realistic --solution may be to define new event handlers > ("videoclick"? "videopauseclick"?) that only affect parts of the video > element and not the entire video element. On Wed, 21 Aug 2013, Philip J?genstedt wrote: > > Indeed, the demo was precisely to show how the native controls become > unusable when the scripts on the page haven't taken them into > consideration. Right, that's what the spec has since had fixed. On Tue, 20 Aug 2013, Brian Chirls wrote: > > Rick makes some good points. It seems there is a clear cost to this > change, but I'm afraid that there is little benefit, since it won't > prevent the proposed control-breaking scenario anyway. > > It seems to me that danger of Mr. J?genstedt's proposed scenario is that > the user is annoyed by being forced to watch and/or listen to a piece of > media against his/her will. No, the problem is that the page's logic interacts with the browser's logic in a way that nobody can predict or handle. You can't force the user to do anything. They control the computer, at the end of the day, and can do whatever they want. On Wed, 21 Aug 2013, Silvia Pfeiffer wrote: > On Wed, Aug 21, 2013 at 8:59 PM, Simon Pieters <simonp at opera.com> wrote: > > > > The problem was this: if you want to do something when a user clicks > > on a video but not when the user interacts with the native controls, > > you're basically out of luck. > > No, you can do as you do below: you can define an onclick handler and do > something. As long as you don't do something that the native controls > are already taking care of, such as play() and pause(). If you are > indeed trying to influence the play/pause state of the video element > both from script and native controls, you need to be more creative with > your event handlers and use onclick and onpause and onplay event > handlers and carefully manage which ones cancel out which other ones. Since you don't know what the controls can do, I don't see how that makes sense. What if you want to mute the volume when the user clicks on a non-control part of the video, but do nothing when they click on the controls? You can't do it without the browser suppressing events when the user is interacting with the controls. > It also means that in the case of Firefox or in the case of Android > Chrome, where the native controls cover the full video with a overlay > button when not on autoplay, you cannot get any onclick events on the > video element at all. Right, that seems perfectly reasonable. On Wed, 21 Aug 2013, Simon Pieters wrote: > > It may be the case that the change is suboptimal especially now that > some browsers make the whole video a big play/pause button. I don't see how that affects the issue. > For instance, I can imagine exposing a property on the click event that > tells whether the user clicked on the controls, and maybe even what was > being clicked (as a string). > > <video onclick="if (controlsTarget == null) { if (paused) play(); else > pause(); }" ...></video> That seems like it would be far more complicated than necessary. What's the use case? (Why would you ever want the event when the user did click on a control?) On Wed, 21 Aug 2013, Brian Chirls wrote: > > Yes, I think adding information to the click event is a great approach. > Event objects often have additional information, like mouse coordinates > or key code, so it wouldn't feel like an unusual or special case. The > previous approach removes information, where this one adds it. Let's not > forget that the same information should apply to touch and hover events > as well. What is this information for? We're talking about a lot of complexity here, we shouldn't do that unless we have a really solid reason. On Wed, 21 Aug 2013, Tab Atkins Jr. wrote: > > The problem with trying to use click, even with additional information, > is that *the UA-defined controls are unknown*. Maybe they have a > play-pause button. Maybe they've only got a scrubber, and rely on > clicking on the face to play/pause. Maybe they do something quite > different. The HTML spec makes *zero* guarantees about what's inside of > that, which is *intentional*. Indeed. > The correct thing to do is listen for the defined events which indicate > that a particular state has changed. I can't think of a reasonable > use-case for wanting to know which button was clicked that isn't solved > at least as well by just listening for the event for the state change. Indeed. The API is very carefully designed to enable multiple independent controllers to interact sanely, especially the case of UA controls and page controls. On Wed, 21 Aug 2013, Brian Chirls wrote: > > So, perhaps we need a separate set of events. So, when a user clicks the > play button, events would fire in this order: > 1. play requested by user agent from some UI. Cancelable. > 2. 'play' event. The browser has been asked to play the video, whether by > the UI or by API. > 3. 'playing' event. After all the network magic has happened, the video is > actually playing. We already have all these events (not precisely how you describe them, but more or less). Please do see the spec: http://whatwg.org/html#mediaevents On Thu, 22 Aug 2013, Elliott Sprehn wrote: > > This means that if I have <video controls> on the page and then I click > something that shows a non-modal dialog that should dismiss on clicking > elsewhere in the page, and then click the video the page popup doesn't > disappear. If you click one of the controls on that video, right. It's similar to what happens if you click another window, or in an <iframe>. (It's conceptually the same thing.) > Should authors be listening for mouseup instead to take actions when > users click inside <video>? mouseup would be suppressed also. On Thu, 22 Aug 2013, Elliott Sprehn wrote: > > This is wrong, it means I have no way to tell if you click inside the > <video> to dismiss popups or notifications. I don't think we should be > making <video controls> a blackhole to events, it breaks lots of use > cases. What use cases does it break that aren't already broken? If we want to support "any click outside this non-modal <dialog> should close it", then we should just provide that feature directly, we shouldn't rely on authors knowing to check for window.onblur and descendant iframe mouse events and so on. > Instead we should expose the controls as a pseudo element on the event, > just like TransitionEvent has a String pseudoElement so you can tell if > the thing transitioning is the "::before" or the "::after", we should > add ::controls and inside the click handler you can take no action if > the target is the controls. If we assume the new Shadow DOM spec, we > could just use the "part" feature which was designed specifically for > this kind of thing and should be exposed on all events. I don't think this solves the problem -- foolip's example would still fail. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From glenn at zewt.org Tue Sep 10 16:53:10 2013 From: glenn at zewt.org (Glenn Maynard) Date: Tue, 10 Sep 2013 18:53:10 -0500 Subject: [whatwg] Should <video controls> generate click events? In-Reply-To: <alpine.DEB.2.00.1309102145290.12199@ps20323.dreamhostps.com> References: <op.wzbxjpiqsr6mfa@kirk> <alpine.DEB.2.00.1308062124340.9685@ps20323.dreamhostps.com> <CAO9Q3iJCXefD+cn+7zsWw6z19Hof5efO85zO=CAvG1GhjxYjGQ@mail.gmail.com> <CAO9Q3iKwpDwFpxaQOBeeg7SQZJR+9rmAVbobF7QU7jcHcO7Uhg@mail.gmail.com> <alpine.DEB.2.00.1309102145290.12199@ps20323.dreamhostps.com> Message-ID: <CABirCh-GV-BUsFSWUFYbuUh=Qpb84yWLLp3+X8_4CVLM6HUK_A@mail.gmail.com> On Tue, Sep 10, 2013 at 6:35 PM, Ian Hickson <ian at hixie.ch> wrote: > On Tue, 20 Aug 2013, Glenn Maynard wrote: > > It's the behavior users expect when watching videos, which is the case > > <video> should optimize for. If you're doing something else where the > > user interacts with the video in other ways, then it's expected that you > > need to prevent this behavior explicitly. > > > > Unlike browser controls, this is visible to scripts and something that > > affects authors, so this probably should be in the spec if it isn't. > > I'm not sure what you want in the spec here. Can you elaborate? > The same thing you described: the activation behavior for videos should be to toggle play/pause. If only some browsers do it, it's an interop problem, and it seems like the right default behavior. I'm not sure whether this should only be when browser controls are enabled or not. It might be best to keep them orthogonal, so browser controls are always UI controls that don't generate click events at all. On Wed, 21 Aug 2013, Silvia Pfeiffer wrote: > > This is why I am saying: Philip's example is not a typical use case. It > > only happens when the developer made the choice to roll their own, but > > the user activates the default controls (e.g. through the context menu) > > as well. This can't happen on YouTube, because YouTube hide away the > > context menu on the video element. > You can't do that. Browsers have options to remove the ability for pages to prevent the context menu from opening. I always use it, since it's disruptive (the browser's context menu belongs to me, not the page). -- Glenn Maynard From glenn at zewt.org Tue Sep 10 18:24:20 2013 From: glenn at zewt.org (Glenn Maynard) Date: Tue, 10 Sep 2013 20:24:20 -0500 Subject: [whatwg] High-density canvases In-Reply-To: <alpine.DEB.2.00.1309100021320.12210@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <5989691D-4430-4FA0-8E22-BCDD35CC5DC7@apple.com> <alpine.DEB.2.00.1309100021320.12210@ps20323.dreamhostps.com> Message-ID: <CABirCh-6Z2wBhc=upZx7EQpTxThCx8ft4K72Zt0acVm_UTj_NA@mail.gmail.com> On Mon, Sep 9, 2013 at 7:31 PM, Ian Hickson <ian at hixie.ch> wrote: > Right, resetting the context would definitely be part of the deal. This > mode would be specifically defined as a mode where you had to listen to > onresize or your canvas would almost certainly get cleared sooner or > later. In fact, we could go further, and say that canvases that aren't > getting rendered at all (e.g. display:none, off-screen, background tab) > can get cleared, with the deal being that next time you need to show the > canvas you immediately get an onresize. > It would be better if the resize didn't happen until the page is actually ready to re-render. That way, the canvas doesn't flicker if it's rendered before the page actually does render (eg. it may need to reload resources to render). Rendering a blurry canvas briefly is better than rendering a blank canvas. For example, add a method "resizeToCurrentDPI()", and don't do it automatically at all. Fire an event when calling the method *would* cause a change of canvas size. The page can then load resources asynchronously as needed, and call the method when it's ready to redraw, avoiding any period where a blank canvas might be composited. > Yeah, my suggestion, if we do this, would be to not do it until high > density displays are even more widely available than now. This is mostly a > convenience and performance-improving API, not a critical feature add. > High-DPI displays are already widespread in mobile (all Apple devices except for the iPad Mini; the Kindle Fire HD), and by contrast there's no sign of them for desktops, so I think we're either there now or we won't be for a long time. -- Glenn Maynard From jackalmage at gmail.com Tue Sep 10 22:46:24 2013 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Tue, 10 Sep 2013 22:46:24 -0700 Subject: [whatwg] High-density canvases In-Reply-To: <CABirCh-6Z2wBhc=upZx7EQpTxThCx8ft4K72Zt0acVm_UTj_NA@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <5989691D-4430-4FA0-8E22-BCDD35CC5DC7@apple.com> <alpine.DEB.2.00.1309100021320.12210@ps20323.dreamhostps.com> <CABirCh-6Z2wBhc=upZx7EQpTxThCx8ft4K72Zt0acVm_UTj_NA@mail.gmail.com> Message-ID: <CAAWBYDDyVLvsiO4fhgogOgn2XgvDBOswON9+0tPVA9CGvDi7ag@mail.gmail.com> On Tue, Sep 10, 2013 at 6:24 PM, Glenn Maynard <glenn at zewt.org> wrote: >> Yeah, my suggestion, if we do this, would be to not do it until high >> density displays are even more widely available than now. This is mostly a >> convenience and performance-improving API, not a critical feature add. > > High-DPI displays are already widespread in mobile (all Apple devices > except for the iPad Mini; the Kindle Fire HD), and by contrast there's no > sign of them for desktops, so I think we're either there now or we won't be > for a long time. High-end laptops have high-dpi screens (the Pixel I'm using right now has one), and they're slowly spreading down the price scale. ~TJ From robert at ocallahan.org Wed Sep 11 01:18:51 2013 From: robert at ocallahan.org (Robert O'Callahan) Date: Wed, 11 Sep 2013 01:18:51 -0700 Subject: [whatwg] High-density canvases In-Reply-To: <CAAWBYDDyVLvsiO4fhgogOgn2XgvDBOswON9+0tPVA9CGvDi7ag@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <5989691D-4430-4FA0-8E22-BCDD35CC5DC7@apple.com> <alpine.DEB.2.00.1309100021320.12210@ps20323.dreamhostps.com> <CABirCh-6Z2wBhc=upZx7EQpTxThCx8ft4K72Zt0acVm_UTj_NA@mail.gmail.com> <CAAWBYDDyVLvsiO4fhgogOgn2XgvDBOswON9+0tPVA9CGvDi7ag@mail.gmail.com> Message-ID: <CAOp6jLZ+EA355PgSx08b+jqv=e=gvwMA3cbTnK2hkRiX3Bb8sQ@mail.gmail.com> On Tue, Sep 10, 2013 at 10:46 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote: > High-end laptops have high-dpi screens (the Pixel I'm using right now > has one), and they're slowly spreading down the price scale. > On Mac there are Retinas of course, and on Windows Firefox defaults to a non-1.0 devicePixelRatio on many systems now (anything where the default "Windows font DPI" is not 96). Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * From robert at ocallahan.org Wed Sep 11 01:20:21 2013 From: robert at ocallahan.org (Robert O'Callahan) Date: Wed, 11 Sep 2013 01:20:21 -0700 Subject: [whatwg] High-density canvases In-Reply-To: <CAGN7qDCC=8EZUpEmN=10tcWGU=8TPQ7rej+sOGhbPaWqqAjWRA@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> <CAGN7qDCC=8EZUpEmN=10tcWGU=8TPQ7rej+sOGhbPaWqqAjWRA@mail.gmail.com> Message-ID: <CAOp6jLZFD_HVKgEfEUB0myCdvz60i_=1NASVQ-YKyzcHxkDxVw@mail.gmail.com> On Tue, Sep 10, 2013 at 1:26 PM, Rik Cabanier <cabanier at gmail.com> wrote: > There's a thread on www-style: > http://lists.w3.org/Archives/Public/www-style/2012Nov/0144.html > It's been in firefox for a while and blink is going to ship it soon: > > https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/RyUSi3zdumQ > devicePixelRatio has reflected page zoom in Firefox ever since we first exposed it (because the thing it maps to internally has always been affected by page zoom). > > > Actually what I really think we should do is also change the > > > window.devicePixelRatio for pinch zoom. Combined with the suggestions > for > > > canvas, that would allow (as Rik pointed out on IRC) for high-quality > > > canvas all the way zoomed in, and for cheap canvases when zoomed out > > I believe pinch zoom should not change devicePixelRatio. It would be nice > if there was a standard way to determine pinch zoom though and if the > canvas could automatically resize. > Pinch-zoom is hard because we don't want to trigger reflows or other expensive behavior on pinch-zoom. I'd leave pinch-zoom out of it for now. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * From simonp at opera.com Wed Sep 11 01:48:29 2013 From: simonp at opera.com (Simon Pieters) Date: Wed, 11 Sep 2013 10:48:29 +0200 Subject: [whatwg] Should <video controls> generate click events? In-Reply-To: <alpine.DEB.2.00.1309102145290.12199@ps20323.dreamhostps.com> References: <op.wzbxjpiqsr6mfa@kirk> <alpine.DEB.2.00.1308062124340.9685@ps20323.dreamhostps.com> <CAO9Q3iJCXefD+cn+7zsWw6z19Hof5efO85zO=CAvG1GhjxYjGQ@mail.gmail.com> <CAO9Q3iKwpDwFpxaQOBeeg7SQZJR+9rmAVbobF7QU7jcHcO7Uhg@mail.gmail.com> <alpine.DEB.2.00.1309102145290.12199@ps20323.dreamhostps.com> Message-ID: <op.w28n23m8idj3kv@simons-macbook-pro.local> On Wed, 11 Sep 2013 01:35:00 +0200, Ian Hickson <ian at hixie.ch> wrote: > On Tue, 20 Aug 2013, Rick Waldron wrote: >> >> Also, at the time, the surface click to play was non-standard and >> incredibly annoying because it just "showed up" as someone's pet feature >> in Firefox. (I'm still not sure if it's a "standard" feature, I can't >> find anything in the spec about it, but I could've just missed it) > > It's not documented in the spec, but it seems reasonable. > On Wed, 21 Aug 2013, Robert O'Callahan wrote: >> >> I think you basically have to assume that if you specify "controls" then >> the controls may accept clicks anywhere in the video element. There's >> nothing in the spec to say that the controls must be restricted to a bar >> of a certain height at the bottom of the element. > > True, but there _is_ something now that says that if the browser > considers > it the user interacting with a control, that there shouldn't be events > sent to the page. It's either a control (no events), or an activation > behaviour (click events, can be canceled by preventDefault()). Saying that Firefox's "click anywhere to play" isn't a control but rather activation behavior for the element makes sense. If other browsers want to implement that behavior, it would be good if the spec called out this difference. > Should we make this an explicit activation behaviour for the <video> > element if it has a controls="" attribute? That might be good so that the behavior is consistent between browsers. However, I think it should be conditional on whether the controls are visible rather than whether the controls attribute is present. -- Simon Pieters Opera Software From philipj at opera.com Wed Sep 11 01:51:44 2013 From: philipj at opera.com (=?ISO-8859-1?Q?Philip_J=E4genstedt?=) Date: Wed, 11 Sep 2013 10:51:44 +0200 Subject: [whatwg] Should <video controls> generate click events? In-Reply-To: <op.w28n23m8idj3kv@simons-macbook-pro.local> References: <op.wzbxjpiqsr6mfa@kirk> <alpine.DEB.2.00.1308062124340.9685@ps20323.dreamhostps.com> <CAO9Q3iJCXefD+cn+7zsWw6z19Hof5efO85zO=CAvG1GhjxYjGQ@mail.gmail.com> <CAO9Q3iKwpDwFpxaQOBeeg7SQZJR+9rmAVbobF7QU7jcHcO7Uhg@mail.gmail.com> <alpine.DEB.2.00.1309102145290.12199@ps20323.dreamhostps.com> <op.w28n23m8idj3kv@simons-macbook-pro.local> Message-ID: <CAMQvoC=Na_25VMzLeY=fWhtQ1Ot-mPPhy5G=4stCfJaUcGDdMw@mail.gmail.com> On Wed, Sep 11, 2013 at 10:48 AM, Simon Pieters <simonp at opera.com> wrote: > On Wed, 11 Sep 2013 01:35:00 +0200, Ian Hickson <ian at hixie.ch> wrote: > >> On Wed, 21 Aug 2013, Robert O'Callahan wrote: >>> >>> >>> I think you basically have to assume that if you specify "controls" then >>> the controls may accept clicks anywhere in the video element. There's >>> nothing in the spec to say that the controls must be restricted to a bar >>> of a certain height at the bottom of the element. >> >> >> True, but there _is_ something now that says that if the browser considers >> it the user interacting with a control, that there shouldn't be events >> sent to the page. It's either a control (no events), or an activation >> behaviour (click events, can be canceled by preventDefault()). > > > Saying that Firefox's "click anywhere to play" isn't a control but rather > activation behavior for the element makes sense. If other browsers want to > implement that behavior, it would be good if the spec called out this > difference. > > >> Should we make this an explicit activation behaviour for the <video> >> element if it has a controls="" attribute? > > > That might be good so that the behavior is consistent between browsers. > However, I think it should be conditional on whether the controls are > visible rather than whether the controls attribute is present. What does "visible" mean here, is it to handle cases where the UA force-enables the controls without adding the controls attribute to the DOM? Philip From jackalmage at gmail.com Wed Sep 11 02:04:56 2013 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Wed, 11 Sep 2013 02:04:56 -0700 Subject: [whatwg] High-density canvases In-Reply-To: <CAOp6jLZFD_HVKgEfEUB0myCdvz60i_=1NASVQ-YKyzcHxkDxVw@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> <CAGN7qDCC=8EZUpEmN=10tcWGU=8TPQ7rej+sOGhbPaWqqAjWRA@mail.gmail.com> <CAOp6jLZFD_HVKgEfEUB0myCdvz60i_=1NASVQ-YKyzcHxkDxVw@mail.gmail.com> Message-ID: <CAAWBYDBKs481S3c14TEnatWuvJrtg4F9jARy6wKVHAfER8Q+yg@mail.gmail.com> On Wed, Sep 11, 2013 at 1:20 AM, Robert O'Callahan <robert at ocallahan.org> wrote: >> > > Actually what I really think we should do is also change the >> > > window.devicePixelRatio for pinch zoom. Combined with the suggestions >> for >> > > canvas, that would allow (as Rik pointed out on IRC) for high-quality >> > > canvas all the way zoomed in, and for cheap canvases when zoomed out >> >> I believe pinch zoom should not change devicePixelRatio. It would be nice >> if there was a standard way to determine pinch zoom though and if the >> canvas could automatically resize. >> > > Pinch-zoom is hard because we don't want to trigger reflows or other > expensive behavior on pinch-zoom. I'd leave pinch-zoom out of it for now. Yes. Somewhere (HTML? CSSOM? CSSOM-View?) needs to define "layout-affecting zoom" and "visual zoom", define what goes where, and then we can just hook things to "layout-affecting zoom" and be done with it. (I think dbaron had some name suggestions, or at least some name *objections*, related to this stuff.) ~TJ From simonp at opera.com Wed Sep 11 02:18:00 2013 From: simonp at opera.com (Simon Pieters) Date: Wed, 11 Sep 2013 11:18:00 +0200 Subject: [whatwg] Should <video controls> generate click events? In-Reply-To: <CAMQvoC=Na_25VMzLeY=fWhtQ1Ot-mPPhy5G=4stCfJaUcGDdMw@mail.gmail.com> References: <op.wzbxjpiqsr6mfa@kirk> <alpine.DEB.2.00.1308062124340.9685@ps20323.dreamhostps.com> <CAO9Q3iJCXefD+cn+7zsWw6z19Hof5efO85zO=CAvG1GhjxYjGQ@mail.gmail.com> <CAO9Q3iKwpDwFpxaQOBeeg7SQZJR+9rmAVbobF7QU7jcHcO7Uhg@mail.gmail.com> <alpine.DEB.2.00.1309102145290.12199@ps20323.dreamhostps.com> <op.w28n23m8idj3kv@simons-macbook-pro.local> <CAMQvoC=Na_25VMzLeY=fWhtQ1Ot-mPPhy5G=4stCfJaUcGDdMw@mail.gmail.com> Message-ID: <op.w28pgaa5idj3kv@simons-macbook-pro.local> On Wed, 11 Sep 2013 10:51:44 +0200, Philip J?genstedt <philipj at opera.com> wrote: >> That might be good so that the behavior is consistent between browsers. >> However, I think it should be conditional on whether the controls are >> visible rather than whether the controls attribute is present. > > What does "visible" mean here, is it to handle cases where the UA > force-enables the controls without adding the controls attribute to > the DOM? Yes. http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#expose-a-user-interface-to-the-user -- Simon Pieters Opera Software From philipj at opera.com Wed Sep 11 02:18:28 2013 From: philipj at opera.com (=?ISO-8859-1?Q?Philip_J=E4genstedt?=) Date: Wed, 11 Sep 2013 11:18:28 +0200 Subject: [whatwg] Should <video controls> generate click events? In-Reply-To: <op.w28pgaa5idj3kv@simons-macbook-pro.local> References: <op.wzbxjpiqsr6mfa@kirk> <alpine.DEB.2.00.1308062124340.9685@ps20323.dreamhostps.com> <CAO9Q3iJCXefD+cn+7zsWw6z19Hof5efO85zO=CAvG1GhjxYjGQ@mail.gmail.com> <CAO9Q3iKwpDwFpxaQOBeeg7SQZJR+9rmAVbobF7QU7jcHcO7Uhg@mail.gmail.com> <alpine.DEB.2.00.1309102145290.12199@ps20323.dreamhostps.com> <op.w28n23m8idj3kv@simons-macbook-pro.local> <CAMQvoC=Na_25VMzLeY=fWhtQ1Ot-mPPhy5G=4stCfJaUcGDdMw@mail.gmail.com> <op.w28pgaa5idj3kv@simons-macbook-pro.local> Message-ID: <CAMQvoC=X3m7N4FiAXhP4S+HQF+4EL-zivwEZY6jGVsFaOGEZVg@mail.gmail.com> On Wed, Sep 11, 2013 at 11:18 AM, Simon Pieters <simonp at opera.com> wrote: > On Wed, 11 Sep 2013 10:51:44 +0200, Philip J?genstedt <philipj at opera.com> > wrote: > >>> That might be good so that the behavior is consistent between browsers. >>> However, I think it should be conditional on whether the controls are >>> visible rather than whether the controls attribute is present. >> >> >> What does "visible" mean here, is it to handle cases where the UA >> force-enables the controls without adding the controls attribute to >> the DOM? > > > Yes. > > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#expose-a-user-interface-to-the-user Right, connecting it to the "expose a user interface to the user" concept seems best. Philip From annevk at annevk.nl Wed Sep 11 03:53:35 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Wed, 11 Sep 2013 11:53:35 +0100 Subject: [whatwg] URL resolution of fragment urls in html5 webapps In-Reply-To: <alpine.DEB.2.00.1309100013320.12199@ps20323.dreamhostps.com> References: <CAO9zZYMo79Dqn-EK8S0j-M9sNJeFEGQg_XgP6+fsszDmq5oDMQ@mail.gmail.com> <CANr5HFXkxQuiy+n1jDkd=jP92Wz=E0_BrGbo40A0xxjpbAw2dQ@mail.gmail.com> <CAO9zZYOuSfkkGbqFWeeJ-gu1k0mZLFfnjrgkiweL+EN9aGGoiw@mail.gmail.com> <alpine.DEB.2.00.1309100013320.12199@ps20323.dreamhostps.com> Message-ID: <CADnb78iS2LsMporp8qKxFmmBy-rHH7q++_-osP94oaWAtjzdcw@mail.gmail.com> On Tue, Sep 10, 2013 at 8:34 PM, Ian Hickson <ian at hixie.ch> wrote: > On Wed, 10 Jul 2013, Rafael Weinstein wrote: >> I'm curious: Is it useful to have fragment URL resolve against anything >> other than the "display" url? I.e. when is the current behavior wrt >> fragments appropriate. > > It's a good question. I thought the old IETF specs for URLs said you had > to do otherwise, but nobody seems to have implemented that. Browsers have been inconsistent on this actually, not sure if they still are. I think if we want to do this differently, then after trimming whitespace to obtain the URL, the <a> element should have a special case for # and pick a different base URL at that point. https://tools.ietf.org/html/rfc2396#section-4.2 has the vague wording that does not take the base URL into account. In https://tools.ietf.org/html/rfc3986#section-4.4 it does. The problem with the former is that it's not clear when it applies, but we could make that clear by only doing it in certain contexts, as I suggested above. -- http://annevankesteren.nl/ From annevk at annevk.nl Wed Sep 11 04:03:00 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Wed, 11 Sep 2013 12:03:00 +0100 Subject: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use In-Reply-To: <alpine.DEB.2.00.1309101934520.12199@ps20323.dreamhostps.com> References: <514A7477.6040905@mit.edu> <alpine.DEB.2.00.1307121809430.15729@ps20323.dreamhostps.com> <51E04C76.30200@mit.edu> <CAJE5ia_WTqejajPZVxf=cxTipvPyE=g0FWQfj-kJaj1tK583kw@mail.gmail.com> <51E04FDD.2080702@mit.edu> <CADnb78iniuYkyc4cH+RECg1p=ANVQPMz_sod9_Q11C=YDN=ZXg@mail.gmail.com> <alpine.DEB.2.00.1309101934520.12199@ps20323.dreamhostps.com> Message-ID: <CADnb78j7UJe1rbCTuuvpXJhfHKkcib2Mqnc=iUoYS+Yh+p8itA@mail.gmail.com> On Tue, Sep 10, 2013 at 8:54 PM, Ian Hickson <ian at hixie.ch> wrote: > On Fri, 12 Jul 2013, Anne van Kesteren wrote: >> But then we shouldn't garble pathname either and we do because we have >> to. So I'm not sure that line of reasoning makes sense. I do think we >> should offer some kind of conversion utility between the two. > > It is unfortunate that resolving URLs does that, it's true. But just > because we're constrained here, why should we mess up domains also? Consistency. It means the entire URL is effectively a byte sequence. And it's very clear what the DNS lookup will be. And given that they keep insisting on changing what certain code points map to over in IETF-land (with limited support from browser vendors :/), it seems safer too. -- http://annevankesteren.nl/ From ian at hixie.ch Wed Sep 11 11:21:06 2013 From: ian at hixie.ch (Ian Hickson) Date: Wed, 11 Sep 2013 18:21:06 +0000 (UTC) Subject: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use In-Reply-To: <CADnb78j7UJe1rbCTuuvpXJhfHKkcib2Mqnc=iUoYS+Yh+p8itA@mail.gmail.com> References: <514A7477.6040905@mit.edu> <alpine.DEB.2.00.1307121809430.15729@ps20323.dreamhostps.com> <51E04C76.30200@mit.edu> <CAJE5ia_WTqejajPZVxf=cxTipvPyE=g0FWQfj-kJaj1tK583kw@mail.gmail.com> <51E04FDD.2080702@mit.edu> <CADnb78iniuYkyc4cH+RECg1p=ANVQPMz_sod9_Q11C=YDN=ZXg@mail.gmail.com> <alpine.DEB.2.00.1309101934520.12199@ps20323.dreamhostps.com> <CADnb78j7UJe1rbCTuuvpXJhfHKkcib2Mqnc=iUoYS+Yh+p8itA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309111819130.12210@ps20323.dreamhostps.com> On Wed, 11 Sep 2013, Anne van Kesteren wrote: > On Tue, Sep 10, 2013 at 8:54 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Fri, 12 Jul 2013, Anne van Kesteren wrote: > >> But then we shouldn't garble pathname either and we do because we > >> have to. So I'm not sure that line of reasoning makes sense. I do > >> think we should offer some kind of conversion utility between the > >> two. > > > > It is unfortunate that resolving URLs does that, it's true. But just > > because we're constrained here, why should we mess up domains also? > > Consistency. Surely the consistency of the API matching the input is more important than the consistency of the API _not_ matching the input... > It means the entire URL is effectively a byte sequence. I don't know what you mean here. > And it's very clear what the DNS lookup will be. Why do you think people care more about that than about the URL matching what they wrote in the markup? > And given that they keep insisting on changing what certain code points > map to over in IETF-land (with limited support from browser vendors :/), > it seems safer too. I don't understand what is safer. Surely if the punycoding step keeps changing, it's less safe, since it'll mean that the results will change without the author expecting it. If we don't punycode in the API, then the result will be the same regardless of the punycode step. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Sep 11 11:22:09 2013 From: ian at hixie.ch (Ian Hickson) Date: Wed, 11 Sep 2013 18:22:09 +0000 (UTC) Subject: [whatwg] URL resolution of fragment urls in html5 webapps In-Reply-To: <CADnb78iS2LsMporp8qKxFmmBy-rHH7q++_-osP94oaWAtjzdcw@mail.gmail.com> References: <CAO9zZYMo79Dqn-EK8S0j-M9sNJeFEGQg_XgP6+fsszDmq5oDMQ@mail.gmail.com> <CANr5HFXkxQuiy+n1jDkd=jP92Wz=E0_BrGbo40A0xxjpbAw2dQ@mail.gmail.com> <CAO9zZYOuSfkkGbqFWeeJ-gu1k0mZLFfnjrgkiweL+EN9aGGoiw@mail.gmail.com> <alpine.DEB.2.00.1309100013320.12199@ps20323.dreamhostps.com> <CADnb78iS2LsMporp8qKxFmmBy-rHH7q++_-osP94oaWAtjzdcw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309111821360.12210@ps20323.dreamhostps.com> On Wed, 11 Sep 2013, Anne van Kesteren wrote: > On Tue, Sep 10, 2013 at 8:34 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Wed, 10 Jul 2013, Rafael Weinstein wrote: > >> I'm curious: Is it useful to have fragment URL resolve against > >> anything other than the "display" url? I.e. when is the current > >> behavior wrt fragments appropriate. > > > > It's a good question. I thought the old IETF specs for URLs said you > > had to do otherwise, but nobody seems to have implemented that. > > Browsers have been inconsistent on this actually, not sure if they still > are. I think if we want to do this differently, then after trimming > whitespace to obtain the URL, the <a> element should have a special case > for # and pick a different base URL at that point. > > https://tools.ietf.org/html/rfc2396#section-4.2 has the vague wording > that does not take the base URL into account. In > https://tools.ietf.org/html/rfc3986#section-4.4 it does. The problem > with the former is that it's not clear when it applies, but we could > make that clear by only doing it in certain contexts, as I suggested > above. Well presumably we wouldn't want to only do it for <a>, since then links would work but SVG wouldn't (the exact opposite of the situation in Chrome now, for what it's worth). -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Sep 11 11:24:29 2013 From: ian at hixie.ch (Ian Hickson) Date: Wed, 11 Sep 2013 18:24:29 +0000 (UTC) Subject: [whatwg] High-density canvases In-Reply-To: <CAOp6jLZFD_HVKgEfEUB0myCdvz60i_=1NASVQ-YKyzcHxkDxVw@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> <CAGN7qDCC=8EZUpEmN=10tcWGU=8TPQ7rej+sOGhbPaWqqAjWRA@mail.gmail.com> <CAOp6jLZFD_HVKgEfEUB0myCdvz60i_=1NASVQ-YKyzcHxkDxVw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309111823370.12210@ps20323.dreamhostps.com> On Wed, 11 Sep 2013, Robert O'Callahan wrote: > > Pinch-zoom is hard because we don't want to trigger reflows or other > expensive behavior on pinch-zoom. I'd leave pinch-zoom out of it for > now. Unless I'm missing something fundamental, changing the pixel density doesn't cause a layout, it's changing the width that causes a layout. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From cabanier at gmail.com Wed Sep 11 11:57:11 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Wed, 11 Sep 2013 11:57:11 -0700 Subject: [whatwg] High-density canvases In-Reply-To: <alpine.DEB.2.00.1309111823370.12210@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> <CAGN7qDCC=8EZUpEmN=10tcWGU=8TPQ7rej+sOGhbPaWqqAjWRA@mail.gmail.com> <CAOp6jLZFD_HVKgEfEUB0myCdvz60i_=1NASVQ-YKyzcHxkDxVw@mail.gmail.com> <alpine.DEB.2.00.1309111823370.12210@ps20323.dreamhostps.com> Message-ID: <CAGN7qDDuFbHLb=O3bORKT1QuS2mrWnc-5e=hhVL+kQQ8K135cg@mail.gmail.com> On Wed, Sep 11, 2013 at 11:24 AM, Ian Hickson <ian at hixie.ch> wrote: > On Wed, 11 Sep 2013, Robert O'Callahan wrote: > > > > Pinch-zoom is hard because we don't want to trigger reflows or other > > expensive behavior on pinch-zoom. I'd leave pinch-zoom out of it for > > now. > > Unless I'm missing something fundamental, changing the pixel density > doesn't cause a layout, it's changing the width that causes a layout. It will do a layout if the width is directly or indirectly dependent on the CSS pixelratio. For instance, notice how the text boxes reflow if you change the page zoom: http://jsfiddle.net/BtAK7/1/ From ian at hixie.ch Wed Sep 11 12:47:29 2013 From: ian at hixie.ch (Ian Hickson) Date: Wed, 11 Sep 2013 19:47:29 +0000 (UTC) Subject: [whatwg] Sortable Tables In-Reply-To: <CALWjOx+vrmxTn6FA1dv+yWToix2frcWVtH7pr3mEoqUH0gCWZw@mail.gmail.com> References: <F9859A39-E9E5-43AC-BFBA-0786EDC128BC@crissov.de> <Pine.LNX.4.64.1211061922450.2478@ps20323.dreamhostps.com> <CAPGwD7iWT4Z_Ea14W0zapA69B-HaG_ZixwkF3jkg0=w3Jw0NyQ@mail.gmail.com> <Pine.LNX.4.64.1212270141200.16292@ps20323.dreamhostps.com> <50DDA850.7080307@gmx.ch> <alpine.DEB.2.00.1307182217440.9685@ps20323.dreamhostps.com> <CALWjOx+vrmxTn6FA1dv+yWToix2frcWVtH7pr3mEoqUH0gCWZw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309111857000.12210@ps20323.dreamhostps.com> On Fri, 19 Jul 2013, Stuart Langridge wrote: > On Thu, Jul 18, 2013 at 11:48 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > > > but <time> is more of a problem if you have multiple things in one > > > cell. For example, one semi-common pattern is to put some data and > > > an input type=checkbox in a single cell, like <td>Wed 7th November, > > > 10.00am GMT <input type="checkbox" name="whatever"></td> > > > > Why can't the checkbox be in a separate cell? > > I'm not saying that this is the way I do it: I'm saying this is what > authors are currently doing. If the checkboxes need to be in a separate > cell, then OK, but we'd need to explain that that's the case: that is, > the answer to "how do I sort a table by a column containing both data > and a checkbox" is "you can't. Put the checkboxes in a separate column." Yeah, fair enough. Hmm. So what should we do? Allow there to be multiple elements in the cell, but if we see a <time>/<meter>/<progress>/<data>, ignore all the others for sorting? Just look at the first element and if it's one of those, ignore all the others for sorting? I fear situations where people have two <time> elements and want them sorting by one then the other, or something. We could also have a way to say that certain elements are ignored... ignore all <input> and <img> elements? Ignore all elements with a new ignore-me- when-sorting="" attribute? I agree we should support the case you give. > Indeed, the objection to wrapping the whole cell content in <time> > applies to any cell which contains a time *and something else*: for > example, <td>Wed 7th November, 10.00am GMT <img src="morning.png"></td> > where the image displays a nice picture of the sun so you can see that > it's morning, but is only debatably part of the actual time itself. I'd feel much more comfortable saying the sun was part of the time than about the checkbox being part of the time. :-) > (And if you put it in a separate column, then there'll be a cell border > between the time and the icon.) That can be fixed with CSS, of course. > > > Using <data> to wrap the whole cell is OK, but using <time> to wrap > > > a bunch of non-time content isn't, really. In this situation would > > > you recommend <td><data value="2012-11-07T10:00Z"><time > > > datetime="2012-11-07T10:00Z">Wed 7th November, 10.00am > > > GMT</time></data></td> which seems rather redundant to me? > > > > I would recommend using two cells, but you could do that too. It would > > mean the keys were compared as strings, though, rather than as > > datetimes. Things wouldn't work if you mixed <data> and <time> > > elements with those values (e.g. if some cells didn't have checkboxes > > and so you used just <time> in some cases), since strings sort after > > times. > > erm. Why is the sort clever about datetimes? Time zones, knowing that "1:01" comes before "01:02", knowing that "P1D" comes before "25h", knowing that "1000-01-01" comes before "01010-10-10", knowing that "-01:00" comes before "Z" comes before "+01:00", knowing that 2013-W37 comes before 2013-10-11 but after 2013-10-09, etc. > Specifically, in order to specify a datetime attribute on a time > element, you have to specify it as a string, and those strings sort > correctly in order with other datetime strings. Not necessarily. Leading zeros are a problem for times, local-dates- and-times, and yearless dates, and all the other time formats have crazy stuff like time zones, multiple valid formats, etc. Also, the spec supports mixing different formats like week dates and years with date-and- time formats. > > > Maybe pass a cloneNode of each TD? > > > > Too expensive (what if one of the nodes is a 24 MB image, or a > > plugin?). > > But the cloned node isn't inserted into the document, right? Surely no > rendering engine is going to fully instantiate a 24MB image that's not > even in the document? An <img> element is instantiated when created, regardless of whether it's in a document or not. That's how you can do preloading of images for rollovers, if you're stuck in the 90s. :-) > > > Or have the sorter work out the sortable *value* of the field (from > > > the content, or the <data value> wrapper) and then pass the values, > > > not the actual cells? Then the comparator can't destroy anything. > > > > It seems to me like that doesn't give you anything that you couldn't > > do by just setting the keys manually on the table before the sort > > happens (which you can do easily onsort="" in the current model). > > Big difference: setting the keys manually onsort is indeed something > that the author can do. But calculating the sortable value of the cell > (either from an explicitly set key, or from the cell content) is > something that the *browser* can do: that is, it can be part of the > spec. So then you're never in danger from dangerous comparators, because > the sort engine algorithm is: (1) for each cell in the column, calculate > its sortable value and make a list of [sortable value, reference to > cell], (2) sort that list, and for each comparison during sorting pass > the two sortable values you want to compare, but *not* the cell > references, to the comparator, (3) now you have a sorted list; shuffle > the actual table rows into the order of the list. This is what my > sorttable script does, and for exactly the reasons that you outline; > that a sort comparator function doesn't get passed the actual TDs, just > their content. If you call script at all, it can mess up the table, whether or not you hand it a reference to the table. But my point above was: what's the difference between allowing authors to set the comparator function, and letting authors assign the sortable value when there's a known comparator function? Both get you the same effect, surely. The advantage is one doesn't need to involve calling script while the table is being sorted. > > > Left-hand header columns (although as noted this is sorta-kinda > > > presentational and should be done with tr::before, but authors will > > > do it in the HTML for backwards-compatiblity if nothing else). > > > > Not sure I follow that one. > > I, Mr Author, have a table on my page, and that table has row numbers, > explicitly in the HTML as the first column. (<tr><td>1</td><td>...</tr>) > I wrote the page 5 years ago, and half my users are still, depressingly, > on IE6. The other half are all running Chrome Canary, usefully. So this > sorting stuff arrives and I think: I'd like this table to be sortable. > So I bang the sort stuff in, knowing full well that the IE6 people don't > get to sort the table, and that's fine (progressive enhancement, wot?), > and the Chrome people say "oh, man, the row numbers get jumbled!" and I > say "ah, you're quite right", and remove them from the HTML to be > replaced with CSS tr::before { content: index(row) } or something. And > then the IE6 people say: we don't have any row numbers any more! I am > not sure how this is reconcilable. Either older browsers don't get row > numbers, or newer ones get them jumbled... I don't know how to fix this in a world where we're sorting groups of rows. I mean, if group #1 is a single row, and group #2 has two rows, and group #3 has three rows but its first cell spans all three, what do you do when the order is changed to #3-#1-#2, if the first column is one of these "keep the numbers consistent" columns? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Sep 11 13:04:40 2013 From: ian at hixie.ch (Ian Hickson) Date: Wed, 11 Sep 2013 20:04:40 +0000 (UTC) Subject: [whatwg] High-density canvases In-Reply-To: <CAGN7qDDuFbHLb=O3bORKT1QuS2mrWnc-5e=hhVL+kQQ8K135cg@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> <CAGN7qDCC=8EZUpEmN=10tcWGU=8TPQ7rej+sOGhbPaWqqAjWRA@mail.gmail.com> <CAOp6jLZFD_HVKgEfEUB0myCdvz60i_=1NASVQ-YKyzcHxkDxVw@mail.gmail.com> <alpine.DEB.2.00.1309111823370.12210@ps20323.dreamhostps.com> <CAGN7qDDuFbHLb=O3bORKT1QuS2mrWnc-5e=hhVL+kQQ8K135cg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309112004080.12199@ps20323.dreamhostps.com> On Wed, 11 Sep 2013, Rik Cabanier wrote: > On Wed, Sep 11, 2013 at 11:24 AM, Ian Hickson <ian at hixie.ch> wrote: > > On Wed, 11 Sep 2013, Robert O'Callahan wrote: > > > > > > Pinch-zoom is hard because we don't want to trigger reflows or other > > > expensive behavior on pinch-zoom. I'd leave pinch-zoom out of it for > > > now. > > > > Unless I'm missing something fundamental, changing the pixel density > > doesn't cause a layout, it's changing the width that causes a layout. > > It will do a layout if the width is directly or indirectly dependent on > the CSS pixelratio. For instance, notice how the text boxes reflow if > you change the page zoom: http://jsfiddle.net/BtAK7/1/ Sure. But pinch-zoom doesn't change the width. (Page zoom does.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From barraclough at apple.com Wed Sep 11 15:05:06 2013 From: barraclough at apple.com (Gavin Barraclough) Date: Wed, 11 Sep 2013 15:05:06 -0700 Subject: [whatwg] [[GetOwnProperty]] for named properties of the Window object In-Reply-To: <52293AC6.5020108@mit.edu> References: <52600B08-E2BB-4AA3-877E-797E1CF687BC@apple.com> <52293AC6.5020108@mit.edu> Message-ID: <C9BAE4B7-C54B-451A-872D-40D6CEAED23C@apple.com> Hi Boris, Thanks, this is really helpful. On Sep 5, 2013, at 7:15 PM, Boris Zbarsky <bzbarsky at MIT.EDU> wrote: > Ccing public-script-coord, since that's the right place for this discussion (because WebIDL is the relevant specification). > > On 9/5/13 6:45 PM, Gavin Barraclough wrote: >> Firefox and Chrome both return descriptors from an object on the prototype chain per the spec > > Chrome doesn't quite follow the spec here, for what it's worth: it returns them from Window.prototype as far as I can tell, not from an actual named properties object. Interesting, I had just assumed this was okay ? is it not spec-compliant for Window.prototype to be a named properties object? >> attributes of the value are configured differently, with enumerable set to false, writable and configurable set to true. > > Current tip Firefox returns {"configurable":true,"enumerable":true,"writable":true} and enumerates the properties. Probably a change from https://bugzilla.mozilla.org/show_bug.cgi?id=895758 to align better with the spec in terms of the enumeration behavior. > >> There seem to be some compelling reasons to follow Firefox / Chrome (writable true seems more congruent with ECMA262 specified [[Put]] > > Indeed. I think the current setup in the spec would make window.foo not settable if <img id="foo"> exists.... That seems bad. I believe these properties are implemented as shadowable in the same way as [Replaceable] properties, so I was somewhat expecting the spec to define properties returned by named property objects to implicitly have the [Replaceable] extended attribute specified in WebIDL (and then assume a modified behaviour of ES [Put] for properties with this attribute, to permit overwrite even if readonly). But I?m not yet familiar enough with the spec to know if this is a reasonable line of thought. :-) Thanks, Gavin >> unless there is another mechanism I?m missing here, enumerable is odd since I don?t think the spec says anything about [[GetOwnPropertyNames]]) > > It doesn't, but it does talk about enumeration; see http://dev.w3.org/2006/webapi/WebIDL/#property-enumeration (whether that's applicable to the Named Properties Object is an interesting question). > > Granted, I would rather that were defined in terms of [[GetOwnPropertyNames]] on the relevant objects instead; that's what actually needs to happen under the hood anyway. > >> ,so I was hoping to better understand why the spec requires the behaviour it does (or whether I?m just following it incorrectly!) > > I think you're following it correctly; it's just buggy. ;) > > -Boris From ian at hixie.ch Wed Sep 11 17:24:24 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 12 Sep 2013 00:24:24 +0000 (UTC) Subject: [whatwg] img loading events - can load & error fire for the same image? In-Reply-To: <CAJ5xic9oYSJZEYQ49qiPTEkAibxJmKF76PK++CZQqjQh2krrjg@mail.gmail.com> References: <CAJ5xic_1LJES_oEk5HZ3hQgDJd5dVqs_mxFk3xT9c1XO-ijE_Q@mail.gmail.com> <alpine.DEB.2.00.1307121911080.15729@ps20323.dreamhostps.com> <CAJ5xic9oYSJZEYQ49qiPTEkAibxJmKF76PK++CZQqjQh2krrjg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309112252030.12199@ps20323.dreamhostps.com> On Mon, 22 Jul 2013, Jake Archibald wrote: > > Take http://jsbin.com/ifihex/1/edit - the image on this page receives a > valid & full HTTP request, but the received data isn't valid image data > (it's html). > > Starting from > http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#update-the-image-data, > here's how I see the image loading according to the spec > > (everything seems fine until step 14) > [...] > * this is the point where I start to get lost, I'm not sure which > else-like statements (as in "On the other hand" and "Otherwise") are > linked to which if-like statements Oh, yeah, this is very confusing. My bad. I've tried to fix it. Let me know how it is now. > >> "load" is fired once the width & height can be determined, which > >> suggests that an un-decodable image, but with intact headers (which > >> give the width & height) will fire "load" but not "error". I agree > >> with this, as it means the browser can defer decoding to render time, > >> but do we need a way in JS to confirm an image is decodable? > > > > What's the use case? (Surely the server should check this on the > > server.) > > The use-case would be image loading that happened without a server. Eg, > an in-browser Photoshop that operated without user interaction. User > selects file on their machine, it has correct headers so fires a load > event, but cannot be painted onto the canvas (or paints incorrectly) due > to corrupt data. The in-browser app is unable to detect the image is > corrupt without building a decoder/validator in JS. Well... there is one way to tell right now. You can try to draw it to a <canvas> and see if anything got drawn by examining all the pixels; if no pixels got drown, then it has some data integrity issues. But really if you're implementing a Photoshop equivalent, you really _should_ implement your own decoder, so you can do things like EXIF manipulation, handle other image formats, do "pngcrush"-like work, etc. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Sep 11 17:54:10 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 12 Sep 2013 00:54:10 +0000 (UTC) Subject: [whatwg] Outline style to use for drawSystemFocusRing In-Reply-To: <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> References: <CAFz-FYxS-sLLOMA2=5bj-aJ1bmsBq8w_4Rminw_JLCMnYaMfPw@mail.gmail.com> <alpine.DEB.2.00.1307242308540.27623@ps20323.dreamhostps.com> <CAGN7qDCdCR1F-D9PtEKUcHkh5KdwKhum4vEAyUQ0VkLeeC+PCA@mail.gmail.com> <alpine.DEB.2.00.1307292147040.27623@ps20323.dreamhostps.com> <CAGN7qDAaq8XnX1z_BbpLVhgE5m4j--b720ZuHSEzq_iN1es0=Q@mail.gmail.com> <alpine.DEB.2.00.1307300020510.27623@ps20323.dreamhostps.com> <CAGN7qDAjRPOQ25gQT+BY+sp8Y503_9KxTa1j2aZSGYU-9BmBVA@mail.gmail.com> <CAFz-FYzzPFU3g+fM+QGbEDAJ-3DSU2qGHY9R+heZRbAWVAN2rw@mail.gmail.com> <CAGN7qDDu3PNxK9PTVr09sqUc0FrOnXgRaQDwLXQ13BhH_=85Bw@mail.gmail.com> <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309120051240.12199@ps20323.dreamhostps.com> On Tue, 10 Sep 2013, Dominic Mazzoni wrote: > > We've finished implementing drawSystemFocusRing and drawCustomFocusRing > in Chrome. Try it in Chrome 31 or higher (either canary or dev channel > should work today). You'll need to go to chrome://flags and enable > *experimental canvas features*, then restart the browser. > > Here's a demo I built that uses drawSystemFocusRing: > http://dmazzoni-google.github.io/canvas-focus-ring-demo/ Looks good. Was your conclusion that the spec was ok as is, or did you deviate from the spec in some way that needs a spec change? (Apologies if you've already reported some feedback that I've lost track of; I didn't see any when I looked just now.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From bzbarsky at MIT.EDU Wed Sep 11 18:07:54 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Wed, 11 Sep 2013 21:07:54 -0400 Subject: [whatwg] [[GetOwnProperty]] for named properties of the Window object In-Reply-To: <C9BAE4B7-C54B-451A-872D-40D6CEAED23C@apple.com> References: <52600B08-E2BB-4AA3-877E-797E1CF687BC@apple.com> <52293AC6.5020108@mit.edu> <C9BAE4B7-C54B-451A-872D-40D6CEAED23C@apple.com> Message-ID: <523113EA.4030908@mit.edu> On 9/11/13 6:05 PM, Gavin Barraclough wrote: > Interesting, I had just assumed this was okay ? is it not spec-compliant for Window.prototype to be a named properties object? No, it's not. The spec defines exactly what the prototype chain looks like here. See the definitions of [[Prototype]] at http://dev.w3.org/2006/webapi/WebIDL/#named-properties-object and http://dev.w3.org/2006/webapi/WebIDL/#interface-prototype-object (item 1 at the latter). So the chain by default is window -> Window.prototype -> named properties object -> EventTarget.prototype -> Object.prototype. This allows specification of the named properties object without having to worry about weird interactions with name collisions on Window.prototype, whether with properties it has by default or properties someone wants to add to it. Note that the named properties object does not allow [[DefineOwnProperty]], so if it were Window.prototype then you wouldn't be able to add any properties to Window.prototype! > I believe these properties are implemented as shadowable in the same way as [Replaceable] properties [Replaceable] properties need the magic they have because they're accessor properties, which normally can't be shadowed via assignment. But named properties on the named properties object are value properties, so simply making them writable allows them to be shadowed. In fact, that's the only way to make them shadowable. > (and then assume a modified behaviour of ES [Put] for properties with this attribute, to permit overwrite even if readonly). I don't think a special [Put] is needed if the properties aren't readonly. -Boris From ian at hixie.ch Wed Sep 11 18:08:10 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 12 Sep 2013 01:08:10 +0000 (UTC) Subject: [whatwg] remove resetClip from the Canvas 2D spec In-Reply-To: <CAA5isUZ4pX3gzMvDfHXVqyOJvHVWdcyGzEBYURxNdgFrAHYgUQ@mail.gmail.com> References: <CAGN7qDC_ox_31kaFzutQn__sRdGe2kmCBQJkDQtKB9NRi+8ztQ@mail.gmail.com> <alpine.DEB.2.00.1307181720430.9685@ps20323.dreamhostps.com> <CAPeKFTjBh08ihwtwKPo54LTr14JbbiwYequMsPZD-Oq2EGk8QA@mail.gmail.com> <alpine.DEB.2.00.1308092019440.27623@ps20323.dreamhostps.com> <CABpaAqThhmOZEGDJ4P2A21xwszF=R+X9H5Ah3ZNjC+htmQpGkw@mail.gmail.com> <CAGN7qDBiQOdTSYfj7T0ek--UW+aQU1q=fV=imQZv_E2s1Nc38w@mail.gmail.com> <CABpaAqQYM4-pCfyB-Sap4yC2Uera_Us+viPKF8Q0BYgLdZ47xg@mail.gmail.com> <CAGN7qDDqVb7OQxH-R+pyQL0ZrnPKxzpVTT-oDzgT+JyuY7MMPg@mail.gmail.com> <CABpaAqSDq_wDL7J5gTJGuUrUApYdm5rbWu8QcNg6ozA0ASwF4w@mail.gmail.com> <CAA5isUaqWcDhRLj3MVa1Jef_LCgpkohLZo-QHibAK3Cd3d_Pcw@mail.gmail.com> <CABpaAqRX6mc5zvATrE31q+F7z6Pm-wNy2MEE4749SLW0k5_3VA@mail.gmail.com> <CAGN7qDCF7YjtbXNv=VkxAx1hhEaLSCCTZEk2SJXMzCbcOiFhuA@mail.gmail.com> <CAPeKFTi+WfPqK1E8SfxrW3+qwBHDeYkZk2JbWtDFB3mSAs98=g@mail.gmail.com> <CAA5isUZ4pX3gzMvDfHXVqyOJvHVWdcyGzEBYURxNdgFrAHYgUQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309120056550.12199@ps20323.dreamhostps.com> On Fri, 9 Aug 2013, Simon Sarris wrote: > > As an alternative [to resetClip()] I would propose something like > setClip() or setClip(path) (with the former working on the current path, > just like clip()/fill()/stroke() does). Seems like this would have the same problems as resetClip(), since it's essentially the same as a call to resetClip() followed by a call to clip(). On Fri, 9 Aug 2013, Justin Novosad wrote: > > What if resetClip restored the clip to what it was at the save call that > created the current state stack level? In other words, restore the clip, > but without popping it off the save/restore stack. > > Also, resetMatrix could be defined to do the same. Wouldn't that be the same as just save()/clip()/restore() ? On Mon, 12 Aug 2013, Rik Cabanier wrote: > > It would be good to hear specific use cases for 'resetClip' so we can make > that call. The main use case would be something like: c.save(); c.resetTransform(); c.resetClip(); // draw something at the top right... c.restore(); ...deep inside some draw code. > > Also, resetMatrix could be defined to do the same. > > Is that API defined somewhere? I think Justin meant resetTransform(). On Mon, 12 Aug 2013, Simon Sarris wrote: > > I think most performance-minded use cases will be fine with junov's idea > since they will not want to touch the stack in the first place. > > Here's a simple use case: Suppose there are nested objects to be drawn, > Panels, TextBlocks, and other visual elements. Panels are containers that > draw a background and all of their children - and they contain any number > of Panels or TextBlocks or other elements, and TextBlocks set the context > font (to their font) and draw some text. > > The drawing structure is hierarchical, and drawn elements may be offset > from their immediate parent. So a drawing hierarchy might look like this: > > Panel(A) > Panel(B) > TextBlock > TextBlock > > That is, Panel(A) contains Panel(B) and a TextBlock. And Panel(B) contains > another TextBlock. In practice, nesting could be much deeper and more > complicated. > > Now suppose also that Panels have some settings, such as a maximum width, > that might cause their visual elements to be clipped. So a panel might need > to save(), clip(), draw all of its children, and then restore(). Nesting > means multiple levels of clipping, for instance with the above hierarchy it > might look like: > > Panel(A) > clip (save) > drawChildren: > Panel(B) > clip (save) > drawChildren: > TextBlock > sets font X > fillText > restore > TextBlock > sets font X > fillText > restore > > This is problematic, because it means: > > 1. I must use save() and restore(), which are slow in their own right I'm pretty sure save() and restore() are the right solution here. If those don't work, we should fix those, not add more features that might have their own issues. > 2. The usage of save() and restore() means that, even if all (or most) of > my fonts are set to the same value, I have to keep setting them over and > over. Setting the font is slow in practice, even if it is set to the same > value as before, and so it should be cached if at all possible. Again, if settings fonts is slow, that should be fixed independently of resetClip(). On Mon, 12 Aug 2013, Justin Novosad wrote: > > Good point, I think part of the problem has to do with the fact that save > is non-selective (saves all of the state). > Might be worthwhile to have a selective save that pushes only a > user-specified subset of the current state onto the stack. There's no reason save() and restore() need be slow just because they save a lot. It's relatively easy to have a stack that only saves the things that have changed (e.g. by setting a bit when you change things, so you know what has changed, and then only pushing onto the stack the instructions to change the stuff that has changed). On Mon, 12 Aug 2013, Simon Sarris wrote: > > Yes, since save() and restore() save and restore everything, it creates > the side effect of needing to set ctx.font/fillStyle/strokeStyle more > often than otherwise, which are slow to set, probably because of some > CSS parser activity, but I'm not wise enough to know. save() and restore() should have no reason to go through the CSS parser. On Mon, 12 Aug 2013, Justin Novosad wrote: > > Ok, so here is a simple proposal: > > IDL: > enum CanvasSaveMode { "all", "transform", "clip", "transform-and-clip" }; > save(optional CanvasSaveMode mode); > > Modes: > all: save the entire rendering context state > transform: save only the current transform > clip: save only the current clip > > if mode is not specified, the entire context state is saved (for backward > compatibility) > > The restore method's interface does not change. It restores whatever state > was saved by the matching save call. I don't understand what problem this is solving. On Tue, 13 Aug 2013, Simon Sarris wrote: > > I'd argue its not strictly a performance issue. More generally its > awkward that you can reset any piece of the canvas context state except > the clipping region. The clipping region alone requires you to clobber > all state in order to reset it. > > You can set the fillStyle back to black, you can set the transformation > matrix back to identity, etc. But you can't set the clipping region back > to the entire canvas area without save()/restore() or > can.width=can.width. It's the only thing like that. > > That ought to be considered bad on principle I think. It makes clipping > a really odd operation compared to anything else, and at the least it > makes the one part of the API unintuitive. This is the argument for resetClip(), though the only use case seems to be the one I mentioned (drawing something at the top right, or whatever, deep inside some code that has clipped and transformed). I've marked the resetClip() feature in the spec as being considered form removal. If no browser implement it in due course, I'll remove it. Despite being relatively commonly requested, it must be admitted that the use cases for this feature aren't that compelling. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From robert at ocallahan.org Thu Sep 12 00:17:31 2013 From: robert at ocallahan.org (Robert O'Callahan) Date: Thu, 12 Sep 2013 00:17:31 -0700 Subject: [whatwg] High-density canvases In-Reply-To: <alpine.DEB.2.00.1309111823370.12210@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> <CAGN7qDCC=8EZUpEmN=10tcWGU=8TPQ7rej+sOGhbPaWqqAjWRA@mail.gmail.com> <CAOp6jLZFD_HVKgEfEUB0myCdvz60i_=1NASVQ-YKyzcHxkDxVw@mail.gmail.com> <alpine.DEB.2.00.1309111823370.12210@ps20323.dreamhostps.com> Message-ID: <CAOp6jLaxkdDE5qKaZmUxHs5Jic8h3yCnE+j7dCUgAHQWLQBiEg@mail.gmail.com> On Wed, Sep 11, 2013 at 11:24 AM, Ian Hickson <ian at hixie.ch> wrote: > On Wed, 11 Sep 2013, Robert O'Callahan wrote: > > Pinch-zoom is hard because we don't want to trigger reflows or other > > expensive behavior on pinch-zoom. I'd leave pinch-zoom out of it for > > now. > > Unless I'm missing something fundamental, changing the pixel density > doesn't cause a layout, it's changing the width that causes a layout. > Changing pixel density does cause a layout in Gecko. For example we round CSS border widths to a whole number of device pixels. (This ensures that when page zoom is applied, all borders with the same specified width are rendered with the same visual width.) On some platforms (Windows), changing pixel density affects text hinting which affects text layout. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * From annevk at annevk.nl Thu Sep 12 02:24:32 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Thu, 12 Sep 2013 10:24:32 +0100 Subject: [whatwg] URL resolution of fragment urls in html5 webapps In-Reply-To: <alpine.DEB.2.00.1309111821360.12210@ps20323.dreamhostps.com> References: <CAO9zZYMo79Dqn-EK8S0j-M9sNJeFEGQg_XgP6+fsszDmq5oDMQ@mail.gmail.com> <CANr5HFXkxQuiy+n1jDkd=jP92Wz=E0_BrGbo40A0xxjpbAw2dQ@mail.gmail.com> <CAO9zZYOuSfkkGbqFWeeJ-gu1k0mZLFfnjrgkiweL+EN9aGGoiw@mail.gmail.com> <alpine.DEB.2.00.1309100013320.12199@ps20323.dreamhostps.com> <CADnb78iS2LsMporp8qKxFmmBy-rHH7q++_-osP94oaWAtjzdcw@mail.gmail.com> <alpine.DEB.2.00.1309111821360.12210@ps20323.dreamhostps.com> Message-ID: <CADnb78iHZEKdX8F_76vezghkXNiXcq64Edmr2-ofHKhZ17hJcQ@mail.gmail.com> On Wed, Sep 11, 2013 at 7:22 PM, Ian Hickson <ian at hixie.ch> wrote: > Well presumably we wouldn't want to only do it for <a>, since then links > would work but SVG wouldn't (the exact opposite of the situation in Chrome > now, for what it's worth). Yeah, we should have to do it for everything we classify as "hyperlink". <a>, <svg:a>, <area>, and <link> I suppose. I'm not sure what in MathML would need covering. -- http://annevankesteren.nl/ From annevk at annevk.nl Thu Sep 12 02:56:32 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Thu, 12 Sep 2013 10:56:32 +0100 Subject: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use In-Reply-To: <alpine.DEB.2.00.1309111819130.12210@ps20323.dreamhostps.com> References: <514A7477.6040905@mit.edu> <alpine.DEB.2.00.1307121809430.15729@ps20323.dreamhostps.com> <51E04C76.30200@mit.edu> <CAJE5ia_WTqejajPZVxf=cxTipvPyE=g0FWQfj-kJaj1tK583kw@mail.gmail.com> <51E04FDD.2080702@mit.edu> <CADnb78iniuYkyc4cH+RECg1p=ANVQPMz_sod9_Q11C=YDN=ZXg@mail.gmail.com> <alpine.DEB.2.00.1309101934520.12199@ps20323.dreamhostps.com> <CADnb78j7UJe1rbCTuuvpXJhfHKkcib2Mqnc=iUoYS+Yh+p8itA@mail.gmail.com> <alpine.DEB.2.00.1309111819130.12210@ps20323.dreamhostps.com> Message-ID: <CADnb78iQ6TnDD+p=WPs8=xFDKYG=QiiBSaxOVj9gqrWYAxzbAA@mail.gmail.com> On Wed, Sep 11, 2013 at 7:21 PM, Ian Hickson <ian at hixie.ch> wrote: > Surely the consistency of the API matching the input is more important > than the consistency of the API _not_ matching the input... The input will be mangled anyway. E.g. domain label separators are normalized to ".". And all kinds of other parts of the URL undergo normalization. >> It means the entire URL is effectively a byte sequence. > > I don't know what you mean here. No code point is higher than 7F. And given the way HTTP operates on URLs, and we extract data from data URLs, making it a byte sequence might not be a such a bad idea... >> And it's very clear what the DNS lookup will be. > > Why do you think people care more about that than about the URL matching > what they wrote in the markup? It won't match that anyway. >> And given that they keep insisting on changing what certain code points >> map to over in IETF-land (with limited support from browser vendors :/), >> it seems safer too. > > I don't understand what is safer. Surely if the punycoding step keeps > changing, it's less safe, since it'll mean that the results will change > without the author expecting it. If we don't punycode in the API, then the > result will be the same regardless of the punycode step. It depends on what you do with the result I suppose. https://groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/blink-dev/fBsVRcEOTWM seems relevant. http://url.spec.whatwg.org/ defines ASCII at the moment. The other reason that is I just remembered is because ToASCII can fail and at that point we want to return failure for the URL. I suppose we could run ToASCII and then ToUnicode... -- http://annevankesteren.nl/ From rashmi.shyam at gmail.com Thu Sep 12 03:48:54 2013 From: rashmi.shyam at gmail.com (Rashmi Shyamasundar) Date: Thu, 12 Sep 2013 16:18:54 +0530 Subject: [whatwg] whatwg Digest, Vol 114, Issue 19 In-Reply-To: <mailman.23942.1378977874.52932.whatwg-whatwg.org@lists.whatwg.org> References: <mailman.23942.1378977874.52932.whatwg-whatwg.org@lists.whatwg.org> Message-ID: <CAEiriRZCPSb_F55Heh-KyNAVj5LjhOpZ-_oxXGOr9KRV8bYKZg@mail.gmail.com> Hi All, This is regarding the resetClip() API for canvas. Please take a look at my patches to the bug https://bugs.webkit.org/show_bug.cgi?id=82801. resetClip() can be implemented in Cairo, without any overhead, since Cairo supports resetClip. I tried to implement the API in CG, using the below approach :- (Please check https://bugs.webkit.org/show_bug.cgi?id=82801#c9 ) Steps :- When resetClip() is called, 1. Save the imageData from canvas imageBuffer 2. Save the GraphicsContextState 3. Clear the canvas buffer. This will delete the buffer and GraphicsContextStateSaver. 4. Copy the saved imageData to a new imageBuffer 5. Set the graphicsContextState to the saved state. GraphicsContextState does not have information about any clip. The drawback with the above approach is that clipping-region cannot be restored since it is not part of the GraphicsContextState or CanvasRenderingContext2D::State. Currently clipping-region is not saved in GraphicsContextState or CanvasRenderingContext2D::State. If clipping-region is somehow saved in GraphicsContextState and CanvasRenderingContext2D::State then, through step#5, clipping region can also be restored. Below is an example which will not work in CG (But, Works perfectly in Cairo), if clipping-region is not saved in GraphicsContextState and CanvasRenderingContext2D::State :- ctx.clip(); ctx.save(); ctx.resetClip(); ...; // draw with no clip ctx.restore(); ...; // draw with a clip (This draw does not contain any clip) Thanks, Rashmi > > Message: 7 > Date: Thu, 12 Sep 2013 01:08:10 +0000 (UTC) > From: Ian Hickson <ian at hixie.ch> > To: WHATWG List <whatwg at whatwg.org> > Subject: Re: [whatwg] remove resetClip from the Canvas 2D spec > Message-ID: > <alpine.DEB.2.00.1309120056550.12199 at ps20323.dreamhostps.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Fri, 9 Aug 2013, Simon Sarris wrote: > > > > As an alternative [to resetClip()] I would propose something like > > setClip() or setClip(path) (with the former working on the current path, > > just like clip()/fill()/stroke() does). > > Seems like this would have the same problems as resetClip(), since it's > essentially the same as a call to resetClip() followed by a call to clip(). > > > On Fri, 9 Aug 2013, Justin Novosad wrote: > > > > What if resetClip restored the clip to what it was at the save call that > > created the current state stack level? In other words, restore the clip, > > but without popping it off the save/restore stack. > > > > Also, resetMatrix could be defined to do the same. > > Wouldn't that be the same as just save()/clip()/restore() ? > > > On Mon, 12 Aug 2013, Rik Cabanier wrote: > > > > It would be good to hear specific use cases for 'resetClip' so we can > make > > that call. > > The main use case would be something like: > > c.save(); > c.resetTransform(); > c.resetClip(); > // draw something at the top right... > c.restore(); > > ...deep inside some draw code. > > > > > Also, resetMatrix could be defined to do the same. > > > > Is that API defined somewhere? > > I think Justin meant resetTransform(). > > > On Mon, 12 Aug 2013, Simon Sarris wrote: > > > > I think most performance-minded use cases will be fine with junov's idea > > since they will not want to touch the stack in the first place. > > > > Here's a simple use case: Suppose there are nested objects to be drawn, > > Panels, TextBlocks, and other visual elements. Panels are containers that > > draw a background and all of their children - and they contain any number > > of Panels or TextBlocks or other elements, and TextBlocks set the context > > font (to their font) and draw some text. > > > > The drawing structure is hierarchical, and drawn elements may be offset > > from their immediate parent. So a drawing hierarchy might look like this: > > > > Panel(A) > > Panel(B) > > TextBlock > > TextBlock > > > > That is, Panel(A) contains Panel(B) and a TextBlock. And Panel(B) > contains > > another TextBlock. In practice, nesting could be much deeper and more > > complicated. > > > > Now suppose also that Panels have some settings, such as a maximum width, > > that might cause their visual elements to be clipped. So a panel might > need > > to save(), clip(), draw all of its children, and then restore(). Nesting > > means multiple levels of clipping, for instance with the above hierarchy > it > > might look like: > > > > Panel(A) > > clip (save) > > drawChildren: > > Panel(B) > > clip (save) > > drawChildren: > > TextBlock > > sets font X > > fillText > > restore > > TextBlock > > sets font X > > fillText > > restore > > > > This is problematic, because it means: > > > > 1. I must use save() and restore(), which are slow in their own right > > I'm pretty sure save() and restore() are the right solution here. If those > don't work, we should fix those, not add more features that might have > their own issues. > > > > 2. The usage of save() and restore() means that, even if all (or most) of > > my fonts are set to the same value, I have to keep setting them over and > > over. Setting the font is slow in practice, even if it is set to the same > > value as before, and so it should be cached if at all possible. > > Again, if settings fonts is slow, that should be fixed independently of > resetClip(). > > > On Mon, 12 Aug 2013, Justin Novosad wrote: > > > > Good point, I think part of the problem has to do with the fact that save > > is non-selective (saves all of the state). > > Might be worthwhile to have a selective save that pushes only a > > user-specified subset of the current state onto the stack. > > There's no reason save() and restore() need be slow just because they save > a lot. It's relatively easy to have a stack that only saves the things > that have changed (e.g. by setting a bit when you change things, so you > know what has changed, and then only pushing onto the stack the > instructions to change the stuff that has changed). > > > On Mon, 12 Aug 2013, Simon Sarris wrote: > > > > Yes, since save() and restore() save and restore everything, it creates > > the side effect of needing to set ctx.font/fillStyle/strokeStyle more > > often than otherwise, which are slow to set, probably because of some > > CSS parser activity, but I'm not wise enough to know. > > save() and restore() should have no reason to go through the CSS parser. > > > On Mon, 12 Aug 2013, Justin Novosad wrote: > > > > Ok, so here is a simple proposal: > > > > IDL: > > enum CanvasSaveMode { "all", "transform", "clip", "transform-and-clip" }; > > save(optional CanvasSaveMode mode); > > > > Modes: > > all: save the entire rendering context state > > transform: save only the current transform > > clip: save only the current clip > > > > if mode is not specified, the entire context state is saved (for backward > > compatibility) > > > > The restore method's interface does not change. It restores whatever > state > > was saved by the matching save call. > > I don't understand what problem this is solving. > > > On Tue, 13 Aug 2013, Simon Sarris wrote: > > > > I'd argue its not strictly a performance issue. More generally its > > awkward that you can reset any piece of the canvas context state except > > the clipping region. The clipping region alone requires you to clobber > > all state in order to reset it. > > > > You can set the fillStyle back to black, you can set the transformation > > matrix back to identity, etc. But you can't set the clipping region back > > to the entire canvas area without save()/restore() or > > can.width=can.width. It's the only thing like that. > > > > That ought to be considered bad on principle I think. It makes clipping > > a really odd operation compared to anything else, and at the least it > > makes the one part of the API unintuitive. > > This is the argument for resetClip(), though the only use case seems to be > the one I mentioned (drawing something at the top right, or whatever, deep > inside some code that has clipped and transformed). > > I've marked the resetClip() feature in the spec as being considered form > removal. If no browser implement it in due course, I'll remove it. Despite > being relatively commonly requested, it must be admitted that the use > cases for this feature aren't that compelling. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > > > ------------------------------ > > From dino at apple.com Thu Sep 12 07:11:56 2013 From: dino at apple.com (Dean Jackson) Date: Thu, 12 Sep 2013 09:11:56 -0500 Subject: [whatwg] High-density canvases In-Reply-To: <CAOp6jLZFD_HVKgEfEUB0myCdvz60i_=1NASVQ-YKyzcHxkDxVw@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> <CAGN7qDCC=8EZUpEmN=10tcWGU=8TPQ7rej+sOGhbPaWqqAjWRA@mail.gmail.com> <CAOp6jLZFD_HVKgEfEUB0myCdvz60i_=1NASVQ-YKyzcHxkDxVw@mail.gmail.com> Message-ID: <BCF6563F-D903-409E-9DE4-BCC76ADF3111@apple.com> On 11 Sep 2013, at 3:20 am, Robert O'Callahan <robert at ocallahan.org> wrote: > On Tue, Sep 10, 2013 at 1:26 PM, Rik Cabanier <cabanier at gmail.com> wrote: > There's a thread on www-style: > http://lists.w3.org/Archives/Public/www-style/2012Nov/0144.html > It's been in firefox for a while and blink is going to ship it soon: > https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/RyUSi3zdumQ > > devicePixelRatio has reflected page zoom in Firefox ever since we first exposed it (because the thing it maps to internally has always been affected by page zoom). OK. I can accept that it makes sense for page zoom (I was only thinking about pinch zoom... which is a bad name). Still, we've (Apple) been telling developers for a long time that devicePixelRatio is (basically) constant. I guess we'll have to either change or be non-conformant. > > > > Actually what I really think we should do is also change the > > > window.devicePixelRatio for pinch zoom. Combined with the suggestions for > > > canvas, that would allow (as Rik pointed out on IRC) for high-quality > > > canvas all the way zoomed in, and for cheap canvases when zoomed out > > I believe pinch zoom should not change devicePixelRatio. It would be nice > if there was a standard way to determine pinch zoom though and if the > canvas could automatically resize. > > Pinch-zoom is hard because we don't want to trigger reflows or other expensive behavior on pinch-zoom. I'd leave pinch-zoom out of it for now. Agreed. Dean From bzbarsky at MIT.EDU Thu Sep 12 08:51:56 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Thu, 12 Sep 2013 11:51:56 -0400 Subject: [whatwg] URL resolution of fragment urls in html5 webapps In-Reply-To: <CADnb78iHZEKdX8F_76vezghkXNiXcq64Edmr2-ofHKhZ17hJcQ@mail.gmail.com> References: <CAO9zZYMo79Dqn-EK8S0j-M9sNJeFEGQg_XgP6+fsszDmq5oDMQ@mail.gmail.com> <CANr5HFXkxQuiy+n1jDkd=jP92Wz=E0_BrGbo40A0xxjpbAw2dQ@mail.gmail.com> <CAO9zZYOuSfkkGbqFWeeJ-gu1k0mZLFfnjrgkiweL+EN9aGGoiw@mail.gmail.com> <alpine.DEB.2.00.1309100013320.12199@ps20323.dreamhostps.com> <CADnb78iS2LsMporp8qKxFmmBy-rHH7q++_-osP94oaWAtjzdcw@mail.gmail.com> <alpine.DEB.2.00.1309111821360.12210@ps20323.dreamhostps.com> <CADnb78iHZEKdX8F_76vezghkXNiXcq64Edmr2-ofHKhZ17hJcQ@mail.gmail.com> Message-ID: <5231E31C.5090309@mit.edu> On 9/12/13 5:24 AM, Anne van Kesteren wrote: > On Wed, Sep 11, 2013 at 7:22 PM, Ian Hickson <ian at hixie.ch> wrote: >> Well presumably we wouldn't want to only do it for <a>, since then links >> would work but SVG wouldn't (the exact opposite of the situation in Chrome >> now, for what it's worth). > > Yeah, we should have to do it for everything we classify as > "hyperlink". <a>, <svg:a>, <area>, and <link> I suppose. Why only "hyperlinks", if you're doing this? Last I checked, WebKit doesn't do it for hyperlinks, but does do it ad-hoc for CSS url() stuff and a few other things, depending on how it's used. -Boris From annevk at annevk.nl Thu Sep 12 08:55:04 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Thu, 12 Sep 2013 16:55:04 +0100 Subject: [whatwg] URL resolution of fragment urls in html5 webapps In-Reply-To: <5231E31C.5090309@mit.edu> References: <CAO9zZYMo79Dqn-EK8S0j-M9sNJeFEGQg_XgP6+fsszDmq5oDMQ@mail.gmail.com> <CANr5HFXkxQuiy+n1jDkd=jP92Wz=E0_BrGbo40A0xxjpbAw2dQ@mail.gmail.com> <CAO9zZYOuSfkkGbqFWeeJ-gu1k0mZLFfnjrgkiweL+EN9aGGoiw@mail.gmail.com> <alpine.DEB.2.00.1309100013320.12199@ps20323.dreamhostps.com> <CADnb78iS2LsMporp8qKxFmmBy-rHH7q++_-osP94oaWAtjzdcw@mail.gmail.com> <alpine.DEB.2.00.1309111821360.12210@ps20323.dreamhostps.com> <CADnb78iHZEKdX8F_76vezghkXNiXcq64Edmr2-ofHKhZ17hJcQ@mail.gmail.com> <5231E31C.5090309@mit.edu> Message-ID: <CADnb78jN9qbEdTgch_XgVjSGQ-FLFsmVVbvgFe8p27+NbU-5eQ@mail.gmail.com> On Thu, Sep 12, 2013 at 4:51 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote: > On 9/12/13 5:24 AM, Anne van Kesteren wrote: >> On Wed, Sep 11, 2013 at 7:22 PM, Ian Hickson <ian at hixie.ch> wrote: >>> Well presumably we wouldn't want to only do it for <a>, since then links >>> would work but SVG wouldn't (the exact opposite of the situation in >>> Chrome now, for what it's worth). >> >> Yeah, we should have to do it for everything we classify as >> "hyperlink". <a>, <svg:a>, <area>, and <link> I suppose. > > Why only "hyperlinks", if you're doing this? I thought it would be incompatible to do it for <form> and maybe <iframe> and others. > Last I checked, WebKit doesn't do it for hyperlinks, but does do it ad-hoc > for CSS url() stuff and a few other things, depending on how it's used. Is this for SVG thingies referenced from CSS? -- http://annevankesteren.nl/ From bzbarsky at MIT.EDU Thu Sep 12 09:28:08 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Thu, 12 Sep 2013 12:28:08 -0400 Subject: [whatwg] URL resolution of fragment urls in html5 webapps In-Reply-To: <CADnb78jN9qbEdTgch_XgVjSGQ-FLFsmVVbvgFe8p27+NbU-5eQ@mail.gmail.com> References: <CAO9zZYMo79Dqn-EK8S0j-M9sNJeFEGQg_XgP6+fsszDmq5oDMQ@mail.gmail.com> <CANr5HFXkxQuiy+n1jDkd=jP92Wz=E0_BrGbo40A0xxjpbAw2dQ@mail.gmail.com> <CAO9zZYOuSfkkGbqFWeeJ-gu1k0mZLFfnjrgkiweL+EN9aGGoiw@mail.gmail.com> <alpine.DEB.2.00.1309100013320.12199@ps20323.dreamhostps.com> <CADnb78iS2LsMporp8qKxFmmBy-rHH7q++_-osP94oaWAtjzdcw@mail.gmail.com> <alpine.DEB.2.00.1309111821360.12210@ps20323.dreamhostps.com> <CADnb78iHZEKdX8F_76vezghkXNiXcq64Edmr2-ofHKhZ17hJcQ@mail.gmail.com> <5231E31C.5090309@mit.edu> <CADnb78jN9qbEdTgch_XgVjSGQ-FLFsmVVbvgFe8p27+NbU-5eQ@mail.gmail.com> Message-ID: <5231EB98.9010803@mit.edu> On 9/12/13 11:55 AM, Anne van Kesteren wrote: >> Last I checked, WebKit doesn't do it for hyperlinks, but does do it ad-hoc >> for CSS url() stuff and a few other things, depending on how it's used. > > Is this for SVG thingies referenced from CSS? Or from SVG presentation attributes. Fill, filters, masks, etc, etc, etc. But again, it's not clear that anything needs to be done here. If something _does_ need to be done, then it needs to be done at a low level (e.g. url() needs to store the original string, not just the resolved url as it does now per CSS specs). -Boris From dmazzoni at google.com Thu Sep 12 09:32:00 2013 From: dmazzoni at google.com (Dominic Mazzoni) Date: Thu, 12 Sep 2013 09:32:00 -0700 Subject: [whatwg] Outline style to use for drawSystemFocusRing In-Reply-To: <alpine.DEB.2.00.1309120051240.12199@ps20323.dreamhostps.com> References: <CAFz-FYxS-sLLOMA2=5bj-aJ1bmsBq8w_4Rminw_JLCMnYaMfPw@mail.gmail.com> <alpine.DEB.2.00.1307242308540.27623@ps20323.dreamhostps.com> <CAGN7qDCdCR1F-D9PtEKUcHkh5KdwKhum4vEAyUQ0VkLeeC+PCA@mail.gmail.com> <alpine.DEB.2.00.1307292147040.27623@ps20323.dreamhostps.com> <CAGN7qDAaq8XnX1z_BbpLVhgE5m4j--b720ZuHSEzq_iN1es0=Q@mail.gmail.com> <alpine.DEB.2.00.1307300020510.27623@ps20323.dreamhostps.com> <CAGN7qDAjRPOQ25gQT+BY+sp8Y503_9KxTa1j2aZSGYU-9BmBVA@mail.gmail.com> <CAFz-FYzzPFU3g+fM+QGbEDAJ-3DSU2qGHY9R+heZRbAWVAN2rw@mail.gmail.com> <CAGN7qDDu3PNxK9PTVr09sqUc0FrOnXgRaQDwLXQ13BhH_=85Bw@mail.gmail.com> <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> <alpine.DEB.2.00.1309120051240.12199@ps20323.dreamhostps.com> Message-ID: <CAFz-FYwi6tQ7WcODc3MBC=6pM_=G5ZONe=nVSHLs5EGTiUjE=w@mail.gmail.com> On Wed, Sep 11, 2013 at 5:54 PM, Ian Hickson <ian at hixie.ch> wrote: > On Tue, 10 Sep 2013, Dominic Mazzoni wrote: > > > > We've finished implementing drawSystemFocusRing and drawCustomFocusRing > > in Chrome. Try it in Chrome 31 or higher (either canary or dev channel > > should work today). You'll need to go to chrome://flags and enable > > *experimental canvas features*, then restart the browser. > > > > Here's a demo I built that uses drawSystemFocusRing: > > http://dmazzoni-google.github.io/canvas-focus-ring-demo/ > > Looks good. Was your conclusion that the spec was ok as is, or did you > deviate from the spec in some way that needs a spec change > I think drawSystemFocusRing is good to go. If you want, you can update the spec to reflect that an implementation is available (behind a flag). Only one minor issue for clarification: if the current path is a line or unclosed polygon, should it be closed (or otherwise outlined) when drawing the focus ring? Currently we're not doing so in Chrome, but it might help to clarify. For example, if the path is a line, what's drawn is just an additional stroke on that line, not a "ring". I'm not as sure about drawCustomFocusRing. The spec says "If the user has requested the use of particular focus rings", but I'm not aware of any platform API we could use to query that. To the best of my knowledge, assistive technology that draws its own focus rings, like ZoomText, normally draws an additional focus ring with extra padding, rather than replacing the system one. (Example: http://www.aisquared.com/zoomtext/tour/enhancements#focus_enhancements) So, I'm not sure how I'd implement that part of the spec. Chrome definitely has no plans to give users an additional preference for focus rings as a browser setting. So, what we implemented in Chrome for drawCustomFocusRing is basically just a function that notifies assistive technology of the bounding rect of the focused region within the canvas. It's still useful, but if that's all it does, then drawCustomFocusRing is a poor name. Perhaps it should be called something like notifyFocusLocation or something like that. - Dominic From annevk at annevk.nl Thu Sep 12 09:51:14 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Thu, 12 Sep 2013 17:51:14 +0100 Subject: [whatwg] URL resolution of fragment urls in html5 webapps In-Reply-To: <5231EB98.9010803@mit.edu> References: <CAO9zZYMo79Dqn-EK8S0j-M9sNJeFEGQg_XgP6+fsszDmq5oDMQ@mail.gmail.com> <CANr5HFXkxQuiy+n1jDkd=jP92Wz=E0_BrGbo40A0xxjpbAw2dQ@mail.gmail.com> <CAO9zZYOuSfkkGbqFWeeJ-gu1k0mZLFfnjrgkiweL+EN9aGGoiw@mail.gmail.com> <alpine.DEB.2.00.1309100013320.12199@ps20323.dreamhostps.com> <CADnb78iS2LsMporp8qKxFmmBy-rHH7q++_-osP94oaWAtjzdcw@mail.gmail.com> <alpine.DEB.2.00.1309111821360.12210@ps20323.dreamhostps.com> <CADnb78iHZEKdX8F_76vezghkXNiXcq64Edmr2-ofHKhZ17hJcQ@mail.gmail.com> <5231E31C.5090309@mit.edu> <CADnb78jN9qbEdTgch_XgVjSGQ-FLFsmVVbvgFe8p27+NbU-5eQ@mail.gmail.com> <5231EB98.9010803@mit.edu> Message-ID: <CADnb78i0VwYzN4YWPYVoMpXZgYgoiSfw0-dBGNGeBbNReZM5=Q@mail.gmail.com> On Thu, Sep 12, 2013 at 5:28 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote: > Or from SVG presentation attributes. Fill, filters, masks, etc, etc, etc. > > But again, it's not clear that anything needs to be done here. If something > _does_ need to be done, then it needs to be done at a low level (e.g. url() > needs to store the original string, not just the resolved url as it does now > per CSS specs). Currently parseURL(input, base) returns either URL or failure. We could make it return URL, URLFragment, or failure too... Anyway, yeah, things are possible, but it's unclear whether everyone is interested in moving all these pieces. -- http://annevankesteren.nl/ From ian at hixie.ch Thu Sep 12 10:42:50 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 12 Sep 2013 17:42:50 +0000 (UTC) Subject: [whatwg] High-density canvases In-Reply-To: <CAOp6jLaxkdDE5qKaZmUxHs5Jic8h3yCnE+j7dCUgAHQWLQBiEg@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> <CAGN7qDCC=8EZUpEmN=10tcWGU=8TPQ7rej+sOGhbPaWqqAjWRA@mail.gmail.com> <CAOp6jLZFD_HVKgEfEUB0myCdvz60i_=1NASVQ-YKyzcHxkDxVw@mail.gmail.com> <alpine.DEB.2.00.1309111823370.12210@ps20323.dreamhostps.com> <CAOp6jLaxkdDE5qKaZmUxHs5Jic8h3yCnE+j7dCUgAHQWLQBiEg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309121742300.12210@ps20323.dreamhostps.com> On Thu, 12 Sep 2013, Robert O'Callahan wrote: > On Wed, Sep 11, 2013 at 11:24 AM, Ian Hickson <ian at hixie.ch> wrote: > > On Wed, 11 Sep 2013, Robert O'Callahan wrote: > > > Pinch-zoom is hard because we don't want to trigger reflows or other > > > expensive behavior on pinch-zoom. I'd leave pinch-zoom out of it for > > > now. > > > > Unless I'm missing something fundamental, changing the pixel density > > doesn't cause a layout, it's changing the width that causes a layout. > > Changing pixel density does cause a layout in Gecko. For example we > round CSS border widths to a whole number of device pixels. (This > ensures that when page zoom is applied, all borders with the same > specified width are rendered with the same visual width.) On some > platforms (Windows), changing pixel density affects text hinting which > affects text layout. So how do you do pinch-zoom under the hood on mobile devices? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Thu Sep 12 11:30:23 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 12 Sep 2013 18:30:23 +0000 (UTC) Subject: [whatwg] web messaging - postMessage In-Reply-To: <CAKRyGxt=-yegxR2G05XyT-sYFdudGOYp0EKysD8cURgYXr5ZEw@mail.gmail.com> References: <CAKRyGxsef-O-dtx1FbK_AiqngHr4Ob5d7sezYyxmswsog3VxZA@mail.gmail.com> <CAKRyGxvogWmMXxmChcZJ9Hi57k6bG+SituDs7pNRfTzdLao3DQ@mail.gmail.com> <9768D477C67135458BF978A45BCF9B3853BB8A58@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> <CAKRyGxuhAXadQeNvZQRdriW-yKmXSHDykrAf_A2Xy0w2gJ6m-w@mail.gmail.com> <CABirCh-397NkFxc8vO-bjaETyz72W7oy7jC+q5BM2+_O86ef6w@mail.gmail.com> <CAKRyGxsJP0bohFJ2SWAWr+H3AWsGYmUOcRZsuN3_uOfVJ1Jmgg@mail.gmail.com> <CABirCh-Ar58nYA_KGWOGjiahj9cq1fjTsmnPwjSRnE9EaWWCiA@mail.gmail.com> <alpine.DEB.2.00.1308052102150.9685@ps20323.dreamhostps.com> <CAKRyGxt=-yegxR2G05XyT-sYFdudGOYp0EKysD8cURgYXr5ZEw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309121818310.12199@ps20323.dreamhostps.com> On Mon, 5 Aug 2013, Jack (Zhan, Hua Ping) wrote: > > The "origin" in this context means the msg destination. The term "origin" in Web standards means a security token, essentially: http://tools.ietf.org/html/rfc6454 In the case of window.postMessage(), there's two places that an origin is used. The first is in the method call: destinationWindow.postMessage(message, targetOrigin); Here, targetOrigin is the origin that the destinationWindow object's active Document is required to have for the message to be delivered. We have this feature so that if the target page gets navigated away unexpectedly, you don't end up sending secrets to evil pages. The second is in the received MessageEvent object: // window is the destinationWindow of the script above // but here we're on the receiving end window.onmessage = function (event) { // event.data is the message from the call above // event.origin is the origin of the Window that sent the message // event.source is the Window that sent the message } Note that event.origin is _not_ targetOrigin. > Think it over, it seems to be "polling", but in your design, seems there > is no polling. in fact, there is. In your design, the receiver has to > check "origin". It has to check that it is receiving messages from a trusted source, right. > This means the receivers have to check the destination of the message. No, they're checking the source of the message. > > If you need to communicate between two otherwise unrelated tabs, there > > are basically two solutions: a shared worker, or a broadcast > > mechanism. The latter isn't currently specced, but discussion on how > > to do it is here: > > > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=22628 > > > > You can also currently fake this using the 'onstorage' event. > > Yes. I know these two solutions since someone told me before. but shared > worker is much more complicated than needed, isn't it? broadcast will > lose privacy, won't it? How would broadcast lose privacy? > >> My better proposal ..... > > This is basically a broadcast mechanism, right. > Yes. you are right, but message dispatch is done by the user agent, only > the intended receiver will receive the msg, so no communication > information would be leaked. And when broadcast is really needed, just > use wildcard for destination. As far as I can tell, what you are describing is consistent with the proposal in the bug above. > > One things that would be useful in making progress on this would be > > more use cases, in particular use cases where it's important to be > > able to respond after a broadcast. > > > > There's basically only one use case in the bug above, namely informing > > other windows of a state change (e.g. user logged in). This can > > currently be done using "onstorage" and that could arguably in fact be > > a sufficient solution (since for a "change" notification, there's no > > need to respond, and it's typically stored state that has changed). > > You are thinking in such a way. I really do not understand. There's an infinite number of features we could add, but we could not implement them all -- there's limited resources to implement stuff, and the more we implement, the more buggy stuff is since the resources get spread thinner and thinner. We have therefore to prioritise and only implement the most important things. To determine if something is important, we look at how people want to use it, and what problems they are trying to solve (use cases). Currently for this feature we lack many use cases. > I think this interface is really nice. Compare the original design and > this design, it is easy to see the difference. > >>>o.contentWindow.postMessage('Hello world', 'http://b.example.org/'); > window.postMessage(msgdata, targetDomain optional,targetWindowIDs optional); > > window is the general js object. the destination can be specified by > domain and/or window/tab ID, both of them can be omitted which means a > broadcast. window IDs aren't a good thing to use for naming windows, since they are trivially spoofed. > the major difference is the "o.contentWindow", this is really weird. > Once you specify the target receiver, you do not have to care its > window handle. The user agent should take care of it. There's an important difference between the Window object of the target, and the origin of the Document currently loaded in the target. It's easy for an attacker to renavigate an iframe or window to their site, so it's important to say the origin of where you're sending the data, so that an evil site can't intercept it. > For security reason, the interface at the receiver side, will be bound > to a specific msg name "msgpost". This msg name is added by the user > agent. The msg name is some kind of identifying the msg channel, so the > receiver will have an idea where this message comes from. Of course, msg > source will also be available for the receiver to check. But as a > receiver, checking msg destination is not needed since this should be > done by the user agent. I don't understand how this improves security. What's the attack model you have in mind that this mitigates? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Thu Sep 12 11:34:39 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 12 Sep 2013 18:34:39 +0000 (UTC) Subject: [whatwg] Request for updating the srcset-specification? In-Reply-To: <436355E7-26B7-4315-8BA0-8248AE76D58E@anselm-hannemann.com> References: <DBFA329F-462B-46E3-9BF5-533A0835C88C@anselm-hannemann.com> <m24nati9ew.fsf@eoconnor.apple.com> <436355E7-26B7-4315-8BA0-8248AE76D58E@anselm-hannemann.com> Message-ID: <alpine.DEB.2.00.1309121833060.12199@ps20323.dreamhostps.com> On Tue, 13 Aug 2013, Anselm Hannemann wrote: > > what do you think of updating [srcset] regarding the implementation(s)? The spec generally speaking intends to always be a little ahead of where the browsers are, so that the browsers can have something to implement next. So it's ok for the spec to be an aspirational superset. (What's not ok would be for the spec to be incompatible with what the browsers do -- neither a subset or a superset, but a different set.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From barraclough at apple.com Thu Sep 12 11:36:53 2013 From: barraclough at apple.com (Gavin Barraclough) Date: Thu, 12 Sep 2013 11:36:53 -0700 Subject: [whatwg] [[GetOwnProperty]] for named properties of the Window object In-Reply-To: <523113EA.4030908@mit.edu> References: <52600B08-E2BB-4AA3-877E-797E1CF687BC@apple.com> <52293AC6.5020108@mit.edu> <C9BAE4B7-C54B-451A-872D-40D6CEAED23C@apple.com> <523113EA.4030908@mit.edu> Message-ID: <DED137DB-3BD8-4298-A427-FBF2BC33EEE5@apple.com> On Sep 11, 2013, at 6:07 PM, Boris Zbarsky <bzbarsky at MIT.EDU> wrote: > On 9/11/13 6:05 PM, Gavin Barraclough wrote: >> Interesting, I had just assumed this was okay ? is it not spec-compliant for Window.prototype to be a named properties object? > > No, it's not. The spec defines exactly what the prototype chain looks like here. See the definitions of [[Prototype]] athttp://dev.w3.org/2006/webapi/WebIDL/#named-properties-object and http://dev.w3.org/2006/webapi/WebIDL/#interface-prototype-object (item 1 at the latter). Ah, got it, thanks. I?d only spotted the partial description in http://dev.w3.org/2006/webapi/WebIDL/#Global > So the chain by default is window -> Window.prototype -> named properties object -> EventTarget.prototype -> Object.prototype. > > This allows specification of the named properties object without having to worry about weird interactions with name collisions on Window.prototype, whether with properties it has by default or properties someone wants to add to it. Note that the named properties object does not allow [[DefineOwnProperty]], so if it were Window.prototype then you wouldn't be able to add any properties to Window.prototype! > >> I believe these properties are implemented as shadowable in the same way as [Replaceable] properties > > [Replaceable] properties need the magic they have because they're accessor properties, which normally can't be shadowed via assignment. > > But named properties on the named properties object are value properties, so simply making them writable allows them to be shadowed. In fact, that's the only way to make them shadowable. Got it. >> (and then assume a modified behaviour of ES [Put] for properties with this attribute, to permit overwrite even if readonly). > > I don't think a special [Put] is needed if the properties aren't readonly. Hmmm, interesting. I was thinking that in the case that a shadowing property was put to the named property object itself, then deleted, this needed further description (as the old property reappears) ? but I guess that it just covered by the current spec [[GetOwnProperty]] implementation. Many thanks, Gavin From ian at hixie.ch Thu Sep 12 11:43:35 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 12 Sep 2013 18:43:35 +0000 (UTC) Subject: [whatwg] Why are we merging Document and HTMLDocument again? In-Reply-To: <0ED2DF0C-C0AC-496C-8B8B-37FF90D0B436@apple.com> References: <51361FA0.8070101@mit.edu> <CADnb78gB=pdOGZ4tY09V-oANt4+KB-WgoDaEuoR1ibjq+N861g@mail.gmail.com> <51362266.7010804@mit.edu> <CADnb78j_ELAmskAB41-K_DTVbNWuPYfn-fa-VC-n2f=OtA0mQg@mail.gmail.com> <51362671.1010302@mit.edu> <Pine.LNX.4.64.1303052029350.15713@ps20323.dreamhostps.com> <5136589D.4040800@mit.edu> <CADnb78hWVVU1qjKU=mK5AXwwNUmsKHeNfD7HmY1OD2Rj+EXmxw@mail.gmail.com> <alpine.DEB.2.00.1307121752451.15729@ps20323.dreamhostps.com> <51E04531.4070801@mit.edu> <0ED2DF0C-C0AC-496C-8B8B-37FF90D0B436@apple.com> Message-ID: <alpine.DEB.2.00.1309121836290.12199@ps20323.dreamhostps.com> On Tue, 13 Aug 2013, Ryosuke Niwa wrote: > On Jul 12, 2013, at 11:04 AM, Boris Zbarsky wrote: > > On 7/12/13 1:57 PM, Ian Hickson wrote: > > > On Thu, 14 Mar 2013, Anne van Kesteren wrote: > > > > On Tue, Mar 5, 2013 at 8:42 PM, Boris Zbarsky wrote: > > > > > On 3/5/13 3:30 PM, Ian Hickson wrote: > > > > > > On Tue, Mar 5, 2013 at 4:50 PM, Boris Zbarsky wrote: > > > > > > > > > > > > > > I don't want to merge the prototype objects for Document and > > > > > > > HTMLDocument, because I don't want to stick a named getter > > > > > > > on every document. > > > > > > > > > > > > I'd be fine with having a Document descendant that is used for > > > > > > Documents that have global scopes / browsing contexts / the > > > > > > works, and one that is used for Documents that don't (e.g. > > > > > > createDocument(), XHR); would that address this issue? > > > > > > > > > > It's one way to address it, yes... > > > > > > > > Just to be clear, this works for Mozilla, as long as it's clearly > > > > defined and other vendors are on board. Arv? > > > > > > Having not heard any interest from anyone else, I haven't done > > > anything. If there's movement here, let me know. > > > > That's because other UAs are just silently ignoring the spec as > > currently written, for the most part... > > I concur with Boris's concerns. So you also support having a Document descendant that is used for Documents that have global scopes / browsing contexts / the works, and one that is used for Documents that don't (e.g. createDocument(), XHR), where the former has the named getter and the latter doesn't? > Can we at least avoid having OverrideBuiltins on Document? Do you mean in general? Wouldn't that be non-backwards compatible? > Or can we keep HTMLDocument that just defines name getter? When would it be used? Are you agreeing with the proposal above? Or do you have something different in mind? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From bzbarsky at MIT.EDU Thu Sep 12 11:43:42 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Thu, 12 Sep 2013 14:43:42 -0400 Subject: [whatwg] [[GetOwnProperty]] for named properties of the Window object In-Reply-To: <DED137DB-3BD8-4298-A427-FBF2BC33EEE5@apple.com> References: <52600B08-E2BB-4AA3-877E-797E1CF687BC@apple.com> <52293AC6.5020108@mit.edu> <C9BAE4B7-C54B-451A-872D-40D6CEAED23C@apple.com> <523113EA.4030908@mit.edu> <DED137DB-3BD8-4298-A427-FBF2BC33EEE5@apple.com> Message-ID: <52320B5E.3090204@mit.edu> On 9/12/13 2:36 PM, Gavin Barraclough wrote: > Hmmm, interesting. I was thinking that in the case that a shadowing > property was put to the named property object itself Can't be done. Looking at the ES5 [[Put]], ownDesc is a data descriptor here, so we land in step 3b, which calls [[DefineOwnProperty]], which is defined at http://dev.w3.org/2006/webapi/WebIDL/#named-properties-object-defineownproperty and throws if "Throw" and silently does nothing otherwise. ES6 is similar. > then deleted Also can't be done. See http://dev.w3.org/2006/webapi/WebIDL/#named-properties-object-delete > Many thanks, No problem! -Boris From ian at hixie.ch Thu Sep 12 12:05:26 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 12 Sep 2013 19:05:26 +0000 (UTC) Subject: [whatwg] NoDatabase databases In-Reply-To: <5211A249.2020003@yahoo.com> References: <5181F231.2080505@yahoo.com> <alpine.DEB.2.00.1308052328281.9685@ps20323.dreamhostps.com> <5211A249.2020003@yahoo.com> Message-ID: <alpine.DEB.2.00.1309121845390.12199@ps20323.dreamhostps.com> On Mon, 19 Aug 2013, Brett Zamir wrote: > > As far as a user-facing application, for the first case, I have some very > preliminary (but usable) proof-of-concept work for a Firefox add-on (along > with not-yet-reusable Node.js and PHP implementations) at > https://github.com/brettz9/httpquery . Generally speaking, browser add-ons aren't use cases for Web features, they're use cases for browser features. I've ignored anything in your e-mail that wasn't a solution to a specific user problem (i.e. that wasn't a use case). That leaves: > The use case here is the same as why someone would want to use the find > bar Users want to use the find-in-page feature because they have loaded a page that contains some text, but they don't know where in the text it is, so they search for it. Doesn't the find bar already solve that problem pretty completely? > use Firebug Firebug is a feature for debugging sites during development. While certainly that can be made better, it doesn't require standard features to be implemented -- it's a browser feature, needing only hooks into the browser to provide all its features. > apply user scripts to a page A user would do this to change a page to do what the user wanted rather than what the author wanted. It seems like HTML already provides plenty of ways for a browser to implement such features. > use a Microdata-aware search engine A user would do this to find data on the Web. There's certainly plenty more work to be done in this area, but it's not clear how your proposal helps improve this. Can you elaborate on how exactly your proposal helps search engines help users find materials better? Fundamentally, I don't think you've described the problem you're trying to solve succintly enough for any proposal to be evaluated. I recommend putting aside the solution you have, and first trying to completely describe the problem. This should be something you can do in a few short sentences. > > I think that in practice we're going to reach practical limits in user > > agents rendering tables long before we're going to reach practical > > limits of document size. A multimegabyte table is going to cause > > layout problems before it takes appreciable time to download. > > How is that possible? Try it. Downloading a megabyte of succint HTML takes a few seconds. Try rendering it in a browser. Try manipulating it (e.g. changing font sizes): http://damowmow.com/playground/demos/tables/004.html Even today, the page loads in a few seconds, but hovering around that page drops the frame rate of the page to single digits. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From rniwa at apple.com Thu Sep 12 13:42:40 2013 From: rniwa at apple.com (Ryosuke Niwa) Date: Thu, 12 Sep 2013 13:42:40 -0700 Subject: [whatwg] Why are we merging Document and HTMLDocument again? In-Reply-To: <alpine.DEB.2.00.1309121836290.12199@ps20323.dreamhostps.com> References: <51361FA0.8070101@mit.edu> <CADnb78gB=pdOGZ4tY09V-oANt4+KB-WgoDaEuoR1ibjq+N861g@mail.gmail.com> <51362266.7010804@mit.edu> <CADnb78j_ELAmskAB41-K_DTVbNWuPYfn-fa-VC-n2f=OtA0mQg@mail.gmail.com> <51362671.1010302@mit.edu> <Pine.LNX.4.64.1303052029350.15713@ps20323.dreamhostps.com> <5136589D.4040800@mit.edu> <CADnb78hWVVU1qjKU=mK5AXwwNUmsKHeNfD7HmY1OD2Rj+EXmxw@mail.gmail.com> <alpine.DEB.2.00.1307121752451.15729@ps20323.dreamhostps.com> <51E04531.4070801@mit.edu> <0ED2DF0C-C0AC-496C-8B8B-37FF90D0B436@apple.com> <alpine.DEB.2.00.1309121836290.12199@ps20323.dreamhostps.com> Message-ID: <1D191C36-CE39-4A1F-AF45-A75673C35EA1@apple.com> On Sep 12, 2013, at 11:43 AM, Ian Hickson <ian at hixie.ch> wrote: > On Tue, 13 Aug 2013, Ryosuke Niwa wrote: >> On Jul 12, 2013, at 11:04 AM, Boris Zbarsky wrote: >>> On 7/12/13 1:57 PM, Ian Hickson wrote: >>>> On Thu, 14 Mar 2013, Anne van Kesteren wrote: >>>>> On Tue, Mar 5, 2013 at 8:42 PM, Boris Zbarsky wrote: >>>>>> On 3/5/13 3:30 PM, Ian Hickson wrote: >>>>>>> On Tue, Mar 5, 2013 at 4:50 PM, Boris Zbarsky wrote: >>>>>>>> >>>>>>>> I don't want to merge the prototype objects for Document and >>>>>>>> HTMLDocument, because I don't want to stick a named getter >>>>>>>> on every document. >>>>>>> >>>>>>> I'd be fine with having a Document descendant that is used for >>>>>>> Documents that have global scopes / browsing contexts / the >>>>>>> works, and one that is used for Documents that don't (e.g. >>>>>>> createDocument(), XHR); would that address this issue? >>>>>> >>>>>> It's one way to address it, yes... >>>>> >>>>> Just to be clear, this works for Mozilla, as long as it's clearly >>>>> defined and other vendors are on board. Arv? >>>> >>>> Having not heard any interest from anyone else, I haven't done >>>> anything. If there's movement here, let me know. >>> >>> That's because other UAs are just silently ignoring the spec as >>> currently written, for the most part... >> >> I concur with Boris's concerns. > > So you also support having a Document descendant that is used for > Documents that have global scopes / browsing contexts / the works, and one > that is used for Documents that don't (e.g. createDocument(), XHR), where > the former has the named getter and the latter doesn't? I think that's what I'm suggesting except that I'm suggesting to keep calling the former HTMLDocument. >> Can we at least avoid having OverrideBuiltins on Document? > > Do you mean in general? Wouldn't that be non-backwards compatible? I'm using the old terminology here. I meant on Document, not HTMLDocument as we do keep OverrideBuiltins for the latter. >> Or can we keep HTMLDocument that just defines name getter? > > When would it be used? Are you agreeing with the proposal above? Or do you > have something different in mind? As far as I checked, SVGDocument and alike don't have named getter either so I'd rather not introduce it any non-HTML document. - R. Niwa From barraclough at apple.com Thu Sep 12 13:50:06 2013 From: barraclough at apple.com (Gavin Barraclough) Date: Thu, 12 Sep 2013 13:50:06 -0700 Subject: [whatwg] [[GetOwnProperty]] for named properties of the Window object In-Reply-To: <52320B5E.3090204@mit.edu> References: <52600B08-E2BB-4AA3-877E-797E1CF687BC@apple.com> <52293AC6.5020108@mit.edu> <C9BAE4B7-C54B-451A-872D-40D6CEAED23C@apple.com> <523113EA.4030908@mit.edu> <DED137DB-3BD8-4298-A427-FBF2BC33EEE5@apple.com> <52320B5E.3090204@mit.edu> Message-ID: <0B70289A-3DA0-40FB-8E8B-3B1E9EAC736B@apple.com> On Sep 12, 2013, at 11:43 AM, Boris Zbarsky <bzbarsky at MIT.EDU> wrote: > On 9/12/13 2:36 PM, Gavin Barraclough wrote: >> Hmmm, interesting. I was thinking that in the case that a shadowing >> property was put to the named property object itself > > Can't be done. Looking at the ES5 [[Put]], ownDesc is a data descriptor here, so we land in step 3b, which calls [[DefineOwnProperty]], which is defined at http://dev.w3.org/2006/webapi/WebIDL/#named-properties-object-defineownpropertyand throws if "Throw" and silently does nothing otherwise. ES6 is similar. Ah, good point. Firefox, Safari, Chrome all currently all allow this, but seems reasonable to prohibit. cheers, G. >> then deleted > > Also can't be done. See http://dev.w3.org/2006/webapi/WebIDL/#named-properties-object-delete > >> Many thanks, > > No problem! > > -Boris From ian at hixie.ch Thu Sep 12 14:00:57 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 12 Sep 2013 21:00:57 +0000 (UTC) Subject: [whatwg] Why are we merging Document and HTMLDocument again? In-Reply-To: <1D191C36-CE39-4A1F-AF45-A75673C35EA1@apple.com> References: <51361FA0.8070101@mit.edu> <CADnb78gB=pdOGZ4tY09V-oANt4+KB-WgoDaEuoR1ibjq+N861g@mail.gmail.com> <51362266.7010804@mit.edu> <CADnb78j_ELAmskAB41-K_DTVbNWuPYfn-fa-VC-n2f=OtA0mQg@mail.gmail.com> <51362671.1010302@mit.edu> <Pine.LNX.4.64.1303052029350.15713@ps20323.dreamhostps.com> <5136589D.4040800@mit.edu> <CADnb78hWVVU1qjKU=mK5AXwwNUmsKHeNfD7HmY1OD2Rj+EXmxw@mail.gmail.com> <alpine.DEB.2.00.1307121752451.15729@ps20323.dreamhostps.com> <51E04531.4070801@mit.edu> <0ED2DF0C-C0AC-496C-8B8B-37FF90D0B436@apple.com> <alpine.DEB.2.00.1309121836290.12199@ps20323.dreamhostps.com> <1D191C36-CE39-4A1F-AF45-A75673C35EA1@apple.com> Message-ID: <alpine.DEB.2.00.1309122055280.12210@ps20323.dreamhostps.com> On Thu, 12 Sep 2013, Ryosuke Niwa wrote: > On Sep 12, 2013, at 11:43 AM, Ian Hickson <ian at hixie.ch> wrote: > > > > So you also support having a Document descendant that is used for > > Documents that have global scopes / browsing contexts / the works, and > > one that is used for Documents that don't (e.g. createDocument(), > > XHR), where the former has the named getter and the latter doesn't? > > I think that's what I'm suggesting except that I'm suggesting to keep > calling the former HTMLDocument. > > As far as I checked, SVGDocument and alike don't have named getter > either so I'd rather not introduce it any non-HTML document. What's an "HTML document" in this world? Something served using text/html? Something with a browsing context? Some combination thereof? SVGDocument is supposed to be merged into Document as well. The idea is to not have any descendants of Document. The reason is that you can have compound documents that need both the SVG and HTML (and MathML and FooML) methods. There's no such thing as "non-HTML documents" now. Documents can have SVG and HTML and mix it at will. I can see having a special descendant that does the name stuff, if we can determine exactly when it would apply. Note that what the DOM and HTML specs call "HTML Document" vs "XML Document" is not the same criteria as was being discussed here earlier (whether it has a browsing context). But I think it's unfortunate to be considering yet another mode switch. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From davidc at nag.co.uk Thu Sep 12 15:58:21 2013 From: davidc at nag.co.uk (David Carlisle) Date: Thu, 12 Sep 2013 23:58:21 +0100 Subject: [whatwg] URL resolution of fragment urls in html5 webapps In-Reply-To: <CADnb78iHZEKdX8F_76vezghkXNiXcq64Edmr2-ofHKhZ17hJcQ@mail.gmail.com> References: <CAO9zZYMo79Dqn-EK8S0j-M9sNJeFEGQg_XgP6+fsszDmq5oDMQ@mail.gmail.com> <CANr5HFXkxQuiy+n1jDkd=jP92Wz=E0_BrGbo40A0xxjpbAw2dQ@mail.gmail.com> <CAO9zZYOuSfkkGbqFWeeJ-gu1k0mZLFfnjrgkiweL+EN9aGGoiw@mail.gmail.com> <alpine.DEB.2.00.1309100013320.12199@ps20323.dreamhostps.com> <CADnb78iS2LsMporp8qKxFmmBy-rHH7q++_-osP94oaWAtjzdcw@mail.gmail.com> <alpine.DEB.2.00.1309111821360.12210@ps20323.dreamhostps.com> <CADnb78iHZEKdX8F_76vezghkXNiXcq64Edmr2-ofHKhZ17hJcQ@mail.gmail.com> Message-ID: <5232470D.5050107@nag.co.uk> On 12/09/2013 10:24, Anne van Kesteren wrote: > Yeah, we should have to do it for everything we classify as > "hyperlink". <a>, <svg:a>, <area>, and <link> I suppose. I'm not > sure what in MathML would need covering. more or less anything in MathML takes an href attribute (and then should act like <a href, whatever you decide that should do.) My reading of the RFCs that Ian referenced was always that #foo was a same-document reference irrespective of any explicit settings of the base URL, but whatever, links in MathML-in-HTML should just do whatever links in HTML do. David From cabanier at gmail.com Thu Sep 12 16:28:09 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Thu, 12 Sep 2013 16:28:09 -0700 Subject: [whatwg] Stroking algorithm in Canvas 2d In-Reply-To: <CAGN7qDDgfZmoZvj9JEwzM764LHWivn=nh_WyGfJOX7SdW31vvg@mail.gmail.com> References: <CAGN7qDA-iib4SULW-JDf4_vpsyuxpg1m8AkXq=qgDtY1OkXahA@mail.gmail.com> <alpine.DEB.2.00.1309091626010.12210@ps20323.dreamhostps.com> <CAGN7qDDgfZmoZvj9JEwzM764LHWivn=nh_WyGfJOX7SdW31vvg@mail.gmail.com> Message-ID: <CAGN7qDDfcvmrJciqPDhJ_YPT=n4caMRZTAQ_SgYwE1pjPx5iYA@mail.gmail.com> Maybe we can start by extracting dashing from the pseudo code. The process of dashing should break up every subpath in a bunch of new subpaths. This new collection of subpaths can then be stroked. Currently the spec says: 1 Let width be the aggregate length of all the lines of all the subpaths in path, in coordinate space units. 2 Let offset be the value of the styles lineDashOffset, in coordinate space units. 3 While offset is greater than width, decrement it by width. 4 While offset is less than width, increment it by width. For 1, dashing should be applied to each subpath. As the PDF reference manual says: When a path consisting of several subpaths is stroked, each subpath shall be treated independently?that is, the dash pattern shall be restarted and the dash phase shall be reapplied to it at the beginning of each subpath. 2 - 4 are not correct. From the PDF reference: Before beginning to stroke a path, the dash array shall be cycled through, adding up the lengths of dashes and gaps. When the accumulated length equals the value specified by the dash phase, stroking of the path shall begin, and the dash array shall be used cyclically from that point onward. So, this cycling should be done on the dash array and not the length of the path that it applies to. From bzbarsky at MIT.EDU Thu Sep 12 17:52:50 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Thu, 12 Sep 2013 20:52:50 -0400 Subject: [whatwg] [[GetOwnProperty]] for named properties of the Window object In-Reply-To: <0B70289A-3DA0-40FB-8E8B-3B1E9EAC736B@apple.com> References: <52600B08-E2BB-4AA3-877E-797E1CF687BC@apple.com> <52293AC6.5020108@mit.edu> <C9BAE4B7-C54B-451A-872D-40D6CEAED23C@apple.com> <523113EA.4030908@mit.edu> <DED137DB-3BD8-4298-A427-FBF2BC33EEE5@apple.com> <52320B5E.3090204@mit.edu> <0B70289A-3DA0-40FB-8E8B-3B1E9EAC736B@apple.com> Message-ID: <523261E2.30008@mit.edu> On 9/12/13 4:50 PM, Gavin Barraclough wrote: > Ah, good point. Firefox, Safari, Chrome all currently all allow this, > but seems reasonable to prohibit. For what it's worth, Firefox nightlies prohibit it, ever since https://bugzilla.mozilla.org/show_bug.cgi?id=895758 allowed us to actually do so. -Boris From rniwa at apple.com Thu Sep 12 18:52:38 2013 From: rniwa at apple.com (Ryosuke Niwa) Date: Thu, 12 Sep 2013 18:52:38 -0700 Subject: [whatwg] Why are we merging Document and HTMLDocument again? In-Reply-To: <alpine.DEB.2.00.1309122055280.12210@ps20323.dreamhostps.com> References: <51361FA0.8070101@mit.edu> <CADnb78gB=pdOGZ4tY09V-oANt4+KB-WgoDaEuoR1ibjq+N861g@mail.gmail.com> <51362266.7010804@mit.edu> <CADnb78j_ELAmskAB41-K_DTVbNWuPYfn-fa-VC-n2f=OtA0mQg@mail.gmail.com> <51362671.1010302@mit.edu> <Pine.LNX.4.64.1303052029350.15713@ps20323.dreamhostps.com> <5136589D.4040800@mit.edu> <CADnb78hWVVU1qjKU=mK5AXwwNUmsKHeNfD7HmY1OD2Rj+EXmxw@mail.gmail.com> <alpine.DEB.2.00.1307121752451.15729@ps20323.dreamhostps.com> <51E04531.4070801@mit.edu> <0ED2DF0C-C0AC-496C-8B8B-37FF90D0B436@apple.com> <alpine.DEB.2.00.1309121836290.12199@ps20323.dreamhostps.com> <1D191C36-CE39-4A1F-AF45-A75673C35EA1@apple.com> <alpine.DEB.2.00.1309122055280.12210@ps20323.dreamhostps.com> Message-ID: <3BD3DB4F-5409-4CC9-9310-2C7E90CBC37B@apple.com> On Sep 12, 2013, at 2:00 PM, Ian Hickson <ian at hixie.ch> wrote: > On Thu, 12 Sep 2013, Ryosuke Niwa wrote: >> On Sep 12, 2013, at 11:43 AM, Ian Hickson <ian at hixie.ch> wrote: >>> >>> So you also support having a Document descendant that is used for >>> Documents that have global scopes / browsing contexts / the works, and >>> one that is used for Documents that don't (e.g. createDocument(), >>> XHR), where the former has the named getter and the latter doesn't? >> >> I think that's what I'm suggesting except that I'm suggesting to keep >> calling the former HTMLDocument. >> >> As far as I checked, SVGDocument and alike don't have named getter >> either so I'd rather not introduce it any non-HTML document. > > What's an "HTML document" in this world? Something served using text/html? > Something with a browsing context? Some combination thereof? I'm not trying to invent anything new here. HTMLDocument as existed before the merge. > SVGDocument is supposed to be merged into Document as well. The idea is to > not have any descendants of Document. The reason is that you can have > compound documents that need both the SVG and HTML (and MathML and FooML) > methods. There's no such thing as "non-HTML documents" now. Documents can > have SVG and HTML and mix it at will. That's okay but there's no point in bringing in legacy features like named property in that new world. Named properties impos a significant runtime cost, and we'd like to get rid of them as much as possible. As such, I'm strongly opposed to supporting it in more places. - R. Niwa From ian at hixie.ch Thu Sep 12 21:15:05 2013 From: ian at hixie.ch (Ian Hickson) Date: Fri, 13 Sep 2013 04:15:05 +0000 (UTC) Subject: [whatwg] Why are we merging Document and HTMLDocument again? In-Reply-To: <3BD3DB4F-5409-4CC9-9310-2C7E90CBC37B@apple.com> References: <51361FA0.8070101@mit.edu> <CADnb78gB=pdOGZ4tY09V-oANt4+KB-WgoDaEuoR1ibjq+N861g@mail.gmail.com> <51362266.7010804@mit.edu> <CADnb78j_ELAmskAB41-K_DTVbNWuPYfn-fa-VC-n2f=OtA0mQg@mail.gmail.com> <51362671.1010302@mit.edu> <Pine.LNX.4.64.1303052029350.15713@ps20323.dreamhostps.com> <5136589D.4040800@mit.edu> <CADnb78hWVVU1qjKU=mK5AXwwNUmsKHeNfD7HmY1OD2Rj+EXmxw@mail.gmail.com> <alpine.DEB.2.00.1307121752451.15729@ps20323.dreamhostps.com> <51E04531.4070801@mit.edu> <0ED2DF0C-C0AC-496C-8B8B-37FF90D0B436@apple.com> <alpine.DEB.2.00.1309121836290.12199@ps20323.dreamhostps.com> <1D191C36-CE39-4A1F-AF45-A75673C35EA1@apple.com> <alpine.DEB.2.00.1309122055280.12210@ps20323.dreamhostps.com> <3BD3DB4F-5409-4CC9-9310-2C7E90CBC37B@apple.com> Message-ID: <alpine.DEB.2.00.1309130409200.12210@ps20323.dreamhostps.com> On Thu, 12 Sep 2013, Ryosuke Niwa wrote: > On Sep 12, 2013, at 2:00 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Thu, 12 Sep 2013, Ryosuke Niwa wrote: > >> On Sep 12, 2013, at 11:43 AM, Ian Hickson <ian at hixie.ch> wrote: > >>> > >>> So you also support having a Document descendant that is used for > >>> Documents that have global scopes / browsing contexts / the works, > >>> and one that is used for Documents that don't (e.g. > >>> createDocument(), XHR), where the former has the named getter and > >>> the latter doesn't? > >> > >> I think that's what I'm suggesting except that I'm suggesting to keep > >> calling the former HTMLDocument. > >> > >> As far as I checked, SVGDocument and alike don't have named getter > >> either so I'd rather not introduce it any non-HTML document. > > > > What's an "HTML document" in this world? Something served using > > text/html? Something with a browsing context? Some combination > > thereof? > > I'm not trying to invent anything new here. HTMLDocument as existed > before the merge. Ok, I guess I'm confused then, because earlier you said you agreed with the idea of removing this feature from non-browsing-context Documents, which is a different criteria. > > SVGDocument is supposed to be merged into Document as well. The idea > > is to not have any descendants of Document. The reason is that you can > > have compound documents that need both the SVG and HTML (and MathML > > and FooML) methods. There's no such thing as "non-HTML documents" now. > > Documents can have SVG and HTML and mix it at will. > > That's okay but there's no point in bringing in legacy features like > named property in that new world. What we did is bring SVG into the "old world", so that there's no distinction between these new kinds of documents and HTMLDocuments. So on the contrary, I don't see how else we could do it if we want it to be possible to have HTML and SVG in text/html. > Named properties impos a significant runtime cost, and we'd like to get > rid of them as much as possible. As such, I'm strongly opposed to > supporting it in more places. What are the places you see us as adding this in? Just XML documents? Those are so rare that it doesn't seem to me that it makes much difference one way or the other. (That's not saying I don't want to remove them there either. We could definitely say something like "the set of named properties is empty if the document is not marked as being an "HTML document" (in the DOM Core sense) "or if the document has no browsing context" -- but that seems orthogonal to the original issue of Document vs HTMLDocument vs SVGDocument.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jungkee.song at samsung.com Thu Sep 12 22:42:56 2013 From: jungkee.song at samsung.com (Jungkee Song) Date: Fri, 13 Sep 2013 14:42:56 +0900 Subject: [whatwg] [XHR] changes in abort() steps Message-ID: <03fd01ceb044$195dde90$4c199bb0$@samsung.com> Hi Anne, In the recent change in abort() steps [1], is it intended to NOT change the state to UNSENT for an ongoing (the send() flag set) request? It's observed that Chrome, Firefox, IE all set it to UNSENT. Also, a few test cases in W3C tests have assertions on it: request.send(); request.abort(); request.assert_true(client.readyState, 4); [1] https://github.com/whatwg/xhr/commit/9b57f112dba4d135986d956b41109607dd90827 3 -- Jungkee Song From jungkee.song at samsung.com Thu Sep 12 22:46:38 2013 From: jungkee.song at samsung.com (Jungkee Song) Date: Fri, 13 Sep 2013 14:46:38 +0900 Subject: [whatwg] [XHR] changes in abort() steps In-Reply-To: <03fd01ceb044$195dde90$4c199bb0$@samsung.com> References: <03fd01ceb044$195dde90$4c199bb0$@samsung.com> Message-ID: <03ff01ceb044$9db2f9a0$d918ece0$@samsung.com> Correction in the code snippet inline. > -----Original Message----- > From: whatwg-bounces at lists.whatwg.org [mailto:whatwg- > bounces at lists.whatwg.org] On Behalf Of Jungkee Song > Sent: Friday, September 13, 2013 2:43 PM > To: Anne van Kesteren; whatwg at lists.whatwg.org > Subject: [whatwg] [XHR] changes in abort() steps > > Hi Anne, > > In the recent change in abort() steps [1], is it intended to NOT change > the state to UNSENT for an ongoing (the send() flag set) request? It's > observed that Chrome, Firefox, IE all set it to UNSENT. Also, a few test > cases in W3C tests have assertions on it: > > request.send(); > request.abort(); > request.assert_true(client.readyState, 0); // UNSENT > > > [1] > https://github.com/whatwg/xhr/commit/9b57f112dba4d135986d956b41109607dd908 > 27 > 3 > > > -- > Jungkee Song From simonp at opera.com Fri Sep 13 00:42:26 2013 From: simonp at opera.com (Simon Pieters) Date: Fri, 13 Sep 2013 09:42:26 +0200 Subject: [whatwg] Why are we merging Document and HTMLDocument again? In-Reply-To: <alpine.DEB.2.00.1309130409200.12210@ps20323.dreamhostps.com> References: <51361FA0.8070101@mit.edu> <CADnb78gB=pdOGZ4tY09V-oANt4+KB-WgoDaEuoR1ibjq+N861g@mail.gmail.com> <51362266.7010804@mit.edu> <CADnb78j_ELAmskAB41-K_DTVbNWuPYfn-fa-VC-n2f=OtA0mQg@mail.gmail.com> <51362671.1010302@mit.edu> <Pine.LNX.4.64.1303052029350.15713@ps20323.dreamhostps.com> <5136589D.4040800@mit.edu> <CADnb78hWVVU1qjKU=mK5AXwwNUmsKHeNfD7HmY1OD2Rj+EXmxw@mail.gmail.com> <alpine.DEB.2.00.1307121752451.15729@ps20323.dreamhostps.com> <51E04531.4070801@mit.edu> <0ED2DF0C-C0AC-496C-8B8B-37FF90D0B436@apple.com> <alpine.DEB.2.00.1309121836290.12199@ps20323.dreamhostps.com> <1D191C36-CE39-4A1F-AF45-A75673C35EA1@apple.com> <alpine.DEB.2.00.1309122055280.12210@ps20323.dreamhostps.com> <3BD3DB4F-5409-4CC9-9310-2C7E90CBC37B@apple.com> <alpine.DEB.2.00.1309130409200.12210@ps20323.dreamhostps.com> Message-ID: <op.w3cac0spidj3kv@simons-macbook-pro.local> On Fri, 13 Sep 2013 06:15:05 +0200, Ian Hickson <ian at hixie.ch> wrote: > What are the places you see us as adding this in? So the concepts discussed here are probably a bit confusing if one doesn't know what the spec terms mean. Let's list concrete cases and see what we want to do with each one. In a browsing context: * text/html document (uses interface "Document" and is an "HTML document") * XML document (uses interface "Document" and is an "XML document") Not in a browsing context: * document.implementation.createDocument() (uses interface "XMLDocument" and is an "XML document") * document.implementation.createHTMLDocument() (uses interface "Document" and is an "HTML document") * new Document() (uses interface "Document" and is an "XML document") * XHR response (uses interface "Document" and is an "XML document", even for text/html if I read the spec correctly) For instance the createHTMLDocument() case currently supports named getter in Gecko but not in Blink. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2519 -- Simon Pieters Opera Software From dschulze at adobe.com Fri Sep 13 01:27:37 2013 From: dschulze at adobe.com (Dirk Schulze) Date: Fri, 13 Sep 2013 01:27:37 -0700 Subject: [whatwg] Fetch SVG images with No CORS tainted cross-origin Message-ID: <A8E761CD-7DB9-4692-BBB3-9C9572B6C833@adobe.com> Hi, If I understand HTML <img> fetching and the fetch spec right. The default behavior on image fetching is No CORS with the mode tainted cross-origin. For the example: <img src="image.svg"> and image.svg: <svg> <image xlink:href="http://otherdomain.com/image.svg"> </svg> In this case the image.svg would be fetched with basic fetch and tainted cross-origin. But the image inside this image would also be loaded as basic fetch tainted cross origin. Right? For various reasons (as described in Mozilla bug 628747[1]). We do not want to have image load further _external_ resources. WebKit, Blink and Gecko allow dataURLs and Gecko allows blobs as resources. I couldn't find a specification for that in the Fetch specification. WebKit and Blink call that "single security origin". If the SVG was fetched as an image resource, it is not allowed to fetch other resources with the described exception above. So, I wonder how that behavior could be described. Sadly it is not always the same behavior. If the SVG image is referenced by an <object>, <embed> or <iframe>, it does not count as "image" anymore but as a document and it can fetch resources again. For my use case of <mask> and <filter> the SVG WG resolved to have the same fetching mechanisms and restrictions as for SVG as "images". To summarize. We have two kind of possibilities of fetching in SVG: SVG with "single security origin": The SVG is not allowed to fetch any external resources. References in the same document and dataURLs, blobs are allowed. SVG "as document": Allowed to fetch resources with No CORS - But: possibly CORS enabled depending on the referencing element (<object>, <embed> or <iframe>). Would it be possible to define it that way? If the former named elements, then use the fetching mechanism defined by these elements. Otherwise use "single security origin"? Could Fetch define "single security origin"? Greetings, Dirk [1] https://bugzilla.mozilla.org/show_bug.cgi?id=628747 From annevk at annevk.nl Fri Sep 13 01:35:40 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Fri, 13 Sep 2013 09:35:40 +0100 Subject: [whatwg] [XHR] changes in abort() steps In-Reply-To: <03fd01ceb044$195dde90$4c199bb0$@samsung.com> References: <03fd01ceb044$195dde90$4c199bb0$@samsung.com> Message-ID: <CADnb78hUkfFHKrVo9DmToMPXp_tmGuj+qYOsJkiaE7C8vNia=A@mail.gmail.com> On Fri, Sep 13, 2013 at 6:42 AM, Jungkee Song <jungkee.song at samsung.com> wrote: > In the recent change in abort() steps, is it intended to NOT change the > state to UNSENT for an ongoing (the send() flag set) request? It's observed > that Chrome, Firefox, IE all set it to UNSENT. Also, a few test cases in W3C > tests have assertions on it: > > request.send(); > request.abort(); > request.assert_true(client.readyState, [0]); Good catch! I totally missed abort() would always end up in UNSENT. Tried to make that clearer by appending " first" to "Otherwise, run these substeps". -- http://annevankesteren.nl/ From annevk at annevk.nl Fri Sep 13 01:43:25 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Fri, 13 Sep 2013 09:43:25 +0100 Subject: [whatwg] Fetch SVG images with No CORS tainted cross-origin In-Reply-To: <A8E761CD-7DB9-4692-BBB3-9C9572B6C833@adobe.com> References: <A8E761CD-7DB9-4692-BBB3-9C9572B6C833@adobe.com> Message-ID: <CADnb78iGxPOhS+V0xB441s=mJmYbcq8-E8fLy=fgJy3STgfjMA@mail.gmail.com> On Fri, Sep 13, 2013 at 9:27 AM, Dirk Schulze <dschulze at adobe.com> wrote: > So, I wonder how that behavior could be described. I think you'd have a mode switch and maybe a wrapper for Fetch that only calls it for data and blob URLs. It seems like you don't really want to invoke Fetch at all for SVG as image. Do scripts even execute in that context? How do you get blob URLs? I suppose we could have a mode for that in Fetch too, but it seems really SVG specific so I'm not sure that's warranted. > SVG with "single security origin": The SVG is not allowed to fetch any external resources. References in the same document and dataURLs, blobs are allowed. > SVG "as document": Allowed to fetch resources with No CORS - But: possibly CORS enabled depending on the referencing element (<object>, <embed> or <iframe>). > > Would it be possible to define it that way? If the former named elements, then use the fetching mechanism defined by these elements. Otherwise use "single security origin"? Could Fetch define "single security origin"? This sentence doesn't make sense. At least the "otherwise" clause in it. I'm not sure "single security origin" makes sense either as I think you don't want to do any fetching whatsoever. If something does a fetch, you want to return network error immediately and don't even attempt to make a connection as that could leak information. So SVG resources should have a "locked down flag" and when it's set "SVG fetch" or whatever you end up calling the wrapper will return "network error" rather than invoking "fetch" unless the URL's scheme is about, blob, or data I suppose. -- http://annevankesteren.nl/ From annevk at annevk.nl Fri Sep 13 01:53:42 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Fri, 13 Sep 2013 09:53:42 +0100 Subject: [whatwg] Why are we merging Document and HTMLDocument again? In-Reply-To: <op.w3cac0spidj3kv@simons-macbook-pro.local> References: <51361FA0.8070101@mit.edu> <CADnb78gB=pdOGZ4tY09V-oANt4+KB-WgoDaEuoR1ibjq+N861g@mail.gmail.com> <51362266.7010804@mit.edu> <CADnb78j_ELAmskAB41-K_DTVbNWuPYfn-fa-VC-n2f=OtA0mQg@mail.gmail.com> <51362671.1010302@mit.edu> <Pine.LNX.4.64.1303052029350.15713@ps20323.dreamhostps.com> <5136589D.4040800@mit.edu> <CADnb78hWVVU1qjKU=mK5AXwwNUmsKHeNfD7HmY1OD2Rj+EXmxw@mail.gmail.com> <alpine.DEB.2.00.1307121752451.15729@ps20323.dreamhostps.com> <51E04531.4070801@mit.edu> <0ED2DF0C-C0AC-496C-8B8B-37FF90D0B436@apple.com> <alpine.DEB.2.00.1309121836290.12199@ps20323.dreamhostps.com> <1D191C36-CE39-4A1F-AF45-A75673C35EA1@apple.com> <alpine.DEB.2.00.1309122055280.12210@ps20323.dreamhostps.com> <3BD3DB4F-5409-4CC9-9310-2C7E90CBC37B@apple.com> <alpine.DEB.2.00.1309130409200.12210@ps20323.dreamhostps.com> <op.w3cac0spidj3kv@simons-macbook-pro.local> Message-ID: <CADnb78iH2J02uX7Winh=93BBNnovUXeo2T0Dfy_Q5aN0+x+o5w@mail.gmail.com> On Fri, Sep 13, 2013 at 8:42 AM, Simon Pieters <simonp at opera.com> wrote: > * XHR response (uses interface "Document" and is an "XML document", even for > text/html if I read the spec correctly) I assumed :/ that HTML would do the marking. Let's consider this a bug. It's not entirely clear to me what the suggestion from Ryosuke is. Is it to keep getters on HTMLDocument only and expose HTMLDocument only in browsing contexts created from text/html resources? And use Document everywhere else and have Document contain all the other members including (former) SVGDocument members? That setup would make sense to me anyway. -- http://annevankesteren.nl/ From dschulze at adobe.com Fri Sep 13 02:52:18 2013 From: dschulze at adobe.com (Dirk Schulze) Date: Fri, 13 Sep 2013 02:52:18 -0700 Subject: [whatwg] Fetch SVG images with No CORS tainted cross-origin In-Reply-To: <CADnb78iGxPOhS+V0xB441s=mJmYbcq8-E8fLy=fgJy3STgfjMA@mail.gmail.com> References: <A8E761CD-7DB9-4692-BBB3-9C9572B6C833@adobe.com> <CADnb78iGxPOhS+V0xB441s=mJmYbcq8-E8fLy=fgJy3STgfjMA@mail.gmail.com> Message-ID: <1B872A94-5E1E-4E5C-B42B-04B1D8AB9555@adobe.com> On Sep 13, 2013, at 10:43 AM, Anne van Kesteren <annevk at annevk.nl> wrote: > On Fri, Sep 13, 2013 at 9:27 AM, Dirk Schulze <dschulze at adobe.com> wrote: >> So, I wonder how that behavior could be described. > > I think you'd have a mode switch and maybe a wrapper for Fetch that > only calls it for data and blob URLs. It seems like you don't really > want to invoke Fetch at all for SVG as image. If Fetch is not just fetching external (as not in the current document) then we still need it for SVG. References within the same document must still work. > Do scripts even execute > in that context? How do you get blob URLs? In WebKit and Blink you can't execute any script anywhere in an SVG document. I am not sure about Gecko but this is the feedback I got. Maybe someone from Mozilla can answer this. > > I suppose we could have a mode for that in Fetch too, but it seems > really SVG specific so I'm not sure that's warranted. > Yes, it is quite SVG specific. I am fine with just dealing with it in SVG as long as possible. And I think it is not possible without changing the fetching on the requesters like <img>. (This is the case for CSS as well btw, which can reference SVG images - different topic.) > >> SVG with "single security origin": The SVG is not allowed to fetch any external resources. References in the same document and dataURLs, blobs are allowed. >> SVG "as document": Allowed to fetch resources with No CORS - But: possibly CORS enabled depending on the referencing element (<object>, <embed> or <iframe>). >> >> Would it be possible to define it that way? If the former named elements, then use the fetching mechanism defined by these elements. Otherwise use "single security origin"? Could Fetch define "single security origin"? > > This sentence doesn't make sense. At least the "otherwise" clause in > it. I'm not sure "single security origin" makes sense either as I > think you don't want to do any fetching whatsoever. If something does > a fetch, you want to return network error immediately and don't even > attempt to make a connection as that could leak information. So SVG > resources should have a "locked down flag" and when it's set "SVG > fetch" or whatever you end up calling the wrapper will return "network > error" rather than invoking "fetch" unless the URL's scheme is about, > blob, or data I suppose. So first, for the first case (before "otherwise") there is nothing that needs to be changed. Fetch and HTML already cover that. The second case would indeed need a flag like "locked down flag". This would just allow fetching of resources in the same document, dataURLs (with lock down for the content of dataURL) and possibly blob URLs. The requester needs to set this "lock down flag". So ideally it would be specified by the Fetch specification. Legacy fetching (used for image fetching) would set this flag by default. In this case no other specification but Fetch and CSS would need to change. Greetings, Dirk > > > -- > http://annevankesteren.nl/ From robin at w3.org Fri Sep 13 03:10:47 2013 From: robin at w3.org (Robin Berjon) Date: Fri, 13 Sep 2013 12:10:47 +0200 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: <CADnb78jQQC3hdRFYfd5n05+VucVhsr9hYUn8OYM=kBGbPcdDJA@mail.gmail.com> References: <CADnb78jksF5RdfPK4Brcib=N-jYcf0YrO=o=fFz4ZLUqTgLUMg@mail.gmail.com> <EE30D49E-FDB4-4BDA-AC0E-33B4E6B2C521@4d.com> <DE55B4C4-6983-44DD-8C44-5E552259D8A4@4d.com> <CADnb78jQQC3hdRFYfd5n05+VucVhsr9hYUn8OYM=kBGbPcdDJA@mail.gmail.com> Message-ID: <5232E4A7.5030203@w3.org> On 29/08/2013 14:48 , Anne van Kesteren wrote: > On Thu, Aug 29, 2013 at 1:15 PM, Alexandre Morgaut > <Alexandre.Morgaut at 4d.com> wrote: >> In the solution mentioned with <link> tag and a "pack:" like scheme >> >> <link id="pack1" rel="package" src="/pack1.zip" type="application/zip" title="My app global resources"> > > I don't think adding a level of indirection is a good idea. I think > the added complexity is the reason this proposal failed the last time > and I don't see a reason to revive it. Actually, the primary objection I recall from the last round of this was that it did not address the major use case that was being considered then, which was performance. It's a revisit of "Limi Packages" and it would seem that they can 1) be slower than individual files in a fair number of cases and 2) bring between nothing and very little compared to SPDY. Of course, that does not remove the value there is in making Zip first class for reasons other than performance. If we can do it without the above indirection then it clearly is better, but using <link> indirection it is possible to make this work without a new scheme, without changing the URL syntax, and while opening the door to graceful fallback. The basic idea is that you start with this: <link rel="package" href="/foo.zip"> and then every URL in the document (e.g. <img src="/foo.zip/meow.gif">) that's a prefix-match for the link's href gets loaded through the zip. Older browsers will fetch /foo.zip/meow.gif, which the server can trivially detect as an error and handle by sending the content from inside the zip. I would rather we figured this out without <link>, but apart from the indirection I reckon this approach has some nice properties and might work if more direct ones don't. -- Robin Berjon - http://berjon.com/ - @robinberjon From robin at w3.org Fri Sep 13 03:12:21 2013 From: robin at w3.org (Robin Berjon) Date: Fri, 13 Sep 2013 12:12:21 +0200 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: <521F4E87.6070202@mit.edu> References: <CADnb78jksF5RdfPK4Brcib=N-jYcf0YrO=o=fFz4ZLUqTgLUMg@mail.gmail.com> <CAJ5xic-npAJAhWV4sV7ut=5Vu3bTfuxfeXLtjtnvj9B6st8mAQ@mail.gmail.com> <CADnb78ieWieX_eZ44QB09tMW8_FP4YNFxCZNs4hgUrkd8drBGQ@mail.gmail.com> <521F4C0B.9020101@mit.edu> <CADnb78jiMvF5-w6249LyyjUSi7CgfRzVSHCoA0hmemRJsmEAFg@mail.gmail.com> <521F4E87.6070202@mit.edu> Message-ID: <5232E505.7040102@w3.org> On 29/08/2013 15:37 , Boris Zbarsky wrote: > On 8/29/13 9:32 AM, Anne van Kesteren wrote: >> Doing a mixture of sniffing and labeling has not served us very well. >> We cannot rely solely on sniffing because of CSS and SVG. We can rely >> solely on a standardized mapping table of extension to Content-Type. > > Ah, ok, the extension table is standardized, not gotten from the OS? OK, > that works. And shockingly enough, that's been done before: http://www.w3.org/TR/widgets/#rule-for-identifying-the-media-type-of-a-file-0 There could be a few things worth pilfering from that document in general. -- Robin Berjon - http://berjon.com/ - @robinberjon From robin at w3.org Fri Sep 13 03:32:43 2013 From: robin at w3.org (Robin Berjon) Date: Fri, 13 Sep 2013 12:32:43 +0200 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: <op.w2kzr1yiidj3kv@simons-macbook-pro.local> References: <CADnb78jksF5RdfPK4Brcib=N-jYcf0YrO=o=fFz4ZLUqTgLUMg@mail.gmail.com> <CAJ5xic-npAJAhWV4sV7ut=5Vu3bTfuxfeXLtjtnvj9B6st8mAQ@mail.gmail.com> <CADnb78ieWieX_eZ44QB09tMW8_FP4YNFxCZNs4hgUrkd8drBGQ@mail.gmail.com> <op.w2kzr1yiidj3kv@simons-macbook-pro.local> Message-ID: <5232E9CB.5010409@w3.org> On 29/08/2013 15:58 , Simon Pieters wrote: > On Thu, 29 Aug 2013 15:02:48 +0200, Anne van Kesteren <annevk at annevk.nl> > wrote: >> On Thu, Aug 29, 2013 at 1:19 PM, Jake Archibald >> <jaffathecake at gmail.com> wrote: >>> Causing a network error in existing browsers is a shame. > > It seems to fail to resolve in IE10. It works in > Gecko/WebKit/Blink/Presto: the %! is requested literally. However, both > Apache and IIS seems to return 400 Bad Request. That's not exactly promising. >> Picking something that could occur in paths seems problematic. > > I'm not sure why it's more problematic than something than could occur > in the fragment. > > For instance, the string "$zip=" is not present at all in > http://webdevdata.org/ data set 18/06/2013. So maybe we could use a > string like that in the path and have a graceful fallback path in legacy > browsers that work in existing servers. That's my preferred approach so far. However I wonder about the precise details. Assuming <img src="/foo.zip/$zip=dahut.png"> I'm guessing that the browser would actually just request "/foo.zip" from the server in the same manner that fragments are stripped, right? Somehow the stripping bothers me a bit; for instance, what would Navigation Controller see? I wonder if we couldn't just use the query part for this: <img src="/foo.zip?!zip/dahut.png">. No stripping is needed (as far as I know servers would normally just serve foo.zip in this case), which simplifies the model. -- Robin Berjon - http://berjon.com/ - @robinberjon From robert at ocallahan.org Fri Sep 13 04:07:25 2013 From: robert at ocallahan.org (Robert O'Callahan) Date: Fri, 13 Sep 2013 04:07:25 -0700 Subject: [whatwg] High-density canvases In-Reply-To: <alpine.DEB.2.00.1309121742300.12210@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <225F987F-31A2-4940-BF4B-AB7EAFD2FA21@apple.com> <alpine.DEB.2.00.1309101931090.12210@ps20323.dreamhostps.com> <0EDBDB6E-9527-4E98-9791-CD16E2ACC6FD@apple.com> <CAGN7qDCC=8EZUpEmN=10tcWGU=8TPQ7rej+sOGhbPaWqqAjWRA@mail.gmail.com> <CAOp6jLZFD_HVKgEfEUB0myCdvz60i_=1NASVQ-YKyzcHxkDxVw@mail.gmail.com> <alpine.DEB.2.00.1309111823370.12210@ps20323.dreamhostps.com> <CAOp6jLaxkdDE5qKaZmUxHs5Jic8h3yCnE+j7dCUgAHQWLQBiEg@mail.gmail.com> <alpine.DEB.2.00.1309121742300.12210@ps20323.dreamhostps.com> Message-ID: <CAOp6jLZUq1CnZcxnJ0GgK3UtSDE9OOiTNnT6bzQOVN=koHXtmA@mail.gmail.com> On Thu, Sep 12, 2013 at 10:42 AM, Ian Hickson <ian at hixie.ch> wrote: > On Thu, 12 Sep 2013, Robert O'Callahan wrote: > > On Wed, Sep 11, 2013 at 11:24 AM, Ian Hickson <ian at hixie.ch> wrote: > > > On Wed, 11 Sep 2013, Robert O'Callahan wrote: > > > > Pinch-zoom is hard because we don't want to trigger reflows or other > > > > expensive behavior on pinch-zoom. I'd leave pinch-zoom out of it for > > > > now. > > > > > > Unless I'm missing something fundamental, changing the pixel density > > > doesn't cause a layout, it's changing the width that causes a layout. > > > > Changing pixel density does cause a layout in Gecko. For example we > > round CSS border widths to a whole number of device pixels. (This > > ensures that when page zoom is applied, all borders with the same > > specified width are rendered with the same visual width.) On some > > platforms (Windows), changing pixel density affects text hinting which > > affects text layout. > > So how do you do pinch-zoom under the hood on mobile devices? > We don't change layout, we just rerender with transformed coordinates. This means that pinch-zoom can break apparent border-widths and you can get ugly hinting on platforms that use pinch-zoom and have fonts with aggressive hinting. We could continue to not change layout, and still change the pixel density of canvases during or after pinch-zoom. We could even change the pixel density of canvases inside scaling CSS transforms. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * From annevk at annevk.nl Fri Sep 13 04:15:22 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Fri, 13 Sep 2013 12:15:22 +0100 Subject: [whatwg] Fetch SVG images with No CORS tainted cross-origin In-Reply-To: <1B872A94-5E1E-4E5C-B42B-04B1D8AB9555@adobe.com> References: <A8E761CD-7DB9-4692-BBB3-9C9572B6C833@adobe.com> <CADnb78iGxPOhS+V0xB441s=mJmYbcq8-E8fLy=fgJy3STgfjMA@mail.gmail.com> <1B872A94-5E1E-4E5C-B42B-04B1D8AB9555@adobe.com> Message-ID: <CADnb78j8vOsF4eU4kPm60Db2vjz268dnOEkHOo3wCrOdjc6EUA@mail.gmail.com> On Fri, Sep 13, 2013 at 10:52 AM, Dirk Schulze <dschulze at adobe.com> wrote: > If Fetch is not just fetching external (as not in the current document) then we still need it for SVG. References within the same document must still work. Fragment identifiers are to be handled by SVG. Again, your "SVG fetch" wrapper could let through certain URLs and not others, but I'm not sure if the only difference is a fragment identifier if that would even go through Fetch. I kinda doubt it since Fetch is async and fragment handling is generally sync. (Good question to answer for https://github.com/slightlyoff/EventWorker/ though as that would make this difference observable.) >> Do scripts even execute >> in that context? How do you get blob URLs? > > In WebKit and Blink you can't execute any script anywhere in an SVG document. I am not sure about Gecko but this is the feedback I got. Maybe someone from Mozilla can answer this. You mean SVG image right? So how do you get a blob URL? >> I suppose we could have a mode for that in Fetch too, but it seems >> really SVG specific so I'm not sure that's warranted. > > Yes, it is quite SVG specific. I am fine with just dealing with it in SVG as long as possible. And I think it is not possible without changing the fetching on the requesters like <img>. (This is the case for CSS as well btw, which can reference SVG images - different topic.) Well, for HTML <img> it's not about fetching. It just has to say that when it gets SVG back, it sets the "locked down flag" or the "image flag" or uses SVG in "image mode" or however SVG decides to name that. > The second case would indeed need a flag like "locked down flag". This would just allow fetching of resources in the same document, dataURLs (with lock down for the content of dataURL) and possibly blob URLs. There's no such thing as fetching resources in the same document. > The requester needs to set this "lock down flag". So ideally it would be specified by the Fetch specification. Legacy fetching (used for image fetching) would set this flag by default. In this case no other specification but Fetch and CSS would need to change. No that's not how this flag works. The flag is for an SVG resource and when you interpret that resource and do SVG fetching it would come into effect. -- http://annevankesteren.nl/ From jirka at kosek.cz Fri Sep 13 04:31:07 2013 From: jirka at kosek.cz (Jirka Kosek) Date: Fri, 13 Sep 2013 13:31:07 +0200 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: <5232E4A7.5030203@w3.org> References: <CADnb78jksF5RdfPK4Brcib=N-jYcf0YrO=o=fFz4ZLUqTgLUMg@mail.gmail.com> <EE30D49E-FDB4-4BDA-AC0E-33B4E6B2C521@4d.com> <DE55B4C4-6983-44DD-8C44-5E552259D8A4@4d.com> <CADnb78jQQC3hdRFYfd5n05+VucVhsr9hYUn8OYM=kBGbPcdDJA@mail.gmail.com> <5232E4A7.5030203@w3.org> Message-ID: <5232F77B.4050908@kosek.cz> On 13.9.2013 12:10, Robin Berjon wrote: > I would rather we figured this out without <link>, but apart from the > indirection I reckon this approach has some nice properties and might > work if more direct ones don't. Also don't forget that while linking is the hardest part of this ZIP circus there is another missing piece -- normative definition of portable and RF subset of ZIP. SC34 started some initial work on such ZIP profile recently: http://www.itscj.ipsj.or.jp/sc34/open/1855.pdf So if some sort of ZIP packaging spec should to appear then it should reference such subset of ZIP not the full definition of ZIP format from PKWare. Jirka -- ------------------------------------------------------------------ Jirka Kosek e-mail: jirka at kosek.cz http://xmlguru.cz ------------------------------------------------------------------ Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing ------------------------------------------------------------------ OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep. ------------------------------------------------------------------ Bringing you XML Prague conference http://xmlprague.cz ------------------------------------------------------------------ From robin at w3.org Fri Sep 13 05:24:26 2013 From: robin at w3.org (Robin Berjon) Date: Fri, 13 Sep 2013 14:24:26 +0200 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: <5232F77B.4050908@kosek.cz> References: <CADnb78jksF5RdfPK4Brcib=N-jYcf0YrO=o=fFz4ZLUqTgLUMg@mail.gmail.com> <EE30D49E-FDB4-4BDA-AC0E-33B4E6B2C521@4d.com> <DE55B4C4-6983-44DD-8C44-5E552259D8A4@4d.com> <CADnb78jQQC3hdRFYfd5n05+VucVhsr9hYUn8OYM=kBGbPcdDJA@mail.gmail.com> <5232E4A7.5030203@w3.org> <5232F77B.4050908@kosek.cz> Message-ID: <523303FA.1070502@w3.org> On 13/09/2013 13:31 , Jirka Kosek wrote: > On 13.9.2013 12:10, Robin Berjon wrote: >> I would rather we figured this out without <link>, but apart from the >> indirection I reckon this approach has some nice properties and might >> work if more direct ones don't. > > Also don't forget that while linking is the hardest part of this ZIP > circus there is another missing piece -- normative definition of > portable and RF subset of ZIP. SC34 started some initial work on such > ZIP profile recently: > > http://www.itscj.ipsj.or.jp/sc34/open/1855.pdf > > So if some sort of ZIP packaging spec should to appear then it should > reference such subset of ZIP not the full definition of ZIP format from > PKWare. This has also been done, perhaps not to a sufficient extent, in Widgets: http://www.w3.org/TR/widgets/#zip-archive -- Robin Berjon - http://berjon.com/ - @robinberjon From annevk at annevk.nl Fri Sep 13 05:48:27 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Fri, 13 Sep 2013 13:48:27 +0100 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: <523303FA.1070502@w3.org> References: <CADnb78jksF5RdfPK4Brcib=N-jYcf0YrO=o=fFz4ZLUqTgLUMg@mail.gmail.com> <EE30D49E-FDB4-4BDA-AC0E-33B4E6B2C521@4d.com> <DE55B4C4-6983-44DD-8C44-5E552259D8A4@4d.com> <CADnb78jQQC3hdRFYfd5n05+VucVhsr9hYUn8OYM=kBGbPcdDJA@mail.gmail.com> <5232E4A7.5030203@w3.org> <5232F77B.4050908@kosek.cz> <523303FA.1070502@w3.org> Message-ID: <CADnb78jT-7D5e5ahh3BkbeOV5n51cVS5Hi5aqn8EhPq2NFZQiA@mail.gmail.com> On Fri, Sep 13, 2013 at 1:24 PM, Robin Berjon <robin at w3.org> wrote: > This has also been done, perhaps not to a sufficient extent, in Widgets: > > http://www.w3.org/TR/widgets/#zip-archive That looks like a mess. To be fair, for the format I don't have much more than http://wiki.whatwg.org/wiki/Zip#Format at the moment though http://fetch.spec.whatwg.org/#zip-archives has a description of the data model, including the extension to Content-Type mapping. I started up drafting the various URL tactics here: http://wiki.whatwg.org/wiki/Zip#URLs Still needs a bit more work. -- http://annevankesteren.nl/ From ian at hixie.ch Fri Sep 13 12:20:57 2013 From: ian at hixie.ch (Ian Hickson) Date: Fri, 13 Sep 2013 19:20:57 +0000 (UTC) Subject: [whatwg] Namespaces and tag names in the HTML parser In-Reply-To: <5C18C3E26A4A43DF8B35BC43F882E29F@PeterPC> References: <bug-21292-2495@http.www.w3.org/Bugs/Public/> <Pine.LNX.4.64.1305292028010.2932@ps20323.dreamhostps.com> <CABMdHiQM=iTmpQgLW0VHbjvDOMU20NFPRO56tMjw95xB_PhcKQ@mail.gmail.com> <Pine.LNX.4.64.1307012230180.11139@ps20323.dreamhostps.com> <101F8E57FFCE4F44BBB459F1F176A217@PeterPC> <alpine.DEB.2.00.1307312259550.9685@ps20323.dreamhostps.com> <5C18C3E26A4A43DF8B35BC43F882E29F@PeterPC> Message-ID: <alpine.DEB.2.00.1309131903580.12199@ps20323.dreamhostps.com> On Thu, 1 Aug 2013, Peter Occil wrote: > > Many of these cases occur in the normative portion of the tree > construction stage. Most of them involve checking whether an element > (as opposed to a tag token) has a certain name: > > Accordingly, these cases are ambiguous: > > * If foster parenting is enabled and target is a table, tbody, tfoot, > thead, or tr element > > * Let last template be the last template element in the stack of open > elements, if any. > > [...] > > * Pop elements from the stack of open elements until a template element > has been popped from the stack. > > * If there is a template element on the stack of open elements, ignore > the token. > > * If the second element on the stack of open elements is not a body > element, [...] or if there is a template element on the stack of open > elements, then ignore the token. All of these hyperlink to the definition of the element and that definition is of an element in the HTML namespace, as the spec says: # Except where otherwise stated, all elements defined or mentioned in this # specification are in the HTML namespace ("http://www.w3.org/1999/xhtml") : For example, button elements are elements with the element type button, : meaning they have the local name "button" and (implicitly as defined : above) the HTML namespace. Why do you think the cases above are ambigious, but the following, for instance, are not? # The section element represents a generic section of a document or # application. # If the target of the click event is an img element [...] # A form control is disabled if its disabled attribute is set, or if it is # a descendant of a fieldset element whose disabled attribute is set and # is not a descendant of that fieldset element's first legend element # child, if any. > Moreover, where needed, a shortcut is to use "an HTML so-and-so element" > rather than "a so-and-so element in the HTML namespace". (This can > apply similarly to SVG and MathML.) I don't understand why this is necessary. I think it would be misleading because it would make authors question why other parts of the spec don't specify the namespace. I've added a redundant note to the parser intro about this, but it's redundant -- it just references the terminology section and repeats the same point again. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Fri Sep 13 14:18:55 2013 From: ian at hixie.ch (Ian Hickson) Date: Fri, 13 Sep 2013 21:18:55 +0000 (UTC) Subject: [whatwg] Parse errors for invalid characters In-Reply-To: <522900C4.2050409@googlemail.com> References: <522900C4.2050409@googlemail.com> Message-ID: <alpine.DEB.2.00.1309131921540.12199@ps20323.dreamhostps.com> On Thu, 5 Sep 2013, Geoffrey Sneddon wrote: > > The phrasing content section states: > > > Text nodes and attribute values must consist of Unicode characters, > > must not contain U+0000 characters, must not contain permanently > > undefined Unicode characters (noncharacters), and must not contain > > control characters other than space characters. > > And the pre-processing the input-stream section states: > > > Any occurrences of any characters in the ranges U+0001 to U+0008, > > U+000E to U+001F, U+007F to U+009F, U+FDD0 to U+FDEF, and characters > > U+000B, U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, U+2FFFE, U+2FFFF, U+3FFFE, > > U+3FFFF, U+4FFFE, U+4FFFF, U+5FFFE, U+5FFFF, U+6FFFE, U+6FFFF, > > U+7FFFE, U+7FFFF, U+8FFFE, U+8FFFF, U+9FFFE, U+9FFFF, U+AFFFE, > > U+AFFFF, U+BFFFE, U+BFFFF, U+CFFFE, U+CFFFF, U+DFFFE, U+DFFFF, > > U+EFFFE, U+EFFFF, U+FFFFE, U+FFFFF, U+10FFFE, and U+10FFFF are parse > > errors. These are all control characters or permanently undefined > > Unicode characters (noncharacters). > > Note the first uses "Unicode characters", the second "characters" ? the > former excludes surrogates as a conformance requirement. > > Note that every disallowed non-surrogate character is a parse error. > > Therefore, it would make sense to make surrogates parse errors. Done. > It should be noted that they can only occur in the input stream if they > come from script (as they cannot be decoded from the input byte stream > as the decoders will never emit a surrogate). Done. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From rniwa at apple.com Fri Sep 13 14:27:02 2013 From: rniwa at apple.com (Ryosuke Niwa) Date: Fri, 13 Sep 2013 14:27:02 -0700 Subject: [whatwg] Why are we merging Document and HTMLDocument again? In-Reply-To: <CADnb78iH2J02uX7Winh=93BBNnovUXeo2T0Dfy_Q5aN0+x+o5w@mail.gmail.com> References: <51361FA0.8070101@mit.edu> <CADnb78gB=pdOGZ4tY09V-oANt4+KB-WgoDaEuoR1ibjq+N861g@mail.gmail.com> <51362266.7010804@mit.edu> <CADnb78j_ELAmskAB41-K_DTVbNWuPYfn-fa-VC-n2f=OtA0mQg@mail.gmail.com> <51362671.1010302@mit.edu> <Pine.LNX.4.64.1303052029350.15713@ps20323.dreamhostps.com> <5136589D.4040800@mit.edu> <CADnb78hWVVU1qjKU=mK5AXwwNUmsKHeNfD7HmY1OD2Rj+EXmxw@mail.gmail.com> <alpine.DEB.2.00.1307121752451.15729@ps20323.dreamhostps.com> <51E04531.4070801@mit.edu> <0ED2DF0C-C0AC-496C-8B8B-37FF90D0B436@apple.com> <alpine.DEB.2.00.1309121836290.12199@ps20323.dreamhostps.com> <1D191C36-CE39-4A1F-AF45-A75673C35EA1@apple.com> <alpine.DEB.2.00.1309122055280.12210@ps20323.dreamhostps.com> <3BD3DB4F-5409-4CC9-9310-2C7E90CBC37B@apple.com> <alpine.DEB.2.00.1309130409200.12210@ps20323.dreamhostps.com> <op.w3cac0spidj3kv@simons-macbook-pro.local> <CADnb78iH2J02uX7Winh=93BBNnovUXeo2T0Dfy_Q5aN0+x+o5w@mail.gmail.com> Message-ID: <61829834-0787-4AEB-A3B3-7D552543C32A@apple.com> On Sep 13, 2013, at 1:53 AM, Anne van Kesteren <annevk at annevk.nl> wrote: > On Fri, Sep 13, 2013 at 8:42 AM, Simon Pieters <simonp at opera.com> wrote: >> * XHR response (uses interface "Document" and is an "XML document", even for >> text/html if I read the spec correctly) > > I assumed :/ that HTML would do the marking. Let's consider this a bug. > > It's not entirely clear to me what the suggestion from Ryosuke is. Is > it to keep getters on HTMLDocument only and expose HTMLDocument only > in browsing contexts created from text/html resources? And use > Document everywhere else and have Document contain all the other > members including (former) SVGDocument members? That setup would make > sense to me anyway. My proposal something along that line. But HTMLDocument also has a bunch of other junk properties like embeds, plugins, scripts, compatMode, bgColor, fgColor, alinkColor, linkColor, vlinkColor, etc? We even have write() and writeln() there! I don?t want to start adding all these legacy methods elsewhere. - R. Niwa From glenn at zewt.org Sat Sep 14 08:36:28 2013 From: glenn at zewt.org (Glenn Maynard) Date: Sat, 14 Sep 2013 10:36:28 -0500 Subject: [whatwg] Forcing orientation in content In-Reply-To: <alpine.DEB.2.00.1309102107450.12199@ps20323.dreamhostps.com> References: <516F27BF.4060508@gmail.com> <alpine.DEB.2.00.1307121944480.15729@ps20323.dreamhostps.com> <420FE1A33AB14ACB9667D659D8F415D5@gmail.com> <op.wz8k70f4te2ec8@aimac> <alpine.DEB.2.00.1309102107450.12199@ps20323.dreamhostps.com> Message-ID: <CABirCh-6OO9qb6Kh=wLQhfmmci8t-FE=6uWN51446LQu5w4mBg@mail.gmail.com> On Tue, Sep 10, 2013 at 4:22 PM, Ian Hickson <ian at hixie.ch> wrote: > > In practice, game developers are rarely willing to spend the time to > > make their games work well in both portrait and landscape. > > That's certainly true, but the reality is that on the Web a web browser > window might be any number of dimensions, so that's a problem you have to > deal with regardless. > (I'm a little confused by this, since my next sentence was explaining how games can deal with this even if they don't spend the time to make it work well.) > > > In Firefox we have implemented the screen orientation spec > > https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html > > That is unfortuate. I don't think that API puts the user first. > This is window.resizeTo all over again, and pages would use it for the same reason: "our page looks best in 640x480" becomes "our page looks best in portrait". The results will be far worse: the user's device will be flipping back and forth between orientations as he browses from page to page. Even if the user is simply tapping browser back a few times, the button will move around between each press as each page in history picks its preferred orientation. Unless implementations deal with these issues somehow, this API looks catastrophically broken. It seems like somebody just took a native mobile orientation API and translated it to JavaScript, without thinking about the differences between task switching on mobile and navigating between web pages. -- Glenn Maynard From simonp at opera.com Sat Sep 14 11:28:07 2013 From: simonp at opera.com (Simon Pieters) Date: Sat, 14 Sep 2013 20:28:07 +0200 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: <5232E9CB.5010409@w3.org> References: <CADnb78jksF5RdfPK4Brcib=N-jYcf0YrO=o=fFz4ZLUqTgLUMg@mail.gmail.com> <CAJ5xic-npAJAhWV4sV7ut=5Vu3bTfuxfeXLtjtnvj9B6st8mAQ@mail.gmail.com> <CADnb78ieWieX_eZ44QB09tMW8_FP4YNFxCZNs4hgUrkd8drBGQ@mail.gmail.com> <op.w2kzr1yiidj3kv@simons-macbook-pro.local> <5232E9CB.5010409@w3.org> Message-ID: <op.w3eyw5scidj3kv@simons-macbook-pro.local> On Fri, 13 Sep 2013 12:32:43 +0200, Robin Berjon <robin at w3.org> wrote: > On 29/08/2013 15:58 , Simon Pieters wrote: >> On Thu, 29 Aug 2013 15:02:48 +0200, Anne van Kesteren <annevk at annevk.nl> >> wrote: >>> On Thu, Aug 29, 2013 at 1:19 PM, Jake Archibald >>> <jaffathecake at gmail.com> wrote: >>>> Causing a network error in existing browsers is a shame. >> >> It seems to fail to resolve in IE10. It works in >> Gecko/WebKit/Blink/Presto: the %! is requested literally. However, both >> Apache and IIS seems to return 400 Bad Request. > > That's not exactly promising. > >>> Picking something that could occur in paths seems problematic. >> >> I'm not sure why it's more problematic than something than could occur >> in the fragment. >> >> For instance, the string "$zip=" is not present at all in >> http://webdevdata.org/ data set 18/06/2013. So maybe we could use a >> string like that in the path and have a graceful fallback path in legacy >> browsers that work in existing servers. > > That's my preferred approach so far. However I wonder about the precise > details. > > Assuming <img src="/foo.zip/$zip=dahut.png"> I'm guessing that the > browser would actually just request "/foo.zip" from the server in the > same manner that fragments are stripped, right? "/foo.zip/", but yeah. > Somehow the stripping bothers me a bit; for instance, what would > Navigation Controller see? I'm not familiar with that. > I wonder if we couldn't just use the query part for this: <img > src="/foo.zip?!zip/dahut.png">. No stripping is needed (as far as I know > servers would normally just serve foo.zip in this case), which > simplifies the model. The query is sent to the server. What the server does with it depends on the server. Making different requests for /foo.zip?!zip/dahut.png and /foo.zip?!zip/lol.png is bad because we want the same response for UAs that support the feature, but caches wouldn't know that they're the same when they have different queries. -- Simon Pieters Opera Software From jstpierre at mecheye.net Sun Sep 15 08:38:19 2013 From: jstpierre at mecheye.net (Jasper St. Pierre) Date: Sun, 15 Sep 2013 11:38:19 -0400 Subject: [whatwg] Clipping text in in canvas Message-ID: <CAA0H+QTT47mzfyzjiRTS+A2W96THOHpLd8rGHzUW8DDb5Z=QGA@mail.gmail.com> The canvas specification maintains: These shapes are painted without affecting the current path, and are subject to shadow effects, global alpha, the clipping region, and global composition operators. [0] But no browsers I tested actually implement the "clipping region" part. Should this be removed for backwards compatibility reasons? Should we introduce a new method of clipping text be introduced, or should we just require users who want to draw clipped text to draw to a scratch canvas and use drawImage to copy the pixels? [0] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#drawing-text-to-the-bitmap -- Jasper From ddailey at zoominternet.net Sun Sep 15 09:04:09 2013 From: ddailey at zoominternet.net (David Dailey) Date: Sun, 15 Sep 2013 12:04:09 -0400 Subject: [whatwg] Clipping text in in canvas In-Reply-To: <CAA0H+QTT47mzfyzjiRTS+A2W96THOHpLd8rGHzUW8DDb5Z=QGA@mail.gmail.com> References: <CAA0H+QTT47mzfyzjiRTS+A2W96THOHpLd8rGHzUW8DDb5Z=QGA@mail.gmail.com> Message-ID: <000601ceb22d$36ae0610$a40a1230$@net> Last I checked applying a clipPath to text in SVG works consistently across browsers, and there it remains accessible: to screen readers, indexing, searching, drag-to-select, etc. Why would one want a bunch of pixels that resemble text? Just saying, David -----Original Message----- From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Jasper St. Pierre Sent: Sunday, September 15, 2013 11:38 AM To: whatwg at whatwg.org Subject: [whatwg] Clipping text in in canvas The canvas specification maintains: These shapes are painted without affecting the current path, and are subject to shadow effects, global alpha, the clipping region, and global composition operators. [0] But no browsers I tested actually implement the "clipping region" part. Should this be removed for backwards compatibility reasons? Should we introduce a new method of clipping text be introduced, or should we just require users who want to draw clipped text to draw to a scratch canvas and use drawImage to copy the pixels? [0] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-eleme nt.html#drawing-text-to-the-bitmap -- Jasper From jstpierre at mecheye.net Sun Sep 15 09:09:08 2013 From: jstpierre at mecheye.net (Jasper St. Pierre) Date: Sun, 15 Sep 2013 12:09:08 -0400 Subject: [whatwg] Clipping text in in canvas In-Reply-To: <000601ceb22d$36ae0610$a40a1230$@net> References: <CAA0H+QTT47mzfyzjiRTS+A2W96THOHpLd8rGHzUW8DDb5Z=QGA@mail.gmail.com> <000601ceb22d$36ae0610$a40a1230$@net> Message-ID: <CAA0H+QQbAPv2Si4DBEePJAmscQQxVMguHE4sQjbR5jB8kUUW4g@mail.gmail.com> On Sun, Sep 15, 2013 at 12:04 PM, David Dailey <ddailey at zoominternet.net>wrote: > Last I checked applying a clipPath to text in SVG works consistently across > browsers, and there it remains accessible: to screen readers, indexing, > searching, drag-to-select, etc. Why would one want a bunch of pixels that > resemble text? > > Just saying, > David > I have an insane, complex use case, and you'd laugh at me if I told you what it was, but trust me when I say I need an immediate mode drawing API like <canvas> instead of a retained scene graph like SVG. -----Original Message----- > From: whatwg-bounces at lists.whatwg.org > [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Jasper St. Pierre > Sent: Sunday, September 15, 2013 11:38 AM > To: whatwg at whatwg.org > Subject: [whatwg] Clipping text in in canvas > > The canvas specification maintains: > > These shapes are painted without affecting the current path, and are > subject to shadow effects, global alpha, the clipping region, and global > composition operators. [0] > > But no browsers I tested actually implement the "clipping region" part. > Should this be removed for backwards compatibility reasons? Should we > introduce a new method of clipping text be introduced, or should we just > require users who want to draw clipped text to draw to a scratch canvas and > use drawImage to copy the pixels? > [0] > > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-eleme > nt.html#drawing-text-to-the-bitmap > > -- > Jasper > > > -- Jasper From ddailey at zoominternet.net Sun Sep 15 09:19:25 2013 From: ddailey at zoominternet.net (David Dailey) Date: Sun, 15 Sep 2013 12:19:25 -0400 Subject: [whatwg] Clipping text in in canvas In-Reply-To: <CAA0H+QQbAPv2Si4DBEePJAmscQQxVMguHE4sQjbR5jB8kUUW4g@mail.gmail.com> References: <CAA0H+QTT47mzfyzjiRTS+A2W96THOHpLd8rGHzUW8DDb5Z=QGA@mail.gmail.com> <000601ceb22d$36ae0610$a40a1230$@net> <CAA0H+QQbAPv2Si4DBEePJAmscQQxVMguHE4sQjbR5jB8kUUW4g@mail.gmail.com> Message-ID: <000a01ceb22f$58516760$08f43620$@net> I'm sure there are such uses and I'm assured that you have one. I was just sending out my canned reminder that alternatives to canvas exist (many folks seemed not to know that, only a few years ago). Cheers and regards D From: magcius at gmail.com [mailto:magcius at gmail.com] On Behalf Of Jasper St. Pierre Sent: Sunday, September 15, 2013 12:09 PM To: David Dailey Cc: whatwg at whatwg.org Subject: Re: [whatwg] Clipping text in in canvas On Sun, Sep 15, 2013 at 12:04 PM, David Dailey <ddailey at zoominternet.net> wrote: Last I checked applying a clipPath to text in SVG works consistently across browsers, and there it remains accessible: to screen readers, indexing, searching, drag-to-select, etc. Why would one want a bunch of pixels that resemble text? Just saying, David I have an insane, complex use case, and you'd laugh at me if I told you what it was, but trust me when I say I need an immediate mode drawing API like <canvas> instead of a retained scene graph like SVG. -----Original Message----- From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Jasper St. Pierre Sent: Sunday, September 15, 2013 11:38 AM To: whatwg at whatwg.org Subject: [whatwg] Clipping text in in canvas The canvas specification maintains: These shapes are painted without affecting the current path, and are subject to shadow effects, global alpha, the clipping region, and global composition operators. [0] But no browsers I tested actually implement the "clipping region" part. Should this be removed for backwards compatibility reasons? Should we introduce a new method of clipping text be introduced, or should we just require users who want to draw clipped text to draw to a scratch canvas and use drawImage to copy the pixels? [0] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-eleme <http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-elem ent.html#drawing-text-to-the-bitmap> nt.html#drawing-text-to-the-bitmap -- Jasper -- Jasper From cabanier at gmail.com Sun Sep 15 17:05:52 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Sun, 15 Sep 2013 17:05:52 -0700 Subject: [whatwg] Clipping text in in canvas In-Reply-To: <CAA0H+QTT47mzfyzjiRTS+A2W96THOHpLd8rGHzUW8DDb5Z=QGA@mail.gmail.com> References: <CAA0H+QTT47mzfyzjiRTS+A2W96THOHpLd8rGHzUW8DDb5Z=QGA@mail.gmail.com> Message-ID: <CAGN7qDAnndDR038gy0BmrRwdEy4BvYOti5AOBmMdmyoj7GG7aA@mail.gmail.com> I think that by 'clipping region', the spec means the 'region that is not clipped'. You can clip anything (including text) in canvas. ie http://jsfiddle.net/6eGxU/23/ On Sun, Sep 15, 2013 at 8:38 AM, Jasper St. Pierre <jstpierre at mecheye.net>wrote: > The canvas specification maintains: > > These shapes are painted without affecting the current path, and are > subject to shadow effects, global alpha, the clipping region, and global > composition operators. [0] > > But no browsers I tested actually implement the "clipping region" part. > Should this be removed for backwards compatibility reasons? Should we > introduce a new method of clipping text be introduced, or should we just > require users who want to draw clipped text to draw to a scratch canvas and > use drawImage to copy the pixels? > [0] > > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#drawing-text-to-the-bitmap > > -- > Jasper > From julian.reschke at gmx.de Mon Sep 16 00:09:35 2013 From: julian.reschke at gmx.de (Julian Reschke) Date: Mon, 16 Sep 2013 09:09:35 +0200 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: <5232E9CB.5010409@w3.org> References: <CADnb78jksF5RdfPK4Brcib=N-jYcf0YrO=o=fFz4ZLUqTgLUMg@mail.gmail.com> <CAJ5xic-npAJAhWV4sV7ut=5Vu3bTfuxfeXLtjtnvj9B6st8mAQ@mail.gmail.com> <CADnb78ieWieX_eZ44QB09tMW8_FP4YNFxCZNs4hgUrkd8drBGQ@mail.gmail.com> <op.w2kzr1yiidj3kv@simons-macbook-pro.local> <5232E9CB.5010409@w3.org> Message-ID: <5236AEAF.4040305@gmx.de> On 2013-09-13 12:32, Robin Berjon wrote: > On 29/08/2013 15:58 , Simon Pieters wrote: >> On Thu, 29 Aug 2013 15:02:48 +0200, Anne van Kesteren <annevk at annevk.nl> >> wrote: >>> On Thu, Aug 29, 2013 at 1:19 PM, Jake Archibald >>> <jaffathecake at gmail.com> wrote: >>>> Causing a network error in existing browsers is a shame. >> >> It seems to fail to resolve in IE10. It works in >> Gecko/WebKit/Blink/Presto: the %! is requested literally. However, both >> Apache and IIS seems to return 400 Bad Request. > > That's not exactly promising. > ... Because it's an invalid URI. "%" needs to be percent-escaped. Best regards, Julian From annevk at annevk.nl Mon Sep 16 00:26:01 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Mon, 16 Sep 2013 08:26:01 +0100 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: <5236AEAF.4040305@gmx.de> References: <CADnb78jksF5RdfPK4Brcib=N-jYcf0YrO=o=fFz4ZLUqTgLUMg@mail.gmail.com> <CAJ5xic-npAJAhWV4sV7ut=5Vu3bTfuxfeXLtjtnvj9B6st8mAQ@mail.gmail.com> <CADnb78ieWieX_eZ44QB09tMW8_FP4YNFxCZNs4hgUrkd8drBGQ@mail.gmail.com> <op.w2kzr1yiidj3kv@simons-macbook-pro.local> <5232E9CB.5010409@w3.org> <5236AEAF.4040305@gmx.de> Message-ID: <CADnb78gwtKakXPTcEwDd1sO_YtqN3hGsDqVq_nvH4OHjBeVA0A@mail.gmail.com> On Mon, Sep 16, 2013 at 8:09 AM, Julian Reschke <julian.reschke at gmx.de> wrote: > Because it's an invalid URI. "%" needs to be percent-escaped. That was the whole point of that particular proposal. It seems something like $zip= might be better though it wouldn't be fully backwards compatible with all valid data URLs to date... -- http://annevankesteren.nl/ From junov at google.com Mon Sep 16 08:25:45 2013 From: junov at google.com (Justin Novosad) Date: Mon, 16 Sep 2013 11:25:45 -0400 Subject: [whatwg] Clipping text in in canvas In-Reply-To: <CAA0H+QTT47mzfyzjiRTS+A2W96THOHpLd8rGHzUW8DDb5Z=QGA@mail.gmail.com> References: <CAA0H+QTT47mzfyzjiRTS+A2W96THOHpLd8rGHzUW8DDb5Z=QGA@mail.gmail.com> Message-ID: <CABpaAqSJkr6z_xZ2VQn6k7KCJox0+iSiq3tLz5S3F=m3jnnTQA@mail.gmail.com> On Sun, Sep 15, 2013 at 11:38 AM, Jasper St. Pierre <jstpierre at mecheye.net>wrote: > But no browsers I tested actually implement the "clipping region" part. > That is weird because all the browsers I tested do implement it. Perhaps something is unclear? What do *you* think that part of the spec means? As far as I am concerned, the fact that the term "clipping region" is a hyperlink to the definition of the 2d canvas clip() method makes it clear enough to me. But maybe my reading is biased because I am already familiar with the feature. Please let us know if you think any of it is ambiguous or confusing. Did you think this had something to do with CSS clipping? -Justin From ian at hixie.ch Mon Sep 16 10:35:28 2013 From: ian at hixie.ch (Ian Hickson) Date: Mon, 16 Sep 2013 17:35:28 +0000 (UTC) Subject: [whatwg] Form-associated elements and the parser In-Reply-To: <CAEvLGcKMnO3L2vnscVCYJppqtstQQx1B78cbDKAEZcXTMrSdog@mail.gmail.com> References: <CAEvLGcJMUTFVcjzfKRALvZYqt2HDAtznbWmOZQ_Ecs_kHkOc=g@mail.gmail.com> <CA+c2ei_GsNi=Mv-b8m8+5h1ggWNLdpB4eKCezyqFqkmkpB1iiQ@mail.gmail.com> <CAEvLGcJVS5CAp=DS6Q8cyN59vNLE0d2dcknLacv21LkRUrJiyA@mail.gmail.com> <CA+c2ei8M99CYRbXUdYDwk3TXR6JafZwb1JyoQEzqpbSzQ2RvjQ@mail.gmail.com> <CAEvLGcKMnO3L2vnscVCYJppqtstQQx1B78cbDKAEZcXTMrSdog@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309132241120.12199@ps20323.dreamhostps.com> On Tue, 6 Aug 2013, Adam Klein wrote: > > Hixie opened my eyes last week to parser-association behavior of the > sort found at > http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2428. > > In that case, an <input> in a detached tree is associated with a <form> > in the main document. This causes badness in WebKit and Blink because > the association between the <form> and the <input> (e.g., as exposed in > the HTMLFormElement.elements collection) is only weakly held to avoid > reference loops (and thus memory leaks). And that weakness occasionally > results in crashes when one of these objects is collected before the > other. > > While all modern HTML parser implementations I tested seemed to agree on > their treatment of the above example (they all return "1" as > elements.length), this feature doesn't strike me as terribly useful. And > for what it's worth, it doesn't seem to be present in legacy IE. > > I'm interested what others would think about changing the parser to only > associate a <form> with an <input> if both are in the same "home > subtree" Or is there some deep web-compat reason for this parsing > oddity? On Tue, 6 Aug 2013, Jonas Sicking wrote: > > Sure, as long as you come up with a formalized algorithm for when there > is an association and when there isn't. Keep in mind that by the time > that the input-element is inserted, the form-element might have been > moved elsewhere. We likely don't need the association in that case, but > detecting that that has happened sounds tricky. On Tue, 6 Aug 2013, Adam Klein wrote: > > My concrete proposal would be something like this: > > In step 4 of [create an element for the token], add a requirement that > "intended parent" and the "form element pointer" be part of the same > "home subtree" [...] I think this works... there's some dodginess around how elements are inserted in the AAA, but I think it works there as well. (The 'reset the form owner' algorithm can't associate cross-subtree; only the parser can do this. So it's just the parser that needs fixing.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Mon Sep 16 10:40:22 2013 From: ian at hixie.ch (Ian Hickson) Date: Mon, 16 Sep 2013 17:40:22 +0000 (UTC) Subject: [whatwg] Clipping text in in canvas In-Reply-To: <CAA0H+QTT47mzfyzjiRTS+A2W96THOHpLd8rGHzUW8DDb5Z=QGA@mail.gmail.com> References: <CAA0H+QTT47mzfyzjiRTS+A2W96THOHpLd8rGHzUW8DDb5Z=QGA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309161739360.12210@ps20323.dreamhostps.com> On Sun, 15 Sep 2013, Jasper St. Pierre wrote: > > The canvas specification maintains: > > These shapes are painted without affecting the current path, and are > subject to shadow effects, global alpha, the clipping region, and global > composition operators. [0] > > But no browsers I tested actually implement the "clipping region" part. > Should this be removed for backwards compatibility reasons? Should we > introduce a new method of clipping text be introduced, or should we just > require users who want to draw clipped text to draw to a scratch canvas > and use drawImage to copy the pixels? [0] > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#drawing-text-to-the-bitmap Do you have a test case demonstrating the problem you describe? (Note that browsers not following the spec is usually not resolved by adding another feature that does the same thing, since there's no reason to believe they're any more likely to follow that spec either.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jstpierre at mecheye.net Mon Sep 16 11:03:59 2013 From: jstpierre at mecheye.net (Jasper St. Pierre) Date: Mon, 16 Sep 2013 14:03:59 -0400 Subject: [whatwg] Clipping text in in canvas In-Reply-To: <alpine.DEB.2.00.1309161739360.12210@ps20323.dreamhostps.com> References: <CAA0H+QTT47mzfyzjiRTS+A2W96THOHpLd8rGHzUW8DDb5Z=QGA@mail.gmail.com> <alpine.DEB.2.00.1309161739360.12210@ps20323.dreamhostps.com> Message-ID: <CAA0H+QR4mLj3uoauifgKnELp0d-BDh9AWZP2B_fKGPno7R3ZOQ@mail.gmail.com> Sorry for the noise, my code just had a bug (surprise, surprise). It was significantly more complicated than this, but the core of the bug was: ctx.save(); ctx.rect(0, 0, 100, 100); ctx.fill(); ctx.restore(); ctx.save(); ctx.rect(30, 0, 100, 100); ctx.clip(); ctx.fillText(); ctx.restore(); But I forgot to reset the path before the clip(), meaning that the clip did nothing at all. A lack of standard test cases for <canvas> clipping behavior, a StackOverflow answer [0], and no way to reliably debug this sort of issue (I couldn't find any way to get or dump the current path on the context) made me think that the browser behavior was incompatible with the spec. As penance, I'll find some time today to contribute some tests to the <canvas> test suite. [0] http://stackoverflow.com/questions/7307430/html-canvas-clipping-and-text On Mon, Sep 16, 2013 at 1:40 PM, Ian Hickson <ian at hixie.ch> wrote: > On Sun, 15 Sep 2013, Jasper St. Pierre wrote: > > > > The canvas specification maintains: > > > > These shapes are painted without affecting the current path, and are > > subject to shadow effects, global alpha, the clipping region, and global > > composition operators. [0] > > > > But no browsers I tested actually implement the "clipping region" part. > > Should this be removed for backwards compatibility reasons? Should we > > introduce a new method of clipping text be introduced, or should we just > > require users who want to draw clipped text to draw to a scratch canvas > > and use drawImage to copy the pixels? [0] > > > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#drawing-text-to-the-bitmap > > Do you have a test case demonstrating the problem you describe? > > (Note that browsers not following the spec is usually not resolved by > adding another feature that does the same thing, since there's no reason > to believe they're any more likely to follow that spec either.) > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > -- Jasper From ian at hixie.ch Mon Sep 16 15:03:20 2013 From: ian at hixie.ch (Ian Hickson) Date: Mon, 16 Sep 2013 22:03:20 +0000 (UTC) Subject: [whatwg] HTML: A DOM attribute that returns the language of a node In-Reply-To: <907E9FE4-CD47-4C12-B563-3F0AB7EC2118@apple.com> References: <2316EE6495904AB79C77E28AC9B9ADC7@PeterPC> <alpine.DEB.2.00.1307121947450.15729@ps20323.dreamhostps.com> <771E4287303644F88F4C46B69DE613B8@PeterPC> <alpine.DEB.2.00.1307131538570.31051@ps20323.dreamhostps.com> <CADP2=hpPxR+tmbpuYPfNZLLucPY1Jmz1z2CepEPdzuWm+pzrpQ@mail.gmail.com> <alpine.DEB.2.00.1307161824330.31051@ps20323.dreamhostps.com> <56BE589E-9F87-4877-BA60-7410CD6B9FA6@apple.com> <alpine.DEB.2.00.1307261816520.27623@ps20323.dreamhostps.com> <907E9FE4-CD47-4C12-B563-3F0AB7EC2118@apple.com> Message-ID: <alpine.DEB.2.00.1309162159380.12199@ps20323.dreamhostps.com> On Thu, 1 Aug 2013, Ryosuke Niwa wrote: > > > > Are you saying that for HTML contenteditable-based editors that want > > to support drag-and-drop editing, they need to be able to annotate the > > outgoing HTML fragment with the effective language so that when it's > > embedded somewhere, the right fonts get used? > > Yes, but not just for drag and drop. Sure, also for copy-and-paste, etc. The point is that browsers need to provide this for at least some of the cases. > > This seems like something that browsers should just do automatically > > for copy-and-paste and drag-and-drop, I wouldn't want to require that > > every contenteditable-based editor have to reimplement this. That > > seems like a lot of redundant work, and in particular, seems to be > > work that most editor implementors would forget. If the browsers just > > did the annotation automatically, then this would work even in editors > > whose implementors didn't worry about i18n. > > How are browsers supposed to do this if the author was simply using > innerHTML? How would an author use innerHTML here? I agree that there's a use case for providing language information, my point is just that this use case seems to need more than just that: it also needs that browsers add language annotations during drag-and-drop and copy-and-paste, at least. Is there anything else that it needs? Will putting language information on drag-and-drop or copy/paste content have any Web compat impact? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Mon Sep 16 15:05:48 2013 From: ian at hixie.ch (Ian Hickson) Date: Mon, 16 Sep 2013 22:05:48 +0000 (UTC) Subject: [whatwg] HTML: A DOM attribute that returns the language of a node In-Reply-To: <51FBAFDE.3070102@cs.tut.fi> References: <2316EE6495904AB79C77E28AC9B9ADC7@PeterPC> <alpine.DEB.2.00.1307121947450.15729@ps20323.dreamhostps.com> <771E4287303644F88F4C46B69DE613B8@PeterPC> <alpine.DEB.2.00.1307131538570.31051@ps20323.dreamhostps.com> <CADP2=hpPxR+tmbpuYPfNZLLucPY1Jmz1z2CepEPdzuWm+pzrpQ@mail.gmail.com> <alpine.DEB.2.00.1307161824330.31051@ps20323.dreamhostps.com> <56BE589E-9F87-4877-BA60-7410CD6B9FA6@apple.com> <alpine.DEB.2.00.1307261816520.27623@ps20323.dreamhostps.com> <907E9FE4-CD47-4C12-B563-3F0AB7EC2118@apple.com> <51FBAFDE.3070102@cs.tut.fi> Message-ID: <alpine.DEB.2.00.1309162203330.12199@ps20323.dreamhostps.com> On Fri, 2 Aug 2013, Jukka K. Korpela wrote: > 2013-08-02 2:43, Ryosuke Niwa wrote: > > > > > > Are you saying that for HTML contenteditable-based editors that want > > > to support drag-and-drop editing, they need to be able to annotate > > > the outgoing HTML fragment with the effective language so that when > > > it's embedded somewhere, the right fonts get used? > > > > Yes, but not just for drag and drop. > > This would mean that the editor would have to guess the language from > the text or ask the user to specify it. Well presumably just getting the language out of the document would be a good first step. > This is not as unrealistic as it may first seem. Microsoft Word does > such things [...] Sure, there's plenty of examples of language identification. > But regarding the effect of language markup on fonts, the effect is > limited to situations where the font is not specified in a style sheet. Yes. That's a case we should probably make sure we handle. > So it could be added, well, just because there is no good reason not to. There's always reasons not to add something: http://wiki.whatwg.org/wiki/FAQ#Where.27s_the_harm_in_adding.E2.80.94 -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From poccil14 at gmail.com Mon Sep 16 17:38:47 2013 From: poccil14 at gmail.com (Peter Occil) Date: Mon, 16 Sep 2013 20:38:47 -0400 Subject: [whatwg] HTML: A DOM attribute that returns the language of a node In-Reply-To: <alpine.DEB.2.00.1309162203330.12199@ps20323.dreamhostps.com> References: <2316EE6495904AB79C77E28AC9B9ADC7@PeterPC><alpine.DEB.2.00.1307121947450.15729@ps20323.dreamhostps.com><771E4287303644F88F4C46B69DE613B8@PeterPC><alpine.DEB.2.00.1307131538570.31051@ps20323.dreamhostps.com><CADP2=hpPxR+tmbpuYPfNZLLucPY1Jmz1z2CepEPdzuWm+pzrpQ@mail.gmail.com><alpine.DEB.2.00.1307161824330.31051@ps20323.dreamhostps.com><56BE589E-9F87-4877-BA60-7410CD6B9FA6@apple.com><alpine.DEB.2.00.1307261816520.27623@ps20323.dreamhostps.com><907E9FE4-CD47-4C12-B563-3F0AB7EC2118@apple.com><51FBAFDE.3070102@cs.tut.fi> <alpine.DEB.2.00.1309162203330.12199@ps20323.dreamhostps.com> Message-ID: <85C7E940207C4AF192E032DB0C4EB48A@PeterPC> Apparently, the use cases I mentioned before have not been discussed yet: " - Localization of form controls in languages where browser support is lacking, such as some minor languages. - Localization of HTML elements, especially date formatting of span and div elements in the page's default language, see especially [1]. " You said these use cases were valid; how do you think so? --Peter [1]: http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#input-impl-notes -----Original Message----- From: Ian Hickson Sent: Monday, September 16, 2013 6:05 PM To: Jukka K. Korpela Cc: whatwg at lists.whatwg.org Subject: Re: [whatwg] HTML: A DOM attribute that returns the language of a node On Fri, 2 Aug 2013, Jukka K. Korpela wrote: > 2013-08-02 2:43, Ryosuke Niwa wrote: > > > > > > Are you saying that for HTML contenteditable-based editors that want > > > to support drag-and-drop editing, they need to be able to annotate > > > the outgoing HTML fragment with the effective language so that when > > > it's embedded somewhere, the right fonts get used? > > > > Yes, but not just for drag and drop. > > This would mean that the editor would have to guess the language from > the text or ask the user to specify it. Well presumably just getting the language out of the document would be a good first step. > This is not as unrealistic as it may first seem. Microsoft Word does > such things [...] Sure, there's plenty of examples of language identification. > But regarding the effect of language markup on fonts, the effect is > limited to situations where the font is not specified in a style sheet. Yes. That's a case we should probably make sure we handle. > So it could be added, well, just because there is no good reason not to. There's always reasons not to add something: http://wiki.whatwg.org/wiki/FAQ#Where.27s_the_harm_in_adding.E2.80.94 -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Mon Sep 16 17:43:20 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 17 Sep 2013 00:43:20 +0000 (UTC) Subject: [whatwg] inputmode feedback In-Reply-To: <83D6DB4D-DC3B-483D-9FD9-62D182D20F1A@apple.com> References: <511BE988.7070208@lamouri.fr> <5130C9A1.2020200@lamouri.fr> <Pine.LNX.4.64.1306062055150.2772@ps20323.dreamhostps.com> <CA+c2ei_fzXqAs1=mCpiwn+A0+yEvRjf5d9iLFFbVzFQgBaEQiw@mail.gmail.com> <CADP2=hrO1+5n9+M134n+GtAh=w32V0HpDM+wjrrGe=arzP+WDQ@mail.gmail.com> <CAAEV3pkY9CuVebq8HdqYWXB_qY=19RMoeXNfdw7Pv0NTmCYUog@mail.gmail.com> <83D6DB4D-DC3B-483D-9FD9-62D182D20F1A@apple.com> Message-ID: <alpine.DEB.2.00.1309170032060.12199@ps20323.dreamhostps.com> On Tue, 13 Aug 2013, Yoichi Osato wrote: > > I have questions about some inputmode attributes. > In the desktop case, full-width-latin, kana and katakana look to intend > user local IME. Right? I'm not sure what this means exactly. > I think whether IME is on or off is very important to user because some > IME have state and show some window to input character. It is much > different from alphabetic direct keyboard input. See > https://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html#composer-section > At least Chinese and Korean IME have state. inputmode="" isn't intended to directly decide how the UI works, e.g. whether an IME, or what kind of IME, is provided. However, it is intended to let browsers make the decision on what kind of IME to provide. > In this point we should add attributes corresponding to chinese and korean. > I don't know whether there are any other such a IME but I think many non > English native people input in alphabet or hir/her native language. I would be very happy to add such things, but I don't know what the needs are in those languages. I've been waiting for someone to elaborate on what exactly is needed. > So should we add "native" attribute? When would you use it? On Tue, 13 Aug 2013, Ryosuke Niwa wrote: > > I think we need to separate the use case for controlling IME mode and > hinting UA as to which type of text/script will be entered as Mounir > suggested in the original email. I don't understand what the difference is. > And I agree that we need to address Chinese and Korean IME use cases if > we're adding Japanese IME use cases. Also, IME behavior is very > different depending on whether you're using pinyin or zhuyin/bopomofo in > Chinese IME so we might need to differentiate those two as well. Ok. What are the kinds of input tha Chinese and Korean Web sites need? > On Mar 1, 2013, at 7:30 AM, Mounir Lamouri <mounir at lamouri.fr> wrote: > > On 15/02/13 08:28, Takayoshi Kochi (?? ??) wrote: > >> That said, even though authors of web apps may want to force the IME > >> mode or its script mode for user's sake, it may cause user's > >> confusion as they are so accustomed to change mode manually where > >> such mode is required. So if a web app sets some mode, the user may > >> toggle it back to unintended mode and get frustrated. > > > > I tend to agree. In one hand, I believe that users might get irritated > > if they can't control the inputmode but in another hand, forcing it > > might fulfil use cases where authors use Javascript to force a user to > > type in uppercase for example (that happens in a few forms). > > On the other hand, inputmode is supposedly only a hint, right? It > doesn't affect the validation state of input elements. Given that, how > does it address such a use case? I don't understand the concern here. The attribute is indeed a hint; it doesn't tell the browser what UI to show, only what the page thinks the user will want to enter. > > On 21/02/13 01:14, Ryosuke Niwa wrote: > >> On Wed, Feb 13, 2013 at 11:29 AM, Mounir Lamouri <mounir at lamouri.fr> > >> wrote: > >>> To conclude, Mozilla is interested in implementing this set of > >>> keywords: verbatim, text, name, prose and digit (or numeric). > >> > >> Why is name not an input type? > >> > >> How does one decide whether a given semantics should be introduced as > >> a type or a mode? > > > > I tend to prefer <input type='text' inputmode='name'> over <input > > type='name'> because <input type='name'>, for the moment would be > > nothing else but a text field with an address book autocompletion. I > > would prefer to have 'tel' that way instead of having it a type FWIW. > > But isn't type=email also a text field with autocompletion, no? I agree > that the UI might be similar on desktop browsers, but it could be > completely different on mobile operating systems where UA could show a > custom keyboard suitable to type in human names as opposed to arbitrary > text. > > How is that different from type=email where UA is supposed to assist > user type in an email address? Yeah, I don't really understand the suggestion above. > It's not like we do a rigorous pattern matching to validate email > addresses either. Actually, we do, or at least the spec does. -- Ian Hickson U+1047E )?._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. ? _? ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Mon Sep 16 17:50:33 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 17 Sep 2013 00:50:33 +0000 (UTC) Subject: [whatwg] HTML: A DOM attribute that returns the language of a node In-Reply-To: <85C7E940207C4AF192E032DB0C4EB48A@PeterPC> References: <2316EE6495904AB79C77E28AC9B9ADC7@PeterPC><alpine.DEB.2.00.1307121947450.15729@ps20323.dreamhostps.com><771E4287303644F88F4C46B69DE613B8@PeterPC><alpine.DEB.2.00.1307131538570.31051@ps20323.dreamhostps.com><CADP2=hpPxR+tmbpuYPfNZLLucPY1Jmz1z2CepEPdzuWm+pzrpQ@mail.gmail.com><alpine.DEB.2.00.1307161824330.31051@ps20323.dreamhostps.com><56BE589E-9F87-4877-BA60-7410CD6B9FA6@apple.com><alpine.DEB.2.00.1307261816520.27623@ps20323.dreamhostps.com><907E9FE4-CD47-4C12-B563-3F0AB7EC2118@apple.com><51FBAFDE.3070102@cs.tut.fi> <alpine.DEB.2.00.1309162203330.12199@ps20323.dreamhostps.com> <85C7E940207C4AF192E032DB0C4EB48A@PeterPC> Message-ID: <alpine.DEB.2.00.1309170046250.12210@ps20323.dreamhostps.com> On Mon, 16 Sep 2013, Peter Occil wrote: > > - Localization of form controls in languages where browser support is > lacking, such as some minor languages. > > - Localization of HTML elements, especially date formatting of span and > div elements in the page's default language [...] > > You said these use cases were valid; how do you think so? I mean these are things that users want and that authors have to do. Your e-mail is still on my list of e-mails to deal with. (Specifically, it's in the pile of e-mail relating to new features.) It hasn't been forgotten, don't worry. :-) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 17 10:06:32 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 17 Sep 2013 17:06:32 +0000 (UTC) Subject: [whatwg] Canvas - Should setLineDash be a nullable sequence? In-Reply-To: <CAA5isUZHQQ+zf2CzNOG6NL96c-RkiqF_z0aFjx82_Lh=Xb0hhg@mail.gmail.com> References: <CAA5isUZHQQ+zf2CzNOG6NL96c-RkiqF_z0aFjx82_Lh=Xb0hhg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309171657450.12199@ps20323.dreamhostps.com> On Tue, 20 Aug 2013, Simon Sarris wrote: > > This is minor, but it did recently break formerly-working functionality > in Google Chrome, so maybe its worth a discussion. > > The specification reads: > > void setLineDash(sequence<unrestricted double> segments); // default empty > sequence<unrestricted double> getLineDash(); > > This means we *cannot* use: > > ctx.setLineDash(null); > > In Chrome 28 and previous (for at least 6 months) null was an allowed > value, but in Chrome 30 (at least) it switched to throwing a TypeError. I couldn't find any currently-shipping browsers that supported this, so it seems unlikely that there'd be much legacy content that depends on it. (Not saying there's none, just that it's limited in scope.) Thus, the compatibility issue here is not the only thing we should consider. (It's still a factor, just not an automatic win, as it might otherwise be.) There's certainly an advantage to failing if the input is "null" here -- it's more likely to catch underlying errors quicker. Instead of just getting a solid line where you expected a dashed one, you get an error with a precise line number from which to start your search. > In any case, I think it would be better if setLineDash was defined in > the spec as a nullable sequence, so that when setting it back to nothing > to return to normal not-dashed path stroking (which could happen > thousands of times in a an animation frame) less stuff gets allocated in > the draw loop. A literal empty array can get optimised out by compilers, so it really shouldn't be that big a deal on the long run. > I think part of the issue is that setLineDash does two things. It sets > the dashing properties, but it also acts as the only way to > enable/disable dashing, I think that null seems appropriate. All lines are dashed, it's just that some have an infinitely long dash with no space. Don't look at it as enabling/disabling dashing. :-) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 17 10:20:38 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 17 Sep 2013 17:20:38 +0000 (UTC) Subject: [whatwg] Path API feedback In-Reply-To: <CAGN7qDDXqyZt2gkmttoUps3qgEUiesBdpGmhotUhk4Ay6S_PVQ@mail.gmail.com> References: <CAGN7qDATVtL08NLKvYsL+WVzGYn5fy3WxdQLQYqpB55NuhyL3g@mail.gmail.com> <Pine.LNX.4.64.1304260027360.3512@ps20323.dreamhostps.com> <CAGN7qDBcC7aPD1BcuDHbvMavfM3ez0CufFWgaLHcaPHBsuoNrA@mail.gmail.com> <alpine.DEB.2.00.1308202232540.27209@ps20323.dreamhostps.com> <CAGN7qDDXqyZt2gkmttoUps3qgEUiesBdpGmhotUhk4Ay6S_PVQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309171709350.12199@ps20323.dreamhostps.com> On Tue, 20 Aug 2013, Rik Cabanier wrote: > > On Sat, 23 Mar 2013, Rik Cabanier wrote: > > > > > > The current path APIs suffer from conflating path segments and > > > geometry. To fix this, I proposed to modify the API so path just > > > describe the path segments. > > > > > > http://blogs.adobe.com/webplatform/2013/01/31/revised-canvas-paths/ > > > > I disagree with the premise of this post -- it's not the case that you > > never want to add segments. It is in fact quite common to add segments > > to a path -- that's what constructing a path is. > > I disagree. How many times does an author want to add segments to an > existing path? Pretty much every time they create a path with more than one segment. > Let's say an application stores a circle in a path and now want to draw > a rectangle too. You propose that the application just appends the > rectangle. No, not necessarily. It depends on what they want to do. If they want a single path that is constructed of a circle and a rectangle in the same way that it would be if they did: x.beginPath(); x.arc(...); x.rect(...); x.fill(); ...then yeah, they should just append the rectangle. But if they want the same effect as: x.beginPath(); x.arc(); x.fill(); x.rect(...); x.fill(); ...then they should not just append them, since as you say, it won't work. > > Also, it's not at all clear to me that there's really a distinction > > between a "shape" and a "path". They're really the same thing -- sets > > of path segments. > > No. A shape is no longer a group of line segments. You *could* convert > it to such a thing but that requires a bunch of complex math (ie > http://www.youtube.com/watch?v=OmfliNQsk88) For now, I'm not proposing > to add that to the canvas API. Once the Path API is implemented, we can add any number of features, such as adding a path so as to form the union of both paths, adding a path so as to form the intersection of both paths, etc. > The resulting 'path' will once again have no winding. This is very > confusing and extremely hard to implement I don't understand why it's hard to implement. It's just the non-Path API, but stored away for future use. > > Right now we have two options (ignoring the text parts of the path > > API): concatenating path segments, and concatenating path segments > > after having first outlined one of them. > > FYI the outlining algorithm is also not correct. It suffers from the > same issue that strokes are segments. Can you elaborate? (I think I may have asked already, in which case, my apologies for asking again.) > > On the long run I think it would make sense to add other methods, e.g. > > one combining two or more paths together such that the resulting path > > would outline the union of the "insides" of the provided paths, or the > > intersections, or whatnot. > > I think that would be much more confusing and difficult to implement. I > didn't come up with this on my own :-). This is done by graphics > libraries that offers path manipulation support. For instance: skia: > http://skia-autogen.googlecode.com/svn/docs/html/classSkPathEffect.html > lib2geom: http://wiki.inkscape.org/wiki/index.php/WorkingWith2GeomFAQ > Direct2D: > http://msdn.microsoft.com/en-us/library/windows/desktop/dd756653(v=vs.85).aspx#path_geometries I'm confused. Are these examples of how to make confusing APIs, or examples of how the current API is confusing? Those look really, really complicated relative to what Canvas looks like today. On Thu, 5 Sep 2013, Rik Cabanier wrote: > > The problem happens when you call fill or stroke multiple times. > [...] > Now I want to create a region that covers what was drawn. > [...] > 'p' won't describe the same area as what was filled. Sure, for that you need a new API function, e.g. union, which as I've mentioned before, I think would be a logical addition to the API in due course. But I don't think we should add features too quickly, lest we get too far ahead of browsers. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 17 10:30:38 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 17 Sep 2013 17:30:38 +0000 (UTC) Subject: [whatwg] canvas 2d's ellipse In-Reply-To: <CAGN7qDBmpczx1j=hhzWdWXTwPCDj+Ek9+vja56Yi6KsKP5SAkw@mail.gmail.com> References: <3688893053903968472@unknownmsgid> <alpine.DEB.2.00.1308202236340.27209@ps20323.dreamhostps.com> <CAGN7qDBmpczx1j=hhzWdWXTwPCDj+Ek9+vja56Yi6KsKP5SAkw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309171721150.12199@ps20323.dreamhostps.com> On Tue, 20 Aug 2013, Tab Atkins Jr. wrote: > On Tue, Aug 20, 2013 at 3:46 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Tue, 30 Apr 2013, Rik Cabanier wrote: > >> I think the API should look like this: > >> > >> void ellipse(unrestricted double x, optional unrestricted double y, > >> unrestricted double radiusX, optional unrestricted double radiusY, > >> optional unrestricted double rotation, optional unrestricted double > >> startAngle, optional unrestricted double endAngle, optional boolean > >> anticlockwise); > >> > >> with the following behavior: > >> - if radiusY is omitted, it's the same as radiusX > >> - if rotation is omitted, it's equal to 0 > >> - if startAngle is omitted, it's equal to 0 > >> - if endAngle is omitted, it's equal to 0 > >> - if anticlockwise is omitted, it's equal to false > > > > We could do this, sure. How much do people want something like this? > > Does anyone else think it's a good idea? > > I can tell you that specifying all of the arguments in SVG's ellipse > path command is rather annoying. Having good defaults would be a good > thing. The problem here is since the arguments are positional, it doesn't let you just omit the ones you want to omit, only the last few that you don't need. If implementors want to do it, I'm happy to spec it, but it doesn't seem to be something many people feel strongly about... On Tue, 20 Aug 2013, Rik Cabanier wrote: > > > > > > So, if you want to draw a simple circle, you have to supply 8 > > > parameters, even though only 3 are needed. > > > > If you just want a circle, you can use arc(). > > OK. What if you want to draw a simple ellipse? What's a "simple" ellipse? > Here's an example of the issue: http://jsfiddle.net/2N85k/2/ > Because the stroke is using square caps, you can't draw a circle or an > ellipse unless you do a closePath. Yes? Why is this a problem? > Chrome is doing an implicit closePath if start and end angle meet, but > none of the other browsers do. Then Chrome is buggy. Nothing in the spec says to implicitly close the path. > However the spec should be clearer on what happens if the arc is 2 ? for > arc and ellipse. > Chrome believes that case should have a 'closePath' which seems reasonable. > Maybe someone on that team can tell us if this was intentional. I'm tracking this issue here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23050 I don't really understand what's ambiguous about the spec. Please do elaborate on this in the bug. > > On Tue, 30 Apr 2013, Rik Cabanier wrote: > > > > > > I think the exception on negative radius should also be removed. > > > > What would a negative radius mean? > > Either treat it as zero, or use the absolute value. Avoiding exceptions > will make web apps more robust. Or more buggy, because authors won't notice their errors. I'm not a fan of "sweep it under the carpet" bug handling, personally. It drives me crazy that JavaScript has no type checking, no argument checking, etc. So many bugs that should be caught at compile time, or at least at runtime when the code is reached, are instead caught only after careful testing. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jackalmage at gmail.com Tue Sep 17 11:16:20 2013 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Tue, 17 Sep 2013 11:16:20 -0700 Subject: [whatwg] canvas 2d's ellipse In-Reply-To: <alpine.DEB.2.00.1309171721150.12199@ps20323.dreamhostps.com> References: <3688893053903968472@unknownmsgid> <alpine.DEB.2.00.1308202236340.27209@ps20323.dreamhostps.com> <CAGN7qDBmpczx1j=hhzWdWXTwPCDj+Ek9+vja56Yi6KsKP5SAkw@mail.gmail.com> <alpine.DEB.2.00.1309171721150.12199@ps20323.dreamhostps.com> Message-ID: <CAAWBYDDUC8b7tWs4wVJPRorxTiSWN9Yi1-BS5k+RVnEXnGHKRw@mail.gmail.com> On Tue, Sep 17, 2013 at 10:30 AM, Ian Hickson <ian at hixie.ch> wrote: >> > On Tue, 30 Apr 2013, Rik Cabanier wrote: >> > > >> > > I think the exception on negative radius should also be removed. >> > >> > What would a negative radius mean? >> >> Either treat it as zero, or use the absolute value. Avoiding exceptions >> will make web apps more robust. > > Or more buggy, because authors won't notice their errors. > > I'm not a fan of "sweep it under the carpet" bug handling, personally. It > drives me crazy that JavaScript has no type checking, no argument > checking, etc. So many bugs that should be caught at compile time, or at > least at runtime when the code is reached, are instead caught only after > careful testing. "Runtime when the code is reached" often actually means "Whoops! Now the entire app's broken because I forgot to handle a silly edge-case.". When there's an easy and obvious recovery strategy, it's often much friendlier to authors to take it rather than force them to handle errors. This is fairly standard practice in DOM and ES design. ~TJ From ian at hixie.ch Tue Sep 17 11:31:58 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 17 Sep 2013 18:31:58 +0000 (UTC) Subject: [whatwg] canvas 2d's ellipse In-Reply-To: <CAAWBYDDUC8b7tWs4wVJPRorxTiSWN9Yi1-BS5k+RVnEXnGHKRw@mail.gmail.com> References: <3688893053903968472@unknownmsgid> <alpine.DEB.2.00.1308202236340.27209@ps20323.dreamhostps.com> <CAGN7qDBmpczx1j=hhzWdWXTwPCDj+Ek9+vja56Yi6KsKP5SAkw@mail.gmail.com> <alpine.DEB.2.00.1309171721150.12199@ps20323.dreamhostps.com> <CAAWBYDDUC8b7tWs4wVJPRorxTiSWN9Yi1-BS5k+RVnEXnGHKRw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309171829060.12210@ps20323.dreamhostps.com> On Tue, 17 Sep 2013, Tab Atkins Jr. wrote: > > > > I'm not a fan of "sweep it under the carpet" bug handling, personally. > > It drives me crazy that JavaScript has no type checking, no argument > > checking, etc. So many bugs that should be caught at compile time, or > > at least at runtime when the code is reached, are instead caught only > > after careful testing. > > "Runtime when the code is reached" often actually means "Whoops! Now the > entire app's broken because I forgot to handle a silly edge-case.". > When there's an easy and obvious recovery strategy, it's often much > friendlier to authors to take it rather than force them to handle > errors. Usually in these cases the entire app is probably still broken -- maybe with data corruption, even, or with confusingly bad behaviour. The only difference is that you have no idea where to begin looking. It wouldn't be so bad if we had a way to have errors that allowed the code to continue anyway, the way we do e.g. in HTML parsing, where you can easily run a validator to find out what you've done wrong, while still having the errors swept under the carpet on the user's end. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From cabanier at gmail.com Tue Sep 17 12:55:06 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 17 Sep 2013 12:55:06 -0700 Subject: [whatwg] canvas 2d's ellipse In-Reply-To: <alpine.DEB.2.00.1309171829060.12210@ps20323.dreamhostps.com> References: <3688893053903968472@unknownmsgid> <alpine.DEB.2.00.1308202236340.27209@ps20323.dreamhostps.com> <CAGN7qDBmpczx1j=hhzWdWXTwPCDj+Ek9+vja56Yi6KsKP5SAkw@mail.gmail.com> <alpine.DEB.2.00.1309171721150.12199@ps20323.dreamhostps.com> <CAAWBYDDUC8b7tWs4wVJPRorxTiSWN9Yi1-BS5k+RVnEXnGHKRw@mail.gmail.com> <alpine.DEB.2.00.1309171829060.12210@ps20323.dreamhostps.com> Message-ID: <CAGN7qDAvgag3GeqyNBm3xdR5cOcxQqn3C5pK_ng+r6HheDaFfA@mail.gmail.com> On Tue, Sep 17, 2013 at 11:31 AM, Ian Hickson <ian at hixie.ch> wrote: > On Tue, 17 Sep 2013, Tab Atkins Jr. wrote: > > > > > > I'm not a fan of "sweep it under the carpet" bug handling, personally. > > > It drives me crazy that JavaScript has no type checking, no argument > > > checking, etc. So many bugs that should be caught at compile time, or > > > at least at runtime when the code is reached, are instead caught only > > > after careful testing. > > > > "Runtime when the code is reached" often actually means "Whoops! Now the > > entire app's broken because I forgot to handle a silly edge-case.". > > When there's an easy and obvious recovery strategy, it's often much > > friendlier to authors to take it rather than force them to handle > > errors. > > Usually in these cases the entire app is probably still broken -- maybe > with data corruption, even, or with confusingly bad behaviour. The only > difference is that you have no idea where to begin looking. > Ok, so what if *some* applications would be horribly broken. *Others* will still stumble along or work perfectly fine. I'd rather have that, than a completely broken page. > > It wouldn't be so bad if we had a way to have errors that allowed the code > to continue anyway, the way we do e.g. in HTML parsing, where you can > easily run a validator to find out what you've done wrong, while still > having the errors swept under the carpet on the user's end. The browser could log something in the console output so the developer can debug it. Maybe the spec could say that the operation is in error but that processing will continue as if the bad call didn't happen. From ian at hixie.ch Tue Sep 17 13:27:24 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 17 Sep 2013 20:27:24 +0000 (UTC) Subject: [whatwg] canvas 2d's ellipse In-Reply-To: <CAGN7qDAvgag3GeqyNBm3xdR5cOcxQqn3C5pK_ng+r6HheDaFfA@mail.gmail.com> References: <3688893053903968472@unknownmsgid> <alpine.DEB.2.00.1308202236340.27209@ps20323.dreamhostps.com> <CAGN7qDBmpczx1j=hhzWdWXTwPCDj+Ek9+vja56Yi6KsKP5SAkw@mail.gmail.com> <alpine.DEB.2.00.1309171721150.12199@ps20323.dreamhostps.com> <CAAWBYDDUC8b7tWs4wVJPRorxTiSWN9Yi1-BS5k+RVnEXnGHKRw@mail.gmail.com> <alpine.DEB.2.00.1309171829060.12210@ps20323.dreamhostps.com> <CAGN7qDAvgag3GeqyNBm3xdR5cOcxQqn3C5pK_ng+r6HheDaFfA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309172020130.12210@ps20323.dreamhostps.com> On Tue, 17 Sep 2013, Rik Cabanier wrote: > On Tue, Sep 17, 2013 at 11:31 AM, Ian Hickson <ian at hixie.ch> wrote: > > On Tue, 17 Sep 2013, Tab Atkins Jr. wrote: > > > > > > > > I'm not a fan of "sweep it under the carpet" bug handling, > > > > personally. It drives me crazy that JavaScript has no type > > > > checking, no argument checking, etc. So many bugs that should be > > > > caught at compile time, or at least at runtime when the code is > > > > reached, are instead caught only after careful testing. > > > > > > "Runtime when the code is reached" often actually means "Whoops! Now > > > the entire app's broken because I forgot to handle a silly > > > edge-case.". When there's an easy and obvious recovery strategy, > > > it's often much friendlier to authors to take it rather than force > > > them to handle errors. > > > > Usually in these cases the entire app is probably still broken -- > > maybe with data corruption, even, or with confusingly bad behaviour. > > The only difference is that you have no idea where to begin looking. > > Ok, so what if *some* applications would be horribly broken. *Others* > will still stumble along or work perfectly fine. I'd rather have that, > than a completely broken page. Dramatically simplifying the situation here, we're saying that the available options are: A: All buggy applications fail to compile, because of static checking. Cost to fix the bugs is low. B: All buggy applications break entirely when edge cases are hit. Cost to fix the bugs is moderate. C: Some buggy applications break entirely when edge cases are hit. Some buggy applications have data corruption! Some buggy applications have merely graphical artefacts. Cost to fix the bugs is high. I think option A is vastly superior, but since that's not an option, option B is preferable to option C. In reality, I don't think it's true that the Web always goes with C. If it did, there'd never be exceptions thrown by APIs, and exceptions are thrown all the time by APIs. Indeed, if it were the case that we had a philosophy of going with "muddling along" where possible, JavaScript wouldn't have syntax errors, or, much like CSS, it would have rules for recovering from them and would simply ignore syntactically invalid constructs. We don't do that. Instead, we chose the middle ground B most of the time. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From cabanier at gmail.com Tue Sep 17 14:32:03 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 17 Sep 2013 14:32:03 -0700 Subject: [whatwg] canvas 2d's ellipse In-Reply-To: <alpine.DEB.2.00.1309172020130.12210@ps20323.dreamhostps.com> References: <3688893053903968472@unknownmsgid> <alpine.DEB.2.00.1308202236340.27209@ps20323.dreamhostps.com> <CAGN7qDBmpczx1j=hhzWdWXTwPCDj+Ek9+vja56Yi6KsKP5SAkw@mail.gmail.com> <alpine.DEB.2.00.1309171721150.12199@ps20323.dreamhostps.com> <CAAWBYDDUC8b7tWs4wVJPRorxTiSWN9Yi1-BS5k+RVnEXnGHKRw@mail.gmail.com> <alpine.DEB.2.00.1309171829060.12210@ps20323.dreamhostps.com> <CAGN7qDAvgag3GeqyNBm3xdR5cOcxQqn3C5pK_ng+r6HheDaFfA@mail.gmail.com> <alpine.DEB.2.00.1309172020130.12210@ps20323.dreamhostps.com> Message-ID: <CAGN7qDCY5sCBY31fEOWYUT-ZX4CC2BRSC=HscXefYQk3Qhd1bg@mail.gmail.com> On Tue, Sep 17, 2013 at 1:27 PM, Ian Hickson <ian at hixie.ch> wrote: > On Tue, 17 Sep 2013, Rik Cabanier wrote: > > On Tue, Sep 17, 2013 at 11:31 AM, Ian Hickson <ian at hixie.ch> wrote: > > > On Tue, 17 Sep 2013, Tab Atkins Jr. wrote: > > > > > > > > > > I'm not a fan of "sweep it under the carpet" bug handling, > > > > > personally. It drives me crazy that JavaScript has no type > > > > > checking, no argument checking, etc. So many bugs that should be > > > > > caught at compile time, or at least at runtime when the code is > > > > > reached, are instead caught only after careful testing. > > > > > > > > "Runtime when the code is reached" often actually means "Whoops! Now > > > > the entire app's broken because I forgot to handle a silly > > > > edge-case.". When there's an easy and obvious recovery strategy, > > > > it's often much friendlier to authors to take it rather than force > > > > them to handle errors. > > > > > > Usually in these cases the entire app is probably still broken -- > > > maybe with data corruption, even, or with confusingly bad behaviour. > > > The only difference is that you have no idea where to begin looking. > > > > Ok, so what if *some* applications would be horribly broken. *Others* > > will still stumble along or work perfectly fine. I'd rather have that, > > than a completely broken page. > > Dramatically simplifying the situation here, we're saying that the > available options are: > > A: All buggy applications fail to compile, because of static checking. > Cost to fix the bugs is low. > > B: All buggy applications break entirely when edge cases are hit. > Cost to fix the bugs is moderate. > > C: Some buggy applications break entirely when edge cases are hit. > Some buggy applications have data corruption! > Some buggy applications have merely graphical artefacts. > Cost to fix the bugs is high. > > I think option A is vastly superior, but since that's not an option, > option B is preferable to option C. > You are speaking as a developer, not as a user of a web application. Browser could offer a 'debug' more where they break on bad calls or output messages to the console. Once it's 'released', the runtime should be permissive. > > In reality, I don't think it's true that the Web always goes with C. If it > did, there'd never be exceptions thrown by APIs, and exceptions are thrown > all the time by APIs. Indeed, if it were the case that we had a philosophy > of going with "muddling along" where possible, JavaScript wouldn't have > syntax errors, or, much like CSS, it would have rules for recovering from > them and would simply ignore syntactically invalid constructs. We don't do > that. Instead, we chose the middle ground B most of the time. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > From robert at ocallahan.org Tue Sep 17 14:37:59 2013 From: robert at ocallahan.org (Robert O'Callahan) Date: Wed, 18 Sep 2013 09:37:59 +1200 Subject: [whatwg] canvas 2d's ellipse In-Reply-To: <alpine.DEB.2.00.1309172020130.12210@ps20323.dreamhostps.com> References: <3688893053903968472@unknownmsgid> <alpine.DEB.2.00.1308202236340.27209@ps20323.dreamhostps.com> <CAGN7qDBmpczx1j=hhzWdWXTwPCDj+Ek9+vja56Yi6KsKP5SAkw@mail.gmail.com> <alpine.DEB.2.00.1309171721150.12199@ps20323.dreamhostps.com> <CAAWBYDDUC8b7tWs4wVJPRorxTiSWN9Yi1-BS5k+RVnEXnGHKRw@mail.gmail.com> <alpine.DEB.2.00.1309171829060.12210@ps20323.dreamhostps.com> <CAGN7qDAvgag3GeqyNBm3xdR5cOcxQqn3C5pK_ng+r6HheDaFfA@mail.gmail.com> <alpine.DEB.2.00.1309172020130.12210@ps20323.dreamhostps.com> Message-ID: <CAOp6jLYYMNjrK=TF80Gd6BR_YjRHxZzaULbi-GBSTCh0drefgA@mail.gmail.com> On Wed, Sep 18, 2013 at 8:27 AM, Ian Hickson <ian at hixie.ch> wrote: > A: All buggy applications fail to compile, because of static checking. > Cost to fix the bugs is low. > > B: All buggy applications break entirely when edge cases are hit. > Cost to fix the bugs is moderate. > > C: Some buggy applications break entirely when edge cases are hit. > Some buggy applications have data corruption! > Some buggy applications have merely graphical artefacts. > Cost to fix the bugs is high. > I think our decision to make 2D canvas methods [LenientFloat] (choosing C over B) was a good one because "muddling on through" in the case of a transient singularity that will likely only produce a transient rendering error seems like a good cost-benefit tradeoff. So we need to consider the likely impact of the bug; transient graphical artifacts are relatively low impact. Also I think we should consider whether the bad behavior is deterministic and hence likely to be detected during testing. When it isn't (and can't be made so!), it makes more sense for implementations to be lenient (choose B over C), since then it's more likely the impact of the bug will fall on users as much or more than developers and the cost of fixing the bug is high no matter what we do. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * From robert at ocallahan.org Tue Sep 17 14:38:52 2013 From: robert at ocallahan.org (Robert O'Callahan) Date: Wed, 18 Sep 2013 09:38:52 +1200 Subject: [whatwg] canvas 2d's ellipse In-Reply-To: <CAOp6jLYYMNjrK=TF80Gd6BR_YjRHxZzaULbi-GBSTCh0drefgA@mail.gmail.com> References: <3688893053903968472@unknownmsgid> <alpine.DEB.2.00.1308202236340.27209@ps20323.dreamhostps.com> <CAGN7qDBmpczx1j=hhzWdWXTwPCDj+Ek9+vja56Yi6KsKP5SAkw@mail.gmail.com> <alpine.DEB.2.00.1309171721150.12199@ps20323.dreamhostps.com> <CAAWBYDDUC8b7tWs4wVJPRorxTiSWN9Yi1-BS5k+RVnEXnGHKRw@mail.gmail.com> <alpine.DEB.2.00.1309171829060.12210@ps20323.dreamhostps.com> <CAGN7qDAvgag3GeqyNBm3xdR5cOcxQqn3C5pK_ng+r6HheDaFfA@mail.gmail.com> <alpine.DEB.2.00.1309172020130.12210@ps20323.dreamhostps.com> <CAOp6jLYYMNjrK=TF80Gd6BR_YjRHxZzaULbi-GBSTCh0drefgA@mail.gmail.com> Message-ID: <CAOp6jLb4LWPnUDa0unnhXj4Bo=D8w5yMS_SmyYaDOOVCG55Zdg@mail.gmail.com> On Wed, Sep 18, 2013 at 9:37 AM, Robert O'Callahan <robert at ocallahan.org>wrote: > > (choose B over C) > I meant C over B of course. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * From leon.gilyadov at gmail.com Wed Sep 18 01:14:06 2013 From: leon.gilyadov at gmail.com (Leon Gilyadov) Date: Wed, 18 Sep 2013 10:14:06 +0200 Subject: [whatwg] Proposal: q and qq for document.querySelector and document.querySelectorAll Message-ID: <CAAn7mYbM-f1cXJZEcDVRnxYppTDT+DJ78-cNdwVsA4qMpQ8=Vw@mail.gmail.com> *The problem:* document.querySelector and document.querySelectorAll are long and used a lot. Lines in the code are long. *Proposal:* q('.my-div') will be equal to: document.querySelector('.my-div) qq('.my-div') will be equal to: document.querySelectorAll('.my-div') --Leon Gilyadov. From scott.gonzalez at gmail.com Wed Sep 18 05:10:38 2013 From: scott.gonzalez at gmail.com (=?ISO-8859-1?Q?Scott_Gonz=E1lez?=) Date: Wed, 18 Sep 2013 08:10:38 -0400 Subject: [whatwg] Proposal: q and qq for document.querySelector and document.querySelectorAll In-Reply-To: <CAAn7mYbM-f1cXJZEcDVRnxYppTDT+DJ78-cNdwVsA4qMpQ8=Vw@mail.gmail.com> References: <CAAn7mYbM-f1cXJZEcDVRnxYppTDT+DJ78-cNdwVsA4qMpQ8=Vw@mail.gmail.com> Message-ID: <CAO8i3ifFtFCZTcJoPZgnQs=-82KBva3nz+KHAWE58i5Cor6Qqg@mail.gmail.com> So you're suggesting new globals that are bound to the document? That sounds really bad. Also, there's no reason to suggest an alias to querySelector() when it's much more likely that query() will be used by the majority of developers. On Wed, Sep 18, 2013 at 4:14 AM, Leon Gilyadov <leon.gilyadov at gmail.com>wrote: > *The problem:* > document.querySelector and document.querySelectorAll > are long and used a lot. > > Lines in the code are long. > > *Proposal:* > q('.my-div') > will be equal to: > document.querySelector('.my-div) > > qq('.my-div') > will be equal to: > document.querySelectorAll('.my-div') > > > --Leon Gilyadov. > From niels.keurentjes at omines.com Wed Sep 18 05:18:20 2013 From: niels.keurentjes at omines.com (Niels Keurentjes) Date: Wed, 18 Sep 2013 12:18:20 +0000 Subject: [whatwg] Proposal: q and qq for document.querySelector and document.querySelectorAll In-Reply-To: <CAO8i3ifFtFCZTcJoPZgnQs=-82KBva3nz+KHAWE58i5Cor6Qqg@mail.gmail.com> References: <CAAn7mYbM-f1cXJZEcDVRnxYppTDT+DJ78-cNdwVsA4qMpQ8=Vw@mail.gmail.com> <CAO8i3ifFtFCZTcJoPZgnQs=-82KBva3nz+KHAWE58i5Cor6Qqg@mail.gmail.com> Message-ID: <A212DA0831E8714BB0860F102E8E29DC856D350D@omines-srv-004.omines.corp> The spec should only concern itself with exposing functionality. Practical considerations such as length of code are the responsibility of the developer - if you like to have q and qq aliases you can add them yourself at runtime, that's the whole point of a prototyped language. Common libraries like jQuery, prototype and Mootools expose the behaviour as $ and $$ for exactly the reason given, no reason to impose that on every developer if they choose not to use a library. -----Original Message----- From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Scott Gonz?lez Sent: woensdag 18 september 2013 14:11 To: Leon Gilyadov Cc: whatwg at lists.whatwg.org Subject: Re: [whatwg] Proposal: q and qq for document.querySelector and document.querySelectorAll So you're suggesting new globals that are bound to the document? That sounds really bad. Also, there's no reason to suggest an alias to querySelector() when it's much more likely that query() will be used by the majority of developers. On Wed, Sep 18, 2013 at 4:14 AM, Leon Gilyadov <leon.gilyadov at gmail.com>wrote: > *The problem:* > document.querySelector and document.querySelectorAll are long and used > a lot. > > Lines in the code are long. > > *Proposal:* > q('.my-div') > will be equal to: > document.querySelector('.my-div) > > qq('.my-div') > will be equal to: > document.querySelectorAll('.my-div') > > > --Leon Gilyadov. > From james.m.greene at gmail.com Wed Sep 18 07:18:05 2013 From: james.m.greene at gmail.com (James Greene) Date: Wed, 18 Sep 2013 09:18:05 -0500 Subject: [whatwg] Proposal: q and qq for document.querySelector and document.querySelectorAll In-Reply-To: <CALrbKZgcSxwRLO93m5=UMCsh9zsF6ouauW3-awkvg80tzky6Rg@mail.gmail.com> References: <CAAn7mYbM-f1cXJZEcDVRnxYppTDT+DJ78-cNdwVsA4qMpQ8=Vw@mail.gmail.com> <CALrbKZgcSxwRLO93m5=UMCsh9zsF6ouauW3-awkvg80tzky6Rg@mail.gmail.com> Message-ID: <CALrbKZjPbMbdftEh0j2r1snPx5B5_JKR_zPADK-z=UWV+ooiCw@mail.gmail.com> Aww, accidentally did a direct reply instead of replying to the list. :( On Sep 18, 2013 7:01 AM, "James Greene" <james.m.greene at gmail.com> wrote: > var q = document.querySelector; > var qq = document.querySelectorAll; > On Sep 18, 2013 3:14 AM, "Leon Gilyadov" <leon.gilyadov at gmail.com> wrote: > >> *The problem:* >> document.querySelector and document.querySelectorAll >> are long and used a lot. >> >> Lines in the code are long. >> >> *Proposal:* >> q('.my-div') >> will be equal to: >> document.querySelector('.my-div) >> >> qq('.my-div') >> will be equal to: >> document.querySelectorAll('.my-div') >> >> >> --Leon Gilyadov. >> > From simonp at opera.com Wed Sep 18 07:26:35 2013 From: simonp at opera.com (Simon Pieters) Date: Wed, 18 Sep 2013 16:26:35 +0200 Subject: [whatwg] Proposal: q and qq for document.querySelector and document.querySelectorAll In-Reply-To: <CALrbKZjPbMbdftEh0j2r1snPx5B5_JKR_zPADK-z=UWV+ooiCw@mail.gmail.com> References: <CAAn7mYbM-f1cXJZEcDVRnxYppTDT+DJ78-cNdwVsA4qMpQ8=Vw@mail.gmail.com> <CALrbKZgcSxwRLO93m5=UMCsh9zsF6ouauW3-awkvg80tzky6Rg@mail.gmail.com> <CALrbKZjPbMbdftEh0j2r1snPx5B5_JKR_zPADK-z=UWV+ooiCw@mail.gmail.com> Message-ID: <op.w3l2elt3idj3kv@simons-macbook-pro.local> On Wed, 18 Sep 2013 16:18:05 +0200, James Greene <james.m.greene at gmail.com> wrote: > Aww, accidentally did a direct reply instead of replying to the list. :( > On Sep 18, 2013 7:01 AM, "James Greene" <james.m.greene at gmail.com> wrote: > >> var q = document.querySelector; >> var qq = document.querySelectorAll; That doesn't work because `this` will be wrong. But you can add .bind(document) to fix that. -- Simon Pieters Opera Software From dbaron at dbaron.org Wed Sep 18 08:10:01 2013 From: dbaron at dbaron.org (L. David Baron) Date: Wed, 18 Sep 2013 08:10:01 -0700 Subject: [whatwg] HTML: A DOM attribute that returns the language of a node In-Reply-To: <CAO9Q3i+V=_FAP9bj9BbO8e58DkQvZKxs8gNpD56qSua=LCUeVw@mail.gmail.com> References: <2316EE6495904AB79C77E28AC9B9ADC7@PeterPC> <CADnb78iBsk=iZRV5g9hBvowhg5AeDoqvMRmVqKqr-jMHStfCBw@mail.gmail.com> <B83F314F39FB4BC2A11F81CE09C5076F@PeterPC> <CAO9Q3i+V=_FAP9bj9BbO8e58DkQvZKxs8gNpD56qSua=LCUeVw@mail.gmail.com> Message-ID: <20130918151001.GA18458@crum.dbaron.org> On Wednesday 2013-05-01 01:01 -0700, Elliott Sprehn wrote: > On Wed, Apr 24, 2013 at 9:22 AM, Peter Occil <poccil14 at gmail.com> wrote: > > I have no objection to the name "baseLang" rather than "language" as the > > name of the DOM attribute. > > > > But if there isn't more interest or you decide not to add this DOM > > attribute, I encourage you to at least: > > > > > fwiw WebKit (and Blink) implement this through CSS inheritance since you > need to know the lang for all kinds of things and walking up the DOM > repeatedly would be expensive. > > -webkit-locale is inherited by default and contains the enclosing @lang > value. You can query it through getComputedStyle(node).webkitLocale. That > doesn't help your custom parser though. In Gecko it's also implemented through CSS inheritance, but it's not exposed to Web content as a CSS property. (Internally it's '-x-lang', but that name isn't exposed.) We use the language for: * font selection * language-specific text-transform behavior * hyphenation (which doesn't work unless it's explicitly specified, as required by http://dev.w3.org/csswg/css-text/#hyphens-property ) -David -- ? L. David Baron http://dbaron.org/ ? ? Mozilla https://www.mozilla.org/ ? Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) From glenn at zewt.org Wed Sep 18 08:27:51 2013 From: glenn at zewt.org (Glenn Maynard) Date: Wed, 18 Sep 2013 10:27:51 -0500 Subject: [whatwg] Proposal: q and qq for document.querySelector and document.querySelectorAll In-Reply-To: <A212DA0831E8714BB0860F102E8E29DC856D350D@omines-srv-004.omines.corp> References: <CAAn7mYbM-f1cXJZEcDVRnxYppTDT+DJ78-cNdwVsA4qMpQ8=Vw@mail.gmail.com> <CAO8i3ifFtFCZTcJoPZgnQs=-82KBva3nz+KHAWE58i5Cor6Qqg@mail.gmail.com> <A212DA0831E8714BB0860F102E8E29DC856D350D@omines-srv-004.omines.corp> Message-ID: <CABirCh_J1tg71RpbMOkVP5N_QfdR64oKcRDiTvY8e7UTrAxbVA@mail.gmail.com> On Wed, Sep 18, 2013 at 7:18 AM, Niels Keurentjes < niels.keurentjes at omines.com> wrote: > The spec should only concern itself with exposing functionality. Practical > considerations such as length of code are the responsibility of the > developer - if you like to have q and qq aliases you can add them yourself > at runtime, that's the whole point of a prototyped language. Common > libraries like jQuery, prototype and Mootools expose the behaviour as $ and > $$ for exactly the reason given, no reason to impose that on every > developer if they choose not to use a library. > This is nonsense. Usability and practicality are absolutely concerns of the spec. If libraries like jQuery need to be used for it to be convenient to develop for the platform, and everyone has different and incompatible convenience wrappers for everything, then that's a failure of the platform. (I don't think this proposal is a good idea, though.) -- Glenn Maynard From annevk at annevk.nl Wed Sep 18 08:34:23 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Wed, 18 Sep 2013 11:34:23 -0400 Subject: [whatwg] HTML: A DOM attribute that returns the language of a node In-Reply-To: <20130918151001.GA18458@crum.dbaron.org> References: <2316EE6495904AB79C77E28AC9B9ADC7@PeterPC> <CADnb78iBsk=iZRV5g9hBvowhg5AeDoqvMRmVqKqr-jMHStfCBw@mail.gmail.com> <B83F314F39FB4BC2A11F81CE09C5076F@PeterPC> <CAO9Q3i+V=_FAP9bj9BbO8e58DkQvZKxs8gNpD56qSua=LCUeVw@mail.gmail.com> <20130918151001.GA18458@crum.dbaron.org> Message-ID: <CADnb78hO6t+WAEKc8-bE4Lnk45HxnduSgFqhGZ9NQPNPfhOj+g@mail.gmail.com> On Wed, Sep 18, 2013 at 11:10 AM, L. David Baron <dbaron at dbaron.org> wrote: > In Gecko it's also implemented through CSS inheritance, but it's not > exposed to Web content as a CSS property. (Internally it's > '-x-lang', but that name isn't exposed.) > > We use the language for: > * font selection > * language-specific text-transform behavior > * hyphenation (which doesn't work unless it's explicitly specified, > as required by http://dev.w3.org/csswg/css-text/#hyphens-property ) It seems my earlier point about inheritance of text direction remains. Base URLs however are obsolete as only Gecko implements xml:base. If this is implemented through CSS, does it make sense to expose it through the DOM? -- http://annevankesteren.nl/ From tobie.langel at gmail.com Wed Sep 18 09:16:02 2013 From: tobie.langel at gmail.com (Tobie Langel) Date: Wed, 18 Sep 2013 18:16:02 +0200 Subject: [whatwg] Proposal: q and qq for document.querySelector and document.querySelectorAll In-Reply-To: <CABirCh_J1tg71RpbMOkVP5N_QfdR64oKcRDiTvY8e7UTrAxbVA@mail.gmail.com> References: <CAAn7mYbM-f1cXJZEcDVRnxYppTDT+DJ78-cNdwVsA4qMpQ8=Vw@mail.gmail.com> <CAO8i3ifFtFCZTcJoPZgnQs=-82KBva3nz+KHAWE58i5Cor6Qqg@mail.gmail.com> <A212DA0831E8714BB0860F102E8E29DC856D350D@omines-srv-004.omines.corp> <CABirCh_J1tg71RpbMOkVP5N_QfdR64oKcRDiTvY8e7UTrAxbVA@mail.gmail.com> Message-ID: <160A4461446F497FBD1140A0F0BF59C2@gmail.com> On Wednesday, September 18, 2013 at 5:27 PM, Glenn Maynard wrote: > On Wed, Sep 18, 2013 at 7:18 AM, Niels Keurentjes < > niels.keurentjes at omines.com (mailto:niels.keurentjes at omines.com)> wrote: > > The spec should only concern itself with exposing functionality. Practical > > considerations such as length of code are the responsibility of the > > developer - if you like to have q and qq aliases you can add them yourself > > at runtime, that's the whole point of a prototyped language. Common > > libraries like jQuery, prototype and Mootools expose the behaviour as $ and > > $$ for exactly the reason given, no reason to impose that on every > > developer if they choose not to use a library. > > This is nonsense. Usability and practicality are absolutely concerns of > the spec. If libraries like jQuery need to be used for it to be convenient > to develop for the platform, and everyone has different and incompatible > convenience wrappers for everything, then that's a failure of the platform. > > (I don't think this proposal is a good idea, though.) ^ this. --tobie From cabanier at gmail.com Wed Sep 18 11:14:32 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Wed, 18 Sep 2013 11:14:32 -0700 Subject: [whatwg] Canvas - Should setLineDash be a nullable sequence? In-Reply-To: <alpine.DEB.2.00.1309171657450.12199@ps20323.dreamhostps.com> References: <CAA5isUZHQQ+zf2CzNOG6NL96c-RkiqF_z0aFjx82_Lh=Xb0hhg@mail.gmail.com> <alpine.DEB.2.00.1309171657450.12199@ps20323.dreamhostps.com> Message-ID: <CAGN7qDB5UsS9UETt8FHaLW=m4nn6BfDYqLZzaa4DogqNnegSOA@mail.gmail.com> On Tue, Sep 17, 2013 at 10:06 AM, Ian Hickson <ian at hixie.ch> wrote: > On Tue, 20 Aug 2013, Simon Sarris wrote: > > > > This is minor, but it did recently break formerly-working functionality > > in Google Chrome, so maybe its worth a discussion. > > > > The specification reads: > > > > void setLineDash(sequence<unrestricted double> segments); // default > empty > > sequence<unrestricted double> getLineDash(); > > > > This means we *cannot* use: > > > > ctx.setLineDash(null); > > > > In Chrome 28 and previous (for at least 6 months) null was an allowed > > value, but in Chrome 30 (at least) it switched to throwing a TypeError. > > I couldn't find any currently-shipping browsers that supported this, so it > seems unlikely that there'd be much legacy content that depends on it. > (Not saying there's none, just that it's limited in scope.) Thus, the > compatibility issue here is not the only thing we should consider. (It's > still a factor, just not an automatic win, as it might otherwise be.) > > There's certainly an advantage to failing if the input is "null" here -- > it's more likely to catch underlying errors quicker. Instead of just > getting a solid line where you expected a dashed one, you get an error > with a precise line number from which to start your search. > > > > In any case, I think it would be better if setLineDash was defined in > > the spec as a nullable sequence, so that when setting it back to nothing > > to return to normal not-dashed path stroking (which could happen > > thousands of times in a an animation frame) less stuff gets allocated in > > the draw loop. > > A literal empty array can get optimised out by compilers, so it really > shouldn't be that big a deal on the long run. > > > > I think part of the issue is that setLineDash does two things. It sets > > the dashing properties, but it also acts as the only way to > > enable/disable dashing, I think that null seems appropriate. > > All lines are dashed, it's just that some have an infinitely long dash > with no space. Don't look at it as enabling/disabling dashing. :-) > That's correct. If we ever allow a 'null', we should equate it to '[]' From cabanier at gmail.com Wed Sep 18 17:03:47 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Wed, 18 Sep 2013 17:03:47 -0700 Subject: [whatwg] Path API feedback In-Reply-To: <alpine.DEB.2.00.1309171709350.12199@ps20323.dreamhostps.com> References: <CAGN7qDATVtL08NLKvYsL+WVzGYn5fy3WxdQLQYqpB55NuhyL3g@mail.gmail.com> <Pine.LNX.4.64.1304260027360.3512@ps20323.dreamhostps.com> <CAGN7qDBcC7aPD1BcuDHbvMavfM3ez0CufFWgaLHcaPHBsuoNrA@mail.gmail.com> <alpine.DEB.2.00.1308202232540.27209@ps20323.dreamhostps.com> <CAGN7qDDXqyZt2gkmttoUps3qgEUiesBdpGmhotUhk4Ay6S_PVQ@mail.gmail.com> <alpine.DEB.2.00.1309171709350.12199@ps20323.dreamhostps.com> Message-ID: <CAGN7qDCUNfxGvc7isRhYL8WLuxP_gk4PfvrrsOTV5VEMTL1COA@mail.gmail.com> On Tue, Sep 17, 2013 at 10:20 AM, Ian Hickson <ian at hixie.ch> wrote: > On Tue, 20 Aug 2013, Rik Cabanier wrote: > > > On Sat, 23 Mar 2013, Rik Cabanier wrote: > > > > > > > > The current path APIs suffer from conflating path segments and > > > > geometry. To fix this, I proposed to modify the API so path just > > > > describe the path segments. > > > > > > > > http://blogs.adobe.com/webplatform/2013/01/31/revised-canvas-paths/ > > > > > > I disagree with the premise of this post -- it's not the case that you > > > never want to add segments. It is in fact quite common to add segments > > > to a path -- that's what constructing a path is. > > > > I disagree. How many times does an author want to add segments to an > > existing path? > > Pretty much every time they create a path with more than one segment. > Maybe I phrased that wrong. The existing path is a path that was created earlier (and could have already been used to draw). It's not often that you would want to append to such a path. > Let's say an application stores a circle in a path and now want to draw > > a rectangle too. You propose that the application just appends the > > rectangle. > > No, not necessarily. It depends on what they want to do. If they want a > single path that is constructed of a circle and a rectangle in the same > way that it would be if they did: > > x.beginPath(); > x.arc(...); > x.rect(...); > x.fill(); > > ...then yeah, they should just append the rectangle. But if they want the > same effect as: > > x.beginPath(); > x.arc(); > x.fill(); > x.rect(...); > x.fill(); > > ...then they should not just append them, since as you say, it won't work. > Yes, but for hit regions, you would have to calculate the area that these 2 fill operations covered. This is why we need the extra 'union' API. > > > > > Also, it's not at all clear to me that there's really a distinction > > > between a "shape" and a "path". They're really the same thing -- sets > > > of path segments. > > > > No. A shape is no longer a group of line segments. You *could* convert > > it to such a thing but that requires a bunch of complex math (ie > > http://www.youtube.com/watch?v=OmfliNQsk88) For now, I'm not proposing > > to add that to the canvas API. > > Once the Path API is implemented, we can add any number of features, such > as adding a path so as to form the union of both paths, adding a path so > as to form the intersection of both paths, etc. > OK. In order to make that possible, 'addPath', 'addPathByStrokingPath', 'addText' and 'addTextByStrokingText' should be cut from the interface. > > > > The resulting 'path' will once again have no winding. This is very > > confusing and extremely hard to implement > > I don't understand why it's hard to implement. It's just the non-Path API, > but stored away for future use. > > > > > Right now we have two options (ignoring the text parts of the path > > > API): concatenating path segments, and concatenating path segments > > > after having first outlined one of them. > > > > FYI the outlining algorithm is also not correct. It suffers from the > > same issue that strokes are segments. > > Can you elaborate? (I think I may have asked already, in which case, my > apologies for asking again.) > I started it in http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-September/040810.html > > > > > On the long run I think it would make sense to add other methods, e.g. > > > one combining two or more paths together such that the resulting path > > > would outline the union of the "insides" of the provided paths, or the > > > intersections, or whatnot. > > > > I think that would be much more confusing and difficult to implement. I > > didn't come up with this on my own :-). This is done by graphics > > libraries that offers path manipulation support. For instance: skia: > > http://skia-autogen.googlecode.com/svn/docs/html/classSkPathEffect.html > > lib2geom: http://wiki.inkscape.org/wiki/index.php/WorkingWith2GeomFAQ > > Direct2D: > > > http://msdn.microsoft.com/en-us/library/windows/desktop/dd756653(v=vs.85).aspx#path_geometries > > I'm confused. Are these examples of how to make confusing APIs, or > examples of how the current API is confusing? Those look really, really > complicated relative to what Canvas looks like today. > Those are examples how path composition is defined in graphic libraries. I'm not proposing that we copy the APIs :-) None of the libraries I listed, is working on the path operations themselves (like you defined in canvas) > > > On Thu, 5 Sep 2013, Rik Cabanier wrote: > > > > The problem happens when you call fill or stroke multiple times. > > [...] > > Now I want to create a region that covers what was drawn. > > [...] > > 'p' won't describe the same area as what was filled. > > Sure, for that you need a new API function, e.g. union, which as I've > mentioned before, I think would be a logical addition to the API in due > course. But I don't think we should add features too quickly, lest we get > too far ahead of browsers. That sounds reasonable. So please remove the APIs such as AddPathByStrokingPath that rely on these difficult algorithms. From lists at scratchdisk.com Fri Sep 20 10:48:42 2013 From: lists at scratchdisk.com (=?iso-8859-1?Q?J=FCrg_Lehni?=) Date: Fri, 20 Sep 2013 10:48:42 -0700 Subject: [whatwg] Questions regarding Path object In-Reply-To: <alpine.DEB.2.00.1308201808080.27209@ps20323.dreamhostps.com> References: <0E6F0444-AB1B-4FFC-B62C-E14F3DB74BA1@scratchdisk.com> <CAGN7qDB_CM=KTaW5+cB9FoYSuCK93kNvNMru8FVUh4BLxLKezw@mail.gmail.com> <C702CEA4-0D06-4E2B-9EFF-DC93DEF58310@scratchdisk.com> <CAGN7qDABijW_nB=+n4AKNwc6BwKGDY99G9KC0KCJheQyCdDN2w@mail.gmail.com> <82C5F947-BDF4-45A1-9701-3857E2194C60@scratchdisk.com> <CAGN7qDAvnfCEqh7Cp8hgo0kWW11wpJE0UBwTaghwkPB7tya5iQ@mail.gmail.com> <18E5B2F8-5A03-4486-9EEE-CEC0FB3E80EE@scratchdisk.com> <51C0416D.2060905@opera.com> <alpine.DEB.2.00.1308201808080.27209@ps20323.dreamhostps.com> Message-ID: <7DE99F3A-5842-4A8B-9FA5-A1799091FE24@scratchdisk.com> Apologies for the slow reply on this, just seeing your answer now: On Aug 20, 2013, at 11:32 , Ian Hickson <ian at hixie.ch> wrote: > On Sat, 23 Mar 2013, J?rg Lehni wrote: >> >> - Paper.js has its own share of classes, and one of them is called Path. >> We normally run scoped but allow people to inject into the global scope. >> This would override the new Path constructor. > > This was last considered last October: > > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-October/037548.html > > My conclusion then was that we didn't have much evidence that Path was > going to work, but we also didn't have much evidence that it was going to > be an insurmountable problem. > > How much of a problem is the paper.js case? It is quite a problem for us really because many people choose to inject the scoped library into the global scope, for simpler code. That is also the way one writes code in PaperScript (which is executed in its own scope where these constructors appear global, but do not pollute the actual global scope), and thus how all our examples and tutorials are written. Path is the most important constructor in Paper.js, a lot is built on top of it. Changing it now would be a huge nuisance for us. > The name "Path" is generic, but that's kind of the point -- this interface > might get used by SVG and other contexts, which is why I didn't call it > CanvasPath, Path2D, or some variant of Shape. I would like to argue that Path2D is more precise and accurate than simply Path. It is about two dimensional vector graphics after all, and about performing geometric operations with / on it (hit testing, boolean operations, drawing). Path2D makes as much sense in a Canvas context as it does in SVG. >> - I see there are many ways to construct paths from different type of >> data, and perform manipulations on them. addPathByStrokingPath() and >> addPathByStrokingText() are both very welcome, for example. Will there >> be a way to access the resulting path description again, for example as >> SVG-style pathData? I have not seen a description of any such property >> on the object, but would strongly suggest that one is added, since >> having access to the result of such path manipulations would hugely >> increase the usefulness of the Path object. > > Manipulating paths is something I am punting on until browsers implement > what's in the spec already, but I imagine at some point we'll add that, > yeah. Maybe we can be of help there: We have put a lot of thought and work into how Paper.js allows users to directly draw and manipulate Path data, and tried to come up with solutions to make that as easy and convenient as possible. I believe we could contribute insight to that discussion. Also, thanks to Harikrishnan Gopalakrishnan, since a couple of months Paper.js has a working implementation of fat bezier clipping for very fast path intersections, and a very resourceful implementation of boolean operations (both in amount of code, and execution speed). Perhaps this could serve as an example implementation? We are currently working on implementing stroke expansion also. > On Sat, 23 Mar 2013, Rik Cabanier wrote: >> >> The current path APIs suffer from conflating path segments and geometry. >> To fix this, I proposed to modify the API so path just describe the path >> segments. >> >> http://blogs.adobe.com/webplatform/2013/01/31/revised-canvas-paths/ > > I disagree with the premise of this post -- it's not the case that you > never want to add segments. It is in fact quite common to add segments to > a path -- that's what constructing a path is. > > Also, it's not at all clear to me that there's really a distinction > between a "shape" and a "path". They're really the same thing -- sets of > path segments. What distinguishes them is not anything intrinsic to them, > it's the behaviour when you combine segments. > > Thus the clearer solution, IMHO, insofar as there's a problem, is to add > methods that describe the various ways to combine paths. > > Right now we have two options (ignoring the text parts of the path API): > concatenating path segments, and concatenating path segments after having > first outlined one of them. > > On the long run I think it would make sense to add other methods, e.g. one > combining two or more paths together such that the resulting path would > outline the union of the "insides" of the provided paths, or the > intersections, or whatnot. In Paper.js we make the distinction between CompoundPath and Path, which stems from working with Adobe Illustrator. Path describes one open or closed loop of Segments connected by Curves (each Segment having a point, handleIn and handleOut attribute, the Curve in between two Segments in fact just describe the same information in a different way). CompoundPath then are simply groups of Path items, which are rendered together with the same color and fill rule. It's very different to what SVG does, but this distinction has helped us reduce the complexity of what Path needs to do a lot, and it really helps when manipulating Path items directly. >> Path, Shape, Gradient, Matrix all seem way too generic, and will >> definitely clash with many libraries. > > It's not that clear that this is true. There really haven't been that many > reports of clashes, all things considered -- and it's not clear that > Path2D, GraphicsPath, CanvasPath, or any number of other variants, would > really be any more or less likely to clash. Shape, Matrix and Gradient are all constructors that we have in Paper.js as well. >> Well I know there will be problems: Paper.js has a Path class since >> 2011, and these will clash when using the library without scoping, which >> is what many people do. > > How many is many? How high-profile are they? Google, Foursquare and the NY Times have used Paper.js for interactive features, games and dynamic graphics on their websites, just to name a few. I'm not sure if they were used in a scope manner or not, though. >> I doubt we're the only library that clashes. > > Do we have any data on this? Do any libraries use Path2D? I've been looking for Path2D + JavaScript on Google Code search and Github, and have not found one single occurrence. The idea for the name comes from Java, where all 2D geometric classes have 2D behind their name. I'm pretty confident there would not be a single clash. Best, J?rg From simon.sarris at gmail.com Fri Sep 20 11:16:30 2013 From: simon.sarris at gmail.com (Simon Sarris) Date: Fri, 20 Sep 2013 14:16:30 -0400 Subject: [whatwg] Canvas - Somewhat inconsistent rules in the spec for drawImage Message-ID: <CAA5isUZnmG9BOL=oF8Xpunrw6DgF6no50WUTkvDH7ORK5ui5Sw@mail.gmail.com> Summary: You can draw zero-sized Images and objects with zero-sized source rects to the canvas context. You cannot draw zero-sized Canvases, you get an InvalidStateError. According to the spec this is right, but I think there should be more consistency in handling these cases. drawImage can be called with an Image, a Canvas, or a Video element, so you typically see calls like: ctx.drawImage(imageReference, 0, 0); ctx.drawImage(canvasReference, 0, 0); 99% of the time you can think of them as interchangeable. Let's talk about our 1%ers. I came across an interesting (and none-too-useful, but we can blame the browser for that) error when drawing a canvas with zero width and height: inMemoryCanvas.width = 0; // Uncaught InvalidStateError: An attempt was made to use an object that is not, or is no longer, usable. ctx.drawImage(inMemoryCanvas, 0, 0); According to the specification, this is the right error to throw: > If the image argument is an HTMLCanvasElement object with either a horizontal dimension or a vertical dimension equal to zero, then throw an InvalidStateError exception, return aborted, and abort these steps. The bothersome thing is that: 1. Zero-sized Images do not have any such error 2. calling drawImage with a source rectangle, using context.drawImage(image, sx, sy, sw, sh, dx, dy, dw, dh), when the source rectangle has zero width or height, does not give an error. Per the spec: > If one of the sw or sh arguments is zero, abort these steps. Nothing is painted. So zero-sized sources are fine if they are an HTMLImageElement or a source rectangle, but not fine if they are HTMLCanvasElement. This seems inconsistent, and the error given seems odd too. It's not very descriptive and not immediately clear what is wrong. This issue came to my attention because a friend asked for help, who was drawing randomly-sized canvases onto a main context. He suspected InvalidStateError was some bizarre closure bug where part of the canvas state was being lost, but of course the truth was more mundane - some but not all zero-sized objects cannot be drawn to the canvas context. Anywho, I recommend either considering all zero-sized sources as invalid, and perhaps giving a more descriptive error, or simply allowing a zero-sized canvas to be a valid drawImage argument so that it may run its natural course (draw nothing), just like Image and zero-sized source rect arguments. Simon Sarris ~~~ For reference, below is a simple example showing both a zero-sized img being drawn and a zero-sized canvas: // this <img>'s width/height/naturalWidth/naturalHeight are all zero: var img = document.createElement('img'); // Totally fine, no error: ctx.drawImage(img, 0, 0); var inMemoryCanvas = document.createElement('canvas'); inMemoryCanvas.width = 0; inMemoryCanvas.height = 0; // Uncaught InvalidStateError: An attempt was made to use an object that is not, or is no longer, usable. ctx.drawImage(inMemoryCanvas, 0, 0); From lists at scratchdisk.com Fri Sep 20 11:16:36 2013 From: lists at scratchdisk.com (=?iso-8859-1?Q?J=FCrg_Lehni?=) Date: Fri, 20 Sep 2013 11:16:36 -0700 Subject: [whatwg] Questions regarding Path object In-Reply-To: <7DE99F3A-5842-4A8B-9FA5-A1799091FE24@scratchdisk.com> References: <0E6F0444-AB1B-4FFC-B62C-E14F3DB74BA1@scratchdisk.com> <CAGN7qDB_CM=KTaW5+cB9FoYSuCK93kNvNMru8FVUh4BLxLKezw@mail.gmail.com> <C702CEA4-0D06-4E2B-9EFF-DC93DEF58310@scratchdisk.com> <CAGN7qDABijW_nB=+n4AKNwc6BwKGDY99G9KC0KCJheQyCdDN2w@mail.gmail.com> <82C5F947-BDF4-45A1-9701-3857E2194C60@scratchdisk.com> <CAGN7qDAvnfCEqh7Cp8hgo0kWW11wpJE0UBwTaghwkPB7tya5iQ@mail.gmail.com> <18E5B2F8-5A03-4486-9EEE-CEC0FB3E80EE@scratchdisk.com> <51C0416D.2060905@opera.com> <alpine.DEB.2.00.1308201808080.27209@ps20323.dreamhostps.com> <7DE99F3A-5842-4A8B-9FA5-A1799091FE24@scratchdisk.com> Message-ID: <FCC13E51-06A9-47EB-9DB3-B7E5097DACB8@scratchdisk.com> PS: iOS 7 is barely released, but the first bug reports are already coming in, because the new Mobile Safari now defines Path, and clashes: https://twitter.com/danetag/status/380636739251220480 From kangax at gmail.com Fri Sep 20 11:33:41 2013 From: kangax at gmail.com (Juriy Zaytsev) Date: Fri, 20 Sep 2013 20:33:41 +0200 Subject: [whatwg] Questions regarding Path object In-Reply-To: <FCC13E51-06A9-47EB-9DB3-B7E5097DACB8@scratchdisk.com> References: <0E6F0444-AB1B-4FFC-B62C-E14F3DB74BA1@scratchdisk.com> <CAGN7qDB_CM=KTaW5+cB9FoYSuCK93kNvNMru8FVUh4BLxLKezw@mail.gmail.com> <C702CEA4-0D06-4E2B-9EFF-DC93DEF58310@scratchdisk.com> <CAGN7qDABijW_nB=+n4AKNwc6BwKGDY99G9KC0KCJheQyCdDN2w@mail.gmail.com> <82C5F947-BDF4-45A1-9701-3857E2194C60@scratchdisk.com> <CAGN7qDAvnfCEqh7Cp8hgo0kWW11wpJE0UBwTaghwkPB7tya5iQ@mail.gmail.com> <18E5B2F8-5A03-4486-9EEE-CEC0FB3E80EE@scratchdisk.com> <51C0416D.2060905@opera.com> <alpine.DEB.2.00.1308201808080.27209@ps20323.dreamhostps.com> <7DE99F3A-5842-4A8B-9FA5-A1799091FE24@scratchdisk.com> <FCC13E51-06A9-47EB-9DB3-B7E5097DACB8@scratchdisk.com> Message-ID: <CAPdhPzkcXTwGd8XF1rKZ7u5RrRbB6P9eB1dEWu8ajCj6K7Z+Vg@mail.gmail.com> FWIW, in Fabric.js [1], everything is scoped under global `fabric` object. `fabric.Path`, `fabric.Circle`, `fabric.Color`, etc. For any third-party library in a cross-browser environment, this has been the only sane strategy of avoiding conflicts and keeping things scalable. We learned about "global everything" problems back in the Prototype.js [2] days :) After all, "injection" could always be done on a local level: (function() { var Path = fabric.Path, Circle = fabric.Circle, etc. ... new Path(); ... })(); I also don't see much simplicity in using global names. It's just irresponsible and asking for trouble. [1] http://fabricjs.com [2] http://prototypejs.org -- kangax On Fri, Sep 20, 2013 at 8:16 PM, J?rg Lehni <lists at scratchdisk.com> wrote: > PS: iOS 7 is barely released, but the first bug reports are already coming > in, because the new Mobile Safari now defines Path, and clashes: > > https://twitter.com/danetag/status/380636739251220480 > > From junov at google.com Fri Sep 20 11:40:24 2013 From: junov at google.com (Justin Novosad) Date: Fri, 20 Sep 2013 14:40:24 -0400 Subject: [whatwg] Canvas - Somewhat inconsistent rules in the spec for drawImage In-Reply-To: <CAA5isUZnmG9BOL=oF8Xpunrw6DgF6no50WUTkvDH7ORK5ui5Sw@mail.gmail.com> References: <CAA5isUZnmG9BOL=oF8Xpunrw6DgF6no50WUTkvDH7ORK5ui5Sw@mail.gmail.com> Message-ID: <CABpaAqTCJD-idcS9qYGgFxb4-7Bi7B84R-Pm1hNh-zyEUr9=sw@mail.gmail.com> On Fri, Sep 20, 2013 at 2:16 PM, Simon Sarris <simon.sarris at gmail.com>wrote: > > Anywho, I recommend either considering all zero-sized sources as invalid, > and perhaps giving a more descriptive error, or simply allowing a > zero-sized canvas to be a valid drawImage argument so that it may run its > natural course (draw nothing), just like Image and zero-sized source rect > arguments. > If we do anything, it should be the latter (draw nothing) to avoid breaking existing apps. From robert at ocallahan.org Fri Sep 20 15:13:43 2013 From: robert at ocallahan.org (Robert O'Callahan) Date: Sat, 21 Sep 2013 10:13:43 +1200 Subject: [whatwg] Canvas - Somewhat inconsistent rules in the spec for drawImage In-Reply-To: <CABpaAqTCJD-idcS9qYGgFxb4-7Bi7B84R-Pm1hNh-zyEUr9=sw@mail.gmail.com> References: <CAA5isUZnmG9BOL=oF8Xpunrw6DgF6no50WUTkvDH7ORK5ui5Sw@mail.gmail.com> <CABpaAqTCJD-idcS9qYGgFxb4-7Bi7B84R-Pm1hNh-zyEUr9=sw@mail.gmail.com> Message-ID: <CAOp6jLaE5v8pU+aJrwjk5rUVJJLZOrROnadmoP7EnVrFS+h+4w@mail.gmail.com> On Sat, Sep 21, 2013 at 6:40 AM, Justin Novosad <junov at google.com> wrote: > If we do anything, it should be the latter (draw nothing) to avoid breaking > existing apps. > I agree. I commented on this a while ago, and I still think it's simpler and more robust for drawing a zero-size "anything" to just draw nothing. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * From anewpage.media at gmail.com Fri Sep 20 15:36:53 2013 From: anewpage.media at gmail.com (Brian Blakely) Date: Fri, 20 Sep 2013 18:36:53 -0400 Subject: [whatwg] Add <input> "Switch" Type Message-ID: <CAJGQg4G0OphnZocf_HjdniDDgN4FZoTd3oBHQkDz0OcXDvR66A@mail.gmail.com> "iPhone OS" introduced the switch control (http://i.imgur.com/TA79fo2.png) in 2007. Since then, there have been many attempts to recreate this on the Web Platform by hacking existing control types and using a lot of meaningless markup, to varying degrees of success. The proposal is to add a "switch" <input> type. When it is active, the UA should render a switch control. It looks like this: <input type="switch" on /> The "on" attribute indicates whether the switch is in its "on" or "off" state. There is no "off" attribute, as switches are off by default. The values corresponding to each state are true and false, respectively. List of OSs that implement switch controls (likely incomplete): - Windows 8 - OS X - iOS - Android - Blackberry OS - Windows Phone The major advantage here, as with all controls in HTML, is that the behavior and default appearance of the control is guaranteed to be consistent for a user across the Web, and likely match their host OS as well. This is sure to be a very attractive and convenient solution for authors. From jackalmage at gmail.com Fri Sep 20 15:44:55 2013 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Fri, 20 Sep 2013 15:44:55 -0700 Subject: [whatwg] Add <input> "Switch" Type In-Reply-To: <CAJGQg4G0OphnZocf_HjdniDDgN4FZoTd3oBHQkDz0OcXDvR66A@mail.gmail.com> References: <CAJGQg4G0OphnZocf_HjdniDDgN4FZoTd3oBHQkDz0OcXDvR66A@mail.gmail.com> Message-ID: <CAAWBYDCScmVx46zSL0TZ0_L_AWWWfB_Oq2Ps3q7JfMJNTr4XAg@mail.gmail.com> On Fri, Sep 20, 2013 at 3:36 PM, Brian Blakely <anewpage.media at gmail.com> wrote: > "iPhone OS" introduced the switch control (http://i.imgur.com/TA79fo2.png) > in 2007. Since then, there have been many attempts to recreate this on the > Web Platform by hacking existing control types and using a lot of > meaningless markup, to varying degrees of success. > > The proposal is to add a "switch" <input> type. When it is active, the UA > should render a switch control. It looks like this: > > <input type="switch" on /> > > The "on" attribute indicates whether the switch is in its "on" or "off" > state. There is no "off" attribute, as switches are off by default. The > values corresponding to each state are true and false, respectively. > > List of OSs that implement switch controls (likely incomplete): > > - Windows 8 > - OS X > - iOS > - Android > - Blackberry OS > - Windows Phone > > The major advantage here, as with all controls in HTML, is that the > behavior and default appearance of the control is guaranteed to be > consistent for a user across the Web, and likely match their host OS as > well. This is sure to be a very attractive and convenient solution for > authors. This is just a "checkbox" input with different styling, yes? ~TJ From anewpage.media at gmail.com Fri Sep 20 16:03:06 2013 From: anewpage.media at gmail.com (Brian M. Blakely) Date: Fri, 20 Sep 2013 19:03:06 -0400 Subject: [whatwg] Add <input> "Switch" Type In-Reply-To: <CAAWBYDCScmVx46zSL0TZ0_L_AWWWfB_Oq2Ps3q7JfMJNTr4XAg@mail.gmail.com> References: <CAJGQg4G0OphnZocf_HjdniDDgN4FZoTd3oBHQkDz0OcXDvR66A@mail.gmail.com> <CAAWBYDCScmVx46zSL0TZ0_L_AWWWfB_Oq2Ps3q7JfMJNTr4XAg@mail.gmail.com> Message-ID: <17196F15-F100-486D-978D-A7CF22944E58@gmail.com> I was contemplating whether to propose a new input type, or an attribute valid only for checkboxes. But it isn't a checkbox, so I went with a new type value. You can choose to slide the switch or click it in most OS implementations, so even the behavior is different from a checkbox. I consider it a different input type the way "range" and "number" are different, despite being semantically identical. > On Sep 20, 2013, at 6:44 PM, "Tab Atkins Jr." <jackalmage at gmail.com> wrote: > >> On Fri, Sep 20, 2013 at 3:36 PM, Brian Blakely <anewpage.media at gmail.com> wrote: >> "iPhone OS" introduced the switch control (http://i.imgur.com/TA79fo2.png) >> in 2007. Since then, there have been many attempts to recreate this on the >> Web Platform by hacking existing control types and using a lot of >> meaningless markup, to varying degrees of success. >> >> The proposal is to add a "switch" <input> type. When it is active, the UA >> should render a switch control. It looks like this: >> >> <input type="switch" on /> >> >> The "on" attribute indicates whether the switch is in its "on" or "off" >> state. There is no "off" attribute, as switches are off by default. The >> values corresponding to each state are true and false, respectively. >> >> List of OSs that implement switch controls (likely incomplete): >> >> - Windows 8 >> - OS X >> - iOS >> - Android >> - Blackberry OS >> - Windows Phone >> >> The major advantage here, as with all controls in HTML, is that the >> behavior and default appearance of the control is guaranteed to be >> consistent for a user across the Web, and likely match their host OS as >> well. This is sure to be a very attractive and convenient solution for >> authors. > > This is just a "checkbox" input with different styling, yes? > > ~TJ From alonisser at gmail.com Sun Sep 22 02:51:06 2013 From: alonisser at gmail.com (alonn) Date: Sun, 22 Sep 2013 11:51:06 +0200 Subject: [whatwg] Add <input> "Switch" Type Message-ID: <CAN3noj39k=g96bEaDCe2dgB1v+qz8NBStfuY84mQOkjBjGJE3A@mail.gmail.com> +1 from the web author perspective. would be nice if this wasn't so "Hackish" and if the look was more consistent. I do agree that this could be achieved (maybe more backwards compatibly) with an "switch" attribute on the ```checkbox``` input type. Twitter:@alonisser <https://twitter.com/alonisser> LinkedIn Profile <http://www.linkedin.com/in/alonisser> Facebook <https://www.facebook.com/alonisser> *Tech blog:*4p-tech.co.il/blog *Personal Blog:*degeladom.wordpress.com Tel:972-54-6734469 On Sat, Sep 21, 2013 at 9:06 PM, <whatwg-request at lists.whatwg.org> wrote: > Send whatwg mailing list submissions to > whatwg at lists.whatwg.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org > or, via email, send a message with subject or body 'help' to > whatwg-request at lists.whatwg.org > > You can reach the person managing the list at > whatwg-owner at lists.whatwg.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of whatwg digest..." > > When replying to digest messages, please please PLEASE update the subject > line so it isn't the digest subject line. > Today's Topics: > > 1. Re: Canvas - Somewhat inconsistent rules in the spec for > drawImage (Robert O'Callahan) > 2. Add <input> "Switch" Type (Brian Blakely) > 3. Re: Add <input> "Switch" Type (Tab Atkins Jr.) > 4. Re: Add <input> "Switch" Type (Brian M. Blakely) > > > ---------- Forwarded message ---------- > From: "Robert O'Callahan" <robert at ocallahan.org> > To: Justin Novosad <junov at google.com> > Cc: Simon Sarris <simon.sarris at gmail.com>, WHATWG List <whatwg at whatwg.org> > Date: Sat, 21 Sep 2013 10:13:43 +1200 > Subject: Re: [whatwg] Canvas - Somewhat inconsistent rules in the spec for > drawImage > On Sat, Sep 21, 2013 at 6:40 AM, Justin Novosad <junov at google.com> wrote: > > > If we do anything, it should be the latter (draw nothing) to avoid > breaking > > existing apps. > > > > I agree. I commented on this a while ago, and I still think it's simpler > and more robust for drawing a zero-size "anything" to just draw nothing. > > Rob > -- > Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni > le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa > stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, > 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp > waanndt wyeonut thoo mken.o w * > * > > > > ---------- Forwarded message ---------- > From: Brian Blakely <anewpage.media at gmail.com> > To: "whatwg at lists.whatwg.org" <whatwg at lists.whatwg.org> > Cc: > Date: Fri, 20 Sep 2013 18:36:53 -0400 > Subject: [whatwg] Add <input> "Switch" Type > "iPhone OS" introduced the switch control (http://i.imgur.com/TA79fo2.png) > in 2007. Since then, there have been many attempts to recreate this on the > Web Platform by hacking existing control types and using a lot of > meaningless markup, to varying degrees of success. > > The proposal is to add a "switch" <input> type. When it is active, the UA > should render a switch control. It looks like this: > > <input type="switch" on /> > > The "on" attribute indicates whether the switch is in its "on" or "off" > state. There is no "off" attribute, as switches are off by default. The > values corresponding to each state are true and false, respectively. > > List of OSs that implement switch controls (likely incomplete): > > - Windows 8 > - OS X > - iOS > - Android > - Blackberry OS > - Windows Phone > > The major advantage here, as with all controls in HTML, is that the > behavior and default appearance of the control is guaranteed to be > consistent for a user across the Web, and likely match their host OS as > well. This is sure to be a very attractive and convenient solution for > authors. > > > > ---------- Forwarded message ---------- > From: "Tab Atkins Jr." <jackalmage at gmail.com> > To: Brian Blakely <anewpage.media at gmail.com> > Cc: "whatwg at lists.whatwg.org" <whatwg at lists.whatwg.org> > Date: Fri, 20 Sep 2013 15:44:55 -0700 > Subject: Re: [whatwg] Add <input> "Switch" Type > On Fri, Sep 20, 2013 at 3:36 PM, Brian Blakely <anewpage.media at gmail.com> > wrote: > > "iPhone OS" introduced the switch control ( > http://i.imgur.com/TA79fo2.png) > > in 2007. Since then, there have been many attempts to recreate this on > the > > Web Platform by hacking existing control types and using a lot of > > meaningless markup, to varying degrees of success. > > > > The proposal is to add a "switch" <input> type. When it is active, the > UA > > should render a switch control. It looks like this: > > > > <input type="switch" on /> > > > > The "on" attribute indicates whether the switch is in its "on" or "off" > > state. There is no "off" attribute, as switches are off by default. The > > values corresponding to each state are true and false, respectively. > > > > List of OSs that implement switch controls (likely incomplete): > > > > - Windows 8 > > - OS X > > - iOS > > - Android > > - Blackberry OS > > - Windows Phone > > > > The major advantage here, as with all controls in HTML, is that the > > behavior and default appearance of the control is guaranteed to be > > consistent for a user across the Web, and likely match their host OS as > > well. This is sure to be a very attractive and convenient solution for > > authors. > > This is just a "checkbox" input with different styling, yes? > > ~TJ > > > > ---------- Forwarded message ---------- > From: "Brian M. Blakely" <anewpage.media at gmail.com> > To: "Tab Atkins Jr." <jackalmage at gmail.com> > Cc: "whatwg at lists.whatwg.org" <whatwg at lists.whatwg.org> > Date: Fri, 20 Sep 2013 19:03:06 -0400 > Subject: Re: [whatwg] Add <input> "Switch" Type > I was contemplating whether to propose a new input type, or an attribute > valid only for checkboxes. But it isn't a checkbox, so I went with a new > type value. You can choose to slide the switch or click it in most OS > implementations, so even the behavior is different from a checkbox. > > I consider it a different input type the way "range" and "number" are > different, despite being semantically identical. > > > > On Sep 20, 2013, at 6:44 PM, "Tab Atkins Jr." <jackalmage at gmail.com> > wrote: > > > >> On Fri, Sep 20, 2013 at 3:36 PM, Brian Blakely < > anewpage.media at gmail.com> wrote: > >> "iPhone OS" introduced the switch control ( > http://i.imgur.com/TA79fo2.png) > >> in 2007. Since then, there have been many attempts to recreate this on > the > >> Web Platform by hacking existing control types and using a lot of > >> meaningless markup, to varying degrees of success. > >> > >> The proposal is to add a "switch" <input> type. When it is active, the > UA > >> should render a switch control. It looks like this: > >> > >> <input type="switch" on /> > >> > >> The "on" attribute indicates whether the switch is in its "on" or "off" > >> state. There is no "off" attribute, as switches are off by default. > The > >> values corresponding to each state are true and false, respectively. > >> > >> List of OSs that implement switch controls (likely incomplete): > >> > >> - Windows 8 > >> - OS X > >> - iOS > >> - Android > >> - Blackberry OS > >> - Windows Phone > >> > >> The major advantage here, as with all controls in HTML, is that the > >> behavior and default appearance of the control is guaranteed to be > >> consistent for a user across the Web, and likely match their host OS as > >> well. This is sure to be a very attractive and convenient solution for > >> authors. > > > > This is just a "checkbox" input with different styling, yes? > > > > ~TJ > > > _______________________________________________ > whatwg mailing list > whatwg at lists.whatwg.org > http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org > > From yoav at yoav.ws Sun Sep 22 04:05:20 2013 From: yoav at yoav.ws (Yoav Weiss) Date: Sun, 22 Sep 2013 13:05:20 +0200 Subject: [whatwg] The srcset attribute - some implementation feedback & questions Message-ID: <CACj=BEj0CLEP1BjG1-8G=b9ruzXVCkG2DBqx99PDSp6C6fCsSw@mail.gmail.com> I've recently ported the WebKit srcset implementation into Blink, and pretty much rewrote it in the process. I'd like to provide some feedback and ask for clarifications, in order to improve the implementation's spec[1] compliance. Below I'll discuss the algorithm's step and points that I'd like clarifications on. Step 5 ---------- What happens when the srcset attribute is of the form "candidate1.png, candidate2.png 2x"? As far as I understand it, according to the spec it results in a single image candidate url "candidate1.png," followed by the descriptors "candidate2.png 2x", which is probably not what the author intended. As a note, both WebKit & Blink implementations diverge from the spec here, by adding a "check if the URL's last char is ',' and if so, continue without trying to parse out descriptors" step. This also enables the implementations to ignore empty candidates such as "candidate1.png 1x, , , , , candidate2.png 2x". A similar case of <img srcset="candidate1.png,candidate2.png 2x"> results in the image candidate URL being "candidate1.png,candidate2.png". Is that the correct behavior? I'm not sure what should be the result here (since splitting on commas will break data URIs), but I'm certain this will be a source of confusion for authors. Step 13.6 ------------ What happens when one of the valid qualifier characters is followed by other non qualifier chars? e.g.is "2xbla" a valid descriptor? What happens when one of the valid qualifier characters is followed by another qualifier char? e.g.is "2xwh" a valid descriptor? Does it set all three variables to 2? What happens to invalid descriptors? If I understand correctly, invalid descriptors should just be ignored so that "2x 500tt bla" will results in a density of 2, width of infinity and height of infinity. Is that correct? Yoav [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#processing-the-image-candidates From simonp at opera.com Mon Sep 23 02:40:05 2013 From: simonp at opera.com (Simon Pieters) Date: Mon, 23 Sep 2013 11:40:05 +0200 Subject: [whatwg] The srcset attribute - some implementation feedback & questions In-Reply-To: <CACj=BEj0CLEP1BjG1-8G=b9ruzXVCkG2DBqx99PDSp6C6fCsSw@mail.gmail.com> References: <CACj=BEj0CLEP1BjG1-8G=b9ruzXVCkG2DBqx99PDSp6C6fCsSw@mail.gmail.com> Message-ID: <op.w3uyg3y8idj3kv@simons-macbook-pro.local> On Sun, 22 Sep 2013 13:05:20 +0200, Yoav Weiss <yoav at yoav.ws> wrote: > I've recently ported the WebKit srcset implementation into Blink, and > pretty much rewrote it in the process. > > I'd like to provide some feedback and ask for clarifications, in order to > improve the implementation's spec[1] compliance. Below I'll discuss the > algorithm's step and points that I'd like clarifications on. > > Step 5 > ---------- > What happens when the srcset attribute is of the form "candidate1.png, > candidate2.png 2x"? > As far as I understand it, according to the spec it results in a single > image candidate url "candidate1.png," followed by the descriptors > "candidate2.png 2x", Correct. > which is probably not what the author intended. > As a note, both WebKit & Blink implementations diverge from the spec > here, > by adding a "check if the URL's last char is ',' and if so, continue > without trying to parse out descriptors" step. This also enables the > implementations to ignore empty candidates such as "candidate1.png 1x, , > , > , , candidate2.png 2x". Maybe we can change the spec to do that. If the author wants to use a URL with a comma at the end, it can be percent-escaped. > A similar case of <img srcset="candidate1.png,candidate2.png 2x"> results > in the image candidate URL being "candidate1.png,candidate2.png". Is that > the correct behavior? Yes. > I'm not sure what should be the result here (since splitting on commas > will > break data URIs), but I'm certain this will be a source of confusion for > authors. > > Step 13.6 > ------------ > What happens when one of the valid qualifier characters is followed by > other non qualifier chars? e.g.is "2xbla" a valid descriptor? It doesn't match any of the three cases in that step, so it gets dropped on the floor. > What happens when one of the valid qualifier characters is followed by > another qualifier char? e.g.is "2xwh" a valid descriptor? Same as above. > Does it set all > three variables to 2? No. > What happens to invalid descriptors? If I understand correctly, invalid > descriptors should just be ignored so that "2x 500tt bla" will results > in a > density of 2, width of infinity and height of infinity. > Is that correct? Yes. Step 13.6. could say "Otherwise, do nothing", but that's implied. > Yoav > > [1] > http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#processing-the-image-candidates -- Simon Pieters Opera Software From bhsu at google.com Mon Sep 23 13:25:02 2013 From: bhsu at google.com (Bolin Hsu) Date: Mon, 23 Sep 2013 13:25:02 -0700 Subject: [whatwg] Type strings to specify number of AAC audio channels Message-ID: <CAGYei4mLTcZHSbEoHcK+GfEpKR+cnkayODXM+pPvXGyen0sP4Q@mail.gmail.com> Since the royalty for decoding surround sound AAC is higher than stereo AAC, some platforms can decode stereo AAC but not surround sound AAC. But the type string passed to HTMLMediaElement.canPlayType(type) doesn't specify number of channels. I discussed this with some colleagues before I found this list. Has this been covered by standard? Below are some ideas came up during discussion: - Use a new codec string, such as HTMLMediaElement.canPlayType('audio/mp4; codecs="aac51"') - Add a new parameter, such as HTMLMediaElement.canPlayTYpe('audio/mp4; codecs="mp4a.40.2", channels="6") - Add new element for platform configuration. Some platforms can only output stereo audio, so the surround sound is down mixed to stereo. This can potentially query the platform if it can really output 6 simultaneous audio streams, amount other things: HTMLNewElement.getCapability('audio') Thanks, Bolin From ian at hixie.ch Mon Sep 23 13:25:40 2013 From: ian at hixie.ch (Ian Hickson) Date: Mon, 23 Sep 2013 20:25:40 +0000 (UTC) Subject: [whatwg] Window and WindowProxy In-Reply-To: <5211BE6E.1000608@mit.edu> References: <520112A5.8070707@mit.edu> <alpine.DEB.2.00.1308061813150.27623@ps20323.dreamhostps.com> <52014495.8070609@mit.edu> <alpine.DEB.2.00.1308072112450.27623@ps20323.dreamhostps.com> <5203162F.8000006@mit.edu> <alpine.DEB.2.00.1308080607150.27623@ps20323.dreamhostps.com> <52037F6C.2000805@mit.edu> <alpine.DEB.2.00.1308081831300.27623@ps20323.dreamhostps.com> <5203F3B0.4000908@mit.edu> <alpine.DEB.2.00.1308082052130.27623@ps20323.dreamhostps.com> <52041E62.6050007@mit.edu> <alpine.DEB.2.00.1308132005090.27623@ps20323.dreamhostps.com> <5211BE6E.1000608@mit.edu> Message-ID: <alpine.DEB.2.00.1309231909460.12199@ps20323.dreamhostps.com> On Mon, 19 Aug 2013, Boris Zbarsky wrote: > > What Gecko does is that there is a set of canonical prototypes (the DOM > ones, Object.prototype, Array.prototype, etc) per global. The effective > script origin of a global is mutable. The effect of changing the > effective script origin of a global on the prototypes associated with > that global is that nothing at all happens to them: they stay as the > same objects. > > Now what happens to actual objects and their proto chains when they go from > being same-effective-script-origin to not or back... I'm not actually sure. > Bobby Holley probably knows, though; I think this is basically the situation > he's talking about in > <https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701#c38>. Isn't the answer to this question basically the answer to this thread? This new ES5/ES6 stuff all goes over my head, to be honest. I can't wrap my head around the implications, especially in a multi-global (let alone multi-origin) environment. Is there any chance people who do understand this stuff can tell me what it should do? Ideally people from more than one browser vendor, since all the browsers disagree and I get really different answers when I speak 1:1 to individuals from various browser vendors. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Mon Sep 23 13:35:25 2013 From: ian at hixie.ch (Ian Hickson) Date: Mon, 23 Sep 2013 20:35:25 +0000 (UTC) Subject: [whatwg] Forms-related feedback In-Reply-To: <CADnb78iNqA1d95Nb2HY3Djf0hu4KT5HHk_abk3jC6_W3r=xQOw@mail.gmail.com> References: <50AB6E5F.5050803@lamouri.fr> <Pine.LNX.4.64.1211201954290.26354@ps20323.dreamhostps.com> <CAGH7WqGBtP=kP4pBBmeY5cGT=t0W-1gMt+Efx_umEs9rMGYG4Q@mail.gmail.com> <alpine.DEB.2.00.1307122134270.30095@ps20323.dreamhostps.com> <CAGH7WqHPBsEPMvNhHjV9xE6GXOyVngykHnjeTiWuLLXtJH2tnA@mail.gmail.com> <CADnb78iNqA1d95Nb2HY3Djf0hu4KT5HHk_abk3jC6_W3r=xQOw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309232026140.12199@ps20323.dreamhostps.com> On Wed, 21 Aug 2013, TAMURA, Kent wrote: > On Sat, Jul 13, 2013 at 6:39 AM, Ian Hickson <ian at hixie.ch> wrote: > > On Wed, 9 Jan 2013, TAMURA, Kent wrote: > > > On Wed, Nov 21, 2012 at 7:51 AM, Ian Hickson <ian at hixie.ch> wrote: > > > > On Fri, 7 Sep 2012, TAMURA, Kent wrote: > > > > > > > > > > * For date, datetime, datetime-local, month, time, week, the > > > > > attribute returns a string in a field. If a field is > > > > > text-editable, it should return user-editing string like email > > > > > and number. If a field has a fixed localized date/time string > > > > > chosen by a date/time picker, the attribute should return the > > > > > localized string. [...] > > > > > > > > > > - We can enable text field selection APIs for email, number, and > > > > > other types > > > > > > > > How would this work when the control isn't a text control? I don't > > > > understand. For example, consider a date control that is actually > > > > three separate text fields (year month day); how do you envisage > > > > the selection API working and how would rawValue help with this? > > > > > > I think it's ok that rawValue doesn't work with form controls > > > without any text. One of use cases of rawValue would be to handle > > > user input errors. I think non-text form controls should be clever > > > enough to avoid bad user input. For example, users can't set bad > > > values to input[type=range]. > > > > I still don't understand how this would work. You suggest that it > > should work for type=date, but how? What happens when it's mutated by > > script, for instance? I really don't understand the purpose here or > > how it would work to achieve that purpose. > > As for type=date, rawValue should return what a user see. What if the user sees a calendar with a date circled? Or the string "your birthday"? (Exposing that would be a privacy violation.) Or what if the user doesn't see anything (because it's not a visual UA), but every time the user focuses it, the user agent plays a tune from one of Vivaldi's four seasons, followed by a trill to indicate how far into the season the date is? > Value set by script or not doesn't matter. I mean, how would the user agent parse the script's new value. > I saw some questions/requests of a way to get a localized date string in > crbug.com and stackoverflow.com. One of reasons one wanted to get it > was that there are no ways for script to get localized date format used > in type=date. One wanted to get the format to use consistent date format > in a web page, another wanted to get the format to focus on specific > field in type=date (Note that a type=date instance in Google Chrome > contains multiple focus targets.) Providing localisation is definitely something we should do, but rawValue isn't a sane way to do it. You don't want to have the "format a date" API be "create an <input> element, sets its value, and read it back". > As for type=number, I heard a web author wanted to get invalid value > typed by a user in order to show friendly error message without HTML > interactive form validation. The point of type=number is that the browser can do this, no need to reimplement it. (If an author does want to reimplement it, Web Components are presumably the long-term solution: reimplement the widget.) > > > > On Tue, 11 Sep 2012, TAMURA, Kent wrote: > > > > > > > > > Yes, I'd like to enable selection API for at least type=email > > > > > and type=number. All of their existing implementations are text > > > > > fields. I haven't seen a request to suport selection API for > > > > > type=email, etc.. However lack of selection API looks a defect > > > > > to me. > > > > > > > > Why does the page need to touch the selection? > > > > > > It must be same as input[type=text]. e.g. > > > - A page author wants to select the whole value or nothing of an > > > email form control when it gets focus. > > > > Why is that a valid thing for a page to be doing? The browser should > > take care of doing that, not the page. If the page does it, it'll be > > different on each page and the user will get confused. > > We can't force it. Web authors do what they want. We can force it. If we don't provide the API, the author can't do it. > https://code.google.com/p/chromium/issues/detail?id=263910#c3 > This is an actual case. I talked with him, and he said <datalist> > didn't work in his case because he wanted to show images on choices. The demo he gives is: https://chromium.googlecode.com/issues/attachment?aid=2639100003000&name=caret.html&token=tDkJ1CbBJ1hhXbsgb9Y0MRMzlks%3A1379968341420 If people want to reimplement widgets, then we should make sure Web Components can support their particular widget desires. I don't think it makes sense for us to make the default widgets be able to support every weird thing people want to do. > > > - A user entered an email address with unacceptable domain name. > > > A page author wants to move the caret to the beginning of the > > > domain name. > > > > How is that possible in the case of a custom e-mail widget where the > > e-mail address isn't shown, but a user picture and name is shown > > instead? > > I think rawValue isn't necessary in such UI. However all of existing > type=email implementation is a text field. On Wed, 21 Aug 2013, Anne van Kesteren wrote: > > If we start doing this (and other things you proposed) we'll constrain > future implementation strategies for this control. And other > implementations might be forced to follow particular conventions in > order to not break sites. That doesn't seem exactly ideal. Exactly. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From bzbarsky at MIT.EDU Mon Sep 23 13:44:47 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Mon, 23 Sep 2013 16:44:47 -0400 Subject: [whatwg] Window and WindowProxy In-Reply-To: <alpine.DEB.2.00.1309231909460.12199@ps20323.dreamhostps.com> References: <520112A5.8070707@mit.edu> <alpine.DEB.2.00.1308061813150.27623@ps20323.dreamhostps.com> <52014495.8070609@mit.edu> <alpine.DEB.2.00.1308072112450.27623@ps20323.dreamhostps.com> <5203162F.8000006@mit.edu> <alpine.DEB.2.00.1308080607150.27623@ps20323.dreamhostps.com> <52037F6C.2000805@mit.edu> <alpine.DEB.2.00.1308081831300.27623@ps20323.dreamhostps.com> <5203F3B0.4000908@mit.edu> <alpine.DEB.2.00.1308082052130.27623@ps20323.dreamhostps.com> <52041E62.6050007@mit.edu> <alpine.DEB.2.00.1308132005090.27623@ps20323.dreamhostps.com> <5211BE6E.1000608@mit.edu> <alpine.DEB.2.00.1309231909460.12199@ps20323.dreamhostps.com> Message-ID: <5240A83F.8010608@mit.edu> On 9/23/13 4:25 PM, Ian Hickson wrote: > Isn't the answer to this question basically the answer to this thread? I've lost track of what the "question" in this thread is... > This new ES5/ES6 stuff all goes over my head, to be honest. I can't wrap > my head around the implications, especially in a multi-global (let alone > multi-origin) environment. OK. > Is there any chance people who do understand this stuff can tell me what > it should do? I'm trying, sort of. ;) > Ideally people from more than one browser vendor, since all > the browsers disagree and I get really different answers when I speak 1:1 > to individuals from various browser vendors. Mmm... Sounds like we need some venue for standardizing this stuff or something. -Boris From ian at hixie.ch Wed Sep 25 16:23:36 2013 From: ian at hixie.ch (Ian Hickson) Date: Wed, 25 Sep 2013 23:23:36 +0000 (UTC) Subject: [whatwg] Navigation and history traversal issues In-Reply-To: <52160486.4040908@ado.is-a-geek.net> References: <CAFWcpZ51Zp-FQD06mHzfdNKbYrgcT9DOB+c12a2vA3EPyGbbHA@mail.gmail.com> <Pine.LNX.4.64.1209172122440.27765@ps20323.dreamhostps.com> <52160486.4040908@ado.is-a-geek.net> Message-ID: <alpine.DEB.2.00.1309232046350.12199@ps20323.dreamhostps.com> On Thu, 22 Aug 2013, Andrew Oakley wrote: > On 19/09/12 01:18, Ian Hickson wrote: > > > > I've changed the spec so that traversing the history by a delta always > > cancels any pending navigations unless you're in the middle of an > > unload, in which case it just aborts the algorithm entirely. > > > > I've also made back()/forward()/go() not work during the document's > > unload handler, since that could be used for griefing. I'm tempted to > > disable it entirely for all docs a la alert(), but I've no idea if > > that's Web- compatible and I suspect not. > > I assume this is where steps 3 and 4 of the "traverse the history by a > delta" algorithm came from. Step 3. Step 4 is about canceling an existing navigation if you hit back. > It's not clear from the spec which browsing context and document these > steps refer to. Is it the "specified browsing context" and the active > document of that context (I think that makes most sense)? Hm. I meant it to be the Document of the History object, but you raise an interesting point. This whole thing is rather poorly defined. I've tried to clear it up. > Additionally it isn't clear which event loop the task should be > associated with. I've tried to clear this up too. It turns out this wasn't taking into account per-frame process isolation, anyway. I had to introduce yet another kind of event loop. This does introduce some race conditions in UAs with more than one event loop per tab, but I don't know what we can do about that without adding in a lot of blocking during traversal, which I am guessing wouldn't be popular. > > Aah, ok. The spec already says that's not allowed. You can't get to > > the History object of a cross-origin Window: > > > > http://www.whatwg.org/specs/web-apps/current-work/#security-window > > > > (I forget what the story is if you get a History object from a > > same-origin Window, then have the browsing context navigated, then use > > the History object you kept around... I expect it is supposed to work > > much as if you were to call it on the new, cross-origin, History > > object, though.) > > The implication here as that you should never be able to do a history > traversal of a browsing context that is not same origin (and so there is > only one event loop to choose from). The "story" about keeping history > objects around seems does not seem to be specified anywhere (so the > assumption was that it should work as normal). > > It looks like some browsers don't let you use history objects you kept > around (they should probably throw an InvalidStateError), others let you > use them if the current document of the relevant browsing context is > same-origin (and should probably throw a SecurityError). > > It's rather awkward to test this, but can we have something in the spec > to prevent cross-origin history traversal? If this is not in the same > section as the "traverse the history by a delta" algorithm can we have a > note to say that this can never happen cross-origin? Well, no, not really, because it can. For example, if you have an iframe that's cross-origin, and it's navigated, and then you call your own History object's back() method, it'll actually traverse that iframe. But a History object of a non-active Document is a different matter... Looks like this will need help from WebIDL. I've filed bug 23359 and marked it as blocked on bug 23358: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23359 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23358 -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From me at kylehuey.com Wed Sep 25 20:00:55 2013 From: me at kylehuey.com (Kyle Huey) Date: Thu, 26 Sep 2013 11:00:55 +0800 Subject: [whatwg] [Workers] CSP and SharedWorkers Message-ID: <CAP045ApN_NPZEO3X=nNbL1eh4rGWJQya3AT49JwW5h2YeVbmJg@mail.gmail.com> It's unclear how SharedWorkers should interact with Content Security Policies. This came up during code review of the SharedWorker implementation in Gecko[0]. There was a public-webappsec thread[1] on this back in May that didn't really reach a conclusion and I'd like to drive towards one here. Because CSPs are associated with a document, and multiple documents can connect to the same SharedWorker, it is unclear which CSP should be used by a SharedWorker. Furthermore, there are plans to introduce Service Workers ( *n?e* Event Pages) which come into existence before any document exists for the origin at all. It seems like the best solution to this problem is to associate a CSP directly with the worker from the headers served when the JS file for the worker is shipped down. Giving them their own CSP solves the "what CSP do I use" problem. I don't have strong feelings about whether or not we should deny a page with a more liberal CSP from connecting to a SharedWorker with a more strict CSP, but I suspect others might. If we choose to do this we should also think about whether we should do the same for regular workers. The same JS file and the same headers being run under different policies if you do Worker(foo.js) and SharedWorker(foo.js) seems unexpected. We could make regular workers default to the document CSP if nothing is specified for backwards compatibility. Thoughts? - Kyle [0] https://bugzilla.mozilla.org/show_bug.cgi?id=643325 [1] http://lists.w3.org/Archives/Public/public-webappsec/2013May/0054.html From annevk at annevk.nl Thu Sep 26 05:53:30 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Thu, 26 Sep 2013 08:53:30 -0400 Subject: [whatwg] [Workers] CSP and SharedWorkers In-Reply-To: <CAP045ApN_NPZEO3X=nNbL1eh4rGWJQya3AT49JwW5h2YeVbmJg@mail.gmail.com> References: <CAP045ApN_NPZEO3X=nNbL1eh4rGWJQya3AT49JwW5h2YeVbmJg@mail.gmail.com> Message-ID: <CADnb78hhcaVj-N+3aboXAPnv+ZKTehKJh5r=8RwMXxT0qQ1nDg@mail.gmail.com> On Wed, Sep 25, 2013 at 11:00 PM, Kyle Huey <me at kylehuey.com> wrote: > Thoughts? What happens today for <iframe>? The load itself seems to be governed by the parent. Does the policy inherit into it? I feel like workers should work like <iframe> as they're essentially their own global objects. -- http://annevankesteren.nl/ From jaffathecake at gmail.com Thu Sep 26 06:57:33 2013 From: jaffathecake at gmail.com (Jake Archibald) Date: Thu, 26 Sep 2013 14:57:33 +0100 Subject: [whatwg] [Workers] CSP and SharedWorkers In-Reply-To: <CADnb78hhcaVj-N+3aboXAPnv+ZKTehKJh5r=8RwMXxT0qQ1nDg@mail.gmail.com> References: <CAP045ApN_NPZEO3X=nNbL1eh4rGWJQya3AT49JwW5h2YeVbmJg@mail.gmail.com> <CADnb78hhcaVj-N+3aboXAPnv+ZKTehKJh5r=8RwMXxT0qQ1nDg@mail.gmail.com> Message-ID: <CAJ5xic8=j61sYjffVj0UEMP5zgMc2sbEr6NX5658Tm4Zb8v4iQ@mail.gmail.com> The registration of a Service Worker is currently only possible via DOM call from an HTML document, so it makes sense for registration to be governed by CSP. There was some discussion here https://github.com/slightlyoff/ServiceWorker/issues/46 So script-src would cover registration, but there was also suggestion that x-domain controllers would be disallowed be default, and enabled by script-src or perhaps an additional controller-src CSP directive. Note, this only covers registration. If http://example.com allows controllers from http://example.co.uk, and successfully calls registerServiceWorker("/*", "http://example.co.uk/service.js"), that controller will be used for all top-level fetches on http://example.com, and all fetches originating from documents on http://example.com, regardless of their CSP headers. The browser will re-fetch (ugrade) and continue to use http://example.co.uk/service.js even if the CSP rules are changed to disallow controllers from that url. But if a page attempts to register a new controller, the url must be allowed by CSP. Does script-src apply to importScripts in Workers currently? The spec doesn't explicitly mention it, feels like it should. I don't have a strong opinion on whether Workers should have their own CSP. Seems sensible for SharedWorkers to obey their own CSP headers and ignore those of the constructing/registering page (except for the actual constructing/registering of course). script-src should apply for importScripts and imported scripts would use the rules of the top-level SharedWorker. connect-src should also apply to fetch ( https://github.com/slightlyoff/ServiceWorker/blob/master/service_worker.ts#L193 ). On 26 September 2013 13:53, Anne van Kesteren <annevk at annevk.nl> wrote: > On Wed, Sep 25, 2013 at 11:00 PM, Kyle Huey <me at kylehuey.com> wrote: > > Thoughts? > > What happens today for <iframe>? The load itself seems to be governed > by the parent. Does the policy inherit into it? I feel like workers > should work like <iframe> as they're essentially their own global > objects. > > > -- > http://annevankesteren.nl/ > From jaffathecake at gmail.com Thu Sep 26 07:28:11 2013 From: jaffathecake at gmail.com (Jake Archibald) Date: Thu, 26 Sep 2013 15:28:11 +0100 Subject: [whatwg] [Workers] CSP and SharedWorkers In-Reply-To: <CAJ5xic8=j61sYjffVj0UEMP5zgMc2sbEr6NX5658Tm4Zb8v4iQ@mail.gmail.com> References: <CAP045ApN_NPZEO3X=nNbL1eh4rGWJQya3AT49JwW5h2YeVbmJg@mail.gmail.com> <CADnb78hhcaVj-N+3aboXAPnv+ZKTehKJh5r=8RwMXxT0qQ1nDg@mail.gmail.com> <CAJ5xic8=j61sYjffVj0UEMP5zgMc2sbEr6NX5658Tm4Zb8v4iQ@mail.gmail.com> Message-ID: <CAJ5xic9wJf54vO9gaGXqhNNZ6LhaTBPhMy3GTab2jk5XgBY+eA@mail.gmail.com> On 26 September 2013 14:57, Jake Archibald <jaffathecake at gmail.com> wrote: > Note, this only covers registration. If http://example.com allows > controllers from http://example.co.uk, and successfully calls > registerServiceWorker("/*", "http://example.co.uk/service.js"), that > controller will be used for all top-level fetches on http://example.com, > and all fetches originating from documents on http://example.com, > regardless of their CSP headers. > Oops, that's misleading, I mean the existing worker will be used for all fetches even if the CSP rule of the page has changed to disallow registering of that worker. The CSP of the page will still govern script loading, XHR etc. If the page's CSP disallows a resource from a particular URL, it won't consult the worker at all. If the page requests an allowed url, and the worker serves up a response (cached or otherwise) from a not-allowed url, CSP should block it. (apologies for saying "controller" when I mean "service worker") From benjamin at smedbergs.us Thu Sep 26 08:19:10 2013 From: benjamin at smedbergs.us (Benjamin Smedberg) Date: Thu, 26 Sep 2013 11:19:10 -0400 Subject: [whatwg] Supporting scanners on the web Message-ID: <5244506E.3020808@smedbergs.us> One of the use cases that has come up for why people are still using plugins is supporting scanning to the web, in particular multi-page scanning. It seems to me that we could hook this up to <input type="file" multiple>, but that we should try to provide UAs with a hint that a page expects a document instead of images. This primarily may affect whether/how the browser presents a scanner option to the user in addition to or instead of camera/photos when selecting an image. A couple questions I've thought about but don't have answers to: * Do/can PNG images contain information about their resolution, so that the site can reconstruct the actual page size? * Should we give the site any way to specify preferred resolution or color depth for an image? Or should the site be prepared process any images to the required resolution, convert to monochrome, etc. * Should the spec recommend any specific MIME types for scanner page images? Most desktop scanners appear to default to .tiff, but that's not a normal web format: perhaps we should recommend that UAs convert to PNG. --BDS From annevk at annevk.nl Thu Sep 26 10:31:01 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Thu, 26 Sep 2013 13:31:01 -0400 Subject: [whatwg] Supporting scanners on the web In-Reply-To: <5244506E.3020808@smedbergs.us> References: <5244506E.3020808@smedbergs.us> Message-ID: <CADnb78j+8J+eML0d_RwaJKa2+RUCSsbowzkCWVUOy-LrH+y06g@mail.gmail.com> On Thu, Sep 26, 2013 at 11:19 AM, Benjamin Smedberg <benjamin at smedbergs.us> wrote: > One of the use cases that has come up for why people are still using plugins > is supporting scanning to the web, in particular multi-page scanning. It > seems to me that we could hook this up to <input type="file" multiple>, but > that we should try to provide UAs with a hint that a page expects a document > instead of images. This primarily may affect whether/how the browser > presents a scanner option to the user in addition to or instead of > camera/photos when selecting an image. > > A couple questions I've thought about but don't have answers to: > > * Do/can PNG images contain information about their resolution, so that the > site can reconstruct the actual page size? > * Should we give the site any way to specify preferred resolution or color > depth for an image? Or should the site be prepared process any images to the > required resolution, convert to monochrome, etc. > * Should the spec recommend any specific MIME types for scanner page images? > Most desktop scanners appear to default to .tiff, but that's not a normal > web format: perhaps we should recommend that UAs convert to PNG. So what do the plugins do here (pointers to the plugins?)? It seems if we want to replace these plugins, knowing what they do would be a great start. -- http://annevankesteren.nl/ From ian at hixie.ch Thu Sep 26 11:41:03 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 26 Sep 2013 18:41:03 +0000 (UTC) Subject: [whatwg] OUTPUT tag: clarify purpose in spec? In-Reply-To: <52191C14.8060700@kennardconsulting.com> References: <52191C14.8060700@kennardconsulting.com> Message-ID: <alpine.DEB.2.00.1309261831420.12199@ps20323.dreamhostps.com> On Sun, 25 Aug 2013, Richard Kennard wrote: > > Thanks for all the great work you do on the HTML 5 specification! > > Can I ask for a little clarification in the spec? Specifically it says: > > "The output element represents the result of a calculation or user > action." > http://www.w3.org/TR/html5/forms.html#the-output-element > > It is my understanding (or hope!) that the output tag fills a hole in > form markup. For example, if this is the editable version of a form: > > <label for="name">Name:</label><input id="name" type="text" value="Bob"> > > Then this can be its read-only variant: > > <label for="name" value="Name:"><output id="name">Bob</output> No, the readonly variant would be: <label for="name">Name:</label><input id="name" type="text" value="Bob" readonly> > Essentially, I am taking 'result of a calculation' to include 'values looked > up from database, REST call, etc'. Is that correct? I guess. I meant more actual calculations rather than just lookups, but lookups can be the results of "user action", so... There's a lot of <output> examples in the spec; do they help at all? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jkorpela at cs.tut.fi Thu Sep 26 13:00:16 2013 From: jkorpela at cs.tut.fi (Jukka K. Korpela) Date: Thu, 26 Sep 2013 23:00:16 +0300 Subject: [whatwg] OUTPUT tag: clarify purpose in spec? In-Reply-To: <alpine.DEB.2.00.1309261831420.12199@ps20323.dreamhostps.com> References: <52191C14.8060700@kennardconsulting.com> <alpine.DEB.2.00.1309261831420.12199@ps20323.dreamhostps.com> Message-ID: <52449250.9080609@cs.tut.fi> 2013-09-26 21:41, Ian Hickson wrote: > There's a lot of <output> examples in the spec; do they help at all? There are indeed several examples, but they are scattered around; the section that specifically deals with the <output> element, 4.10.15, has only one example. It is a simple calculator that shows the calculated result in an <output> element. And it is a form with no action attribute and with onsubmit="return false", so it is clearly meant to work in the browser only. That is, the value of the output element is not submitted. The question then arises why <output> is used, instead of just showing the result in a <span> or <div> element as usual. In fact, none of the examples about <output> have no apparent association with any submission to server-side processing. Yet, the from the properties defined for <output>, whole point seems to be that the <output> element has a special purpose: it is a control, with a value that may be included in form data upon submission, but its value is not meant to be changed by the user directly, only via actions that may indirectly modify it. Simultaneously, it is normally visible to the user. As I see it, the difference between <output> and a readonly <input> is that the latter is not meant to be changed by the user *at all*, whereas <output> is not be changed *directly*. If this interpretation is correct, I think some of it should be somehow expressed in the spec, and there should be at least one example where <output> is seemingly participating in form data submission. It's of course too late to change the name "output" now, but it is really misleading, since it suggests that the element is just for output (possibly even suggesting that it's really a duplicate of <samp>!). Yet it seems that it primarily computed data (in a broad sense for "computed") to be submitted, though it can, like <input>, be used without submission too. So <computed> or <input type=computed> might have been better. I mention this because this name problem emphasizes the need for explaining what the element is really for. I still don't quite see *why* <output> has been introduced. I can understand it as a purely logical creation, but what is the practical gain expected to be? Yucca From ian at hixie.ch Thu Sep 26 15:15:41 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 26 Sep 2013 22:15:41 +0000 (UTC) Subject: [whatwg] Comments on <dialog> In-Reply-To: <CANMdWTtM00BSP0qFShRfRXQOa9W-0T6Km+zicxekykqWi2F7WA@mail.gmail.com> References: <CAJ_xCi=dZeocSKh=okFnwVfq15PfXQUNsrtOxLQ4Y1yyM_wQdg@mail.gmail.com> <Pine.LNX.4.64.1304221922420.18848@ps20323.dreamhostps.com> <661F94F1-F67E-4AE6-87C0-AA0CAF9B57FF@apple.com> <alpine.DEB.2.00.1308270030250.28417@ps20323.dreamhostps.com> <CANMdWTtM00BSP0qFShRfRXQOa9W-0T6Km+zicxekykqWi2F7WA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309261841150.12199@ps20323.dreamhostps.com> On Mon, 26 Aug 2013, Matt Falkenhagen wrote: > On Thu, Aug 22, 2013 at 7:58 AM, Ian Hickson <ian at hixie.ch> wrote: > > On Mon, 22 Apr 2013, Tab Atkins Jr. wrote: > > > On Mon, Apr 22, 2013 at 12:38 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > On Mon, 22 Apr 2013, Matt Falkenhagen wrote: > > > >> 3. For centering in the viewport, the spec mandates that the used > > > >> value of 'top' be specially calculated. I found it more > > > >> convenient to implement by mutating the computed value rather > > > >> than the used value. This has the added benefit that it's > > > >> straightforward for the page author to implement dragging using > > > >> getComputedStyle. > > > > > > > > The computed value can't rely on layout, since it's used for > > > > inheritance, which can happen without layout, if I'm not mistaken. > > > > > > Matt means that we, the browser, explicitly set the computed value to > > > whatever's appropriate, based on layout values at the time that .show() > > > is called. (Done either by setting values in the override stylesheet, or > > > by manipulating the style attribute on the element. Probably the latter, > > > because there's no guarantee we can uniquely target the dialog via a > > > selector.) > > > > I don't really think this makes any sense. For example, it wouldn't handle > > viewport video changes as it's currently described. > > > > The way the spec is defined now, it's the static position that is set -- > > the 'top' property is unaffected except indirectly by its dependency on > > the static position. What's wrong with that? > > Can you elaborate on what viewport video changes are and what the > problem is? I think I meant viewport width changes, sorry. As in, when you resize the viewport, it would either fail to move the dialog, or it would override the user's move, depending on how we implemented this, without the author really being able to do anything about it. The way the spec is written now, you can still trivially implement dragging; you just set 'top' appropriately based on the element's position. Then, onresize or whenever you want to revert to the default position, you remove the 'top' property. It all just works. I don't really see the problem here. > It may not be a strong reason to change the spec, but in my experience, > implementing this in terms of static position in WebKit/Blink was very > challenging. As an example of the challenge, normally static position > is computed for a box during its layout, which is too early for dialog: > the dialog's dimensions must be known in order to center it, so it must > have been laid out already. How does this differ from, e.g., computing 'auto' margins of shrink-wrapped blocks? > Changing the static position after layout breaks much assumptions in the > code and would seem to require invasive work across the render tree, > layer tree, possibly painting, etc. In contrast, if CSS is manipulated > after the first layout pass, the layout engine just works. So I found it > convenient and stable to mutate CSS 'top' directly. I don't think mutating attributes is a sane approach to doing this. It feels like a hack, it interferes with author affordances, it makes it harder for us to distinguish script-set property values from UA-set property values, it makes it harder for authors to specifically override the UA, etc. > That said there have been some spec changes since my last attempt that > may make this easier, such as the dialog's cb is the icb. That also > means you can just use offsetTop/Left to implement dragging so perhaps > it's no longer helpful for getComputedStyle to return the centered top. Please do let me know if it is too difficult with the static position as defined. We could maybe consider other options like having a special computed value just for 'top', etc, the way we do for 'position'. On Tue, 27 Aug 2013, Ian Hickson wrote: > On Mon, 26 Aug 2013, Ryosuke Niwa wrote: > > On Apr 22, 2013, at 12:38 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > > > The current naming is based on window.showModalDialog() and > > > window.close(). I agree the naming is weird, but being consistent is > > > probably going to be more helpful on the long run. > > > > But that's because we have window.open but not an equivalent of > > window.close for window.showModalDialog, right? > > > > It seems more consistent to use show/hide or open/close as Matt > > suggested. > > Consistent with what? We have window.open()/window.close, and > window.showModalDialog()/window.close(). We also have > document.open()/document.close(), and so on (EventSource, etc). I > suppose we could change show() to open(), but then we'd be inconsistent > with showModalDialog() for openModal()... On Mon, 26 Aug 2013, Ojan Vafai wrote: > > IMO, showModalDialog is the legacy broken API we're stuck with. Better > to name the new thing in a way that's self-consistent and consistent > with everything else (i.e. openModal). I started doing this, since several people have asked about this and it seems the consistency between showModalDialog()/close() seems less interesting to people than the consistency with "open" everywhere else. However, it turns out this would make the show() method clash with the "open" IDL attribute on <dialog>, which we want since it matches the name of the open="" content attribute which matches <details open>. Note that window.open() and document.open() don't really do the same as this method does, either. window.open() creates a new Window, or navigates and existing one; document.open() resets the document. dialog.show() just changes the dialog to be visible. Also, there's an interesting mix in other APIs. (Disclaimer: I don't know many of these APIs personally, so I may be misinterpreting their documentation wildly. I basically looked for terms like "open" and "close" in the docs and tried to see what the right methods were in each case. I only included methods for modal dialogs if there was a trivial method; many APIs have to be configured to make dialogs modals separately.) Android uses show() and dismiss() Closure uses setVisible() Cocoa uses makeKeyAndOrderFront:, orderOut:, close, and performClose:. Delphi uses Show(), ShowModal(), Hide(), and Close(). Ext JS uses show(), hide(), and close(). jQuery uses "open" and "close". Gtk uses gtk_widget_show(), gtk_dialog_run(), gtk_window_close(). .NET uses Show(), ShowDialog(), Hide(), and Close(). Win32 uses ShowWindow() and CloseWindow(). X11 uses XMapWindow() and XUnmapWindow() Most of the APIs I looked at use "close". Most use "show". So I think we're in ok company here. I've left the spec as is. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Thu Sep 26 15:41:55 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 26 Sep 2013 22:41:55 +0000 (UTC) Subject: [whatwg] Elements should be removed from the past names map once it's no longer associated with the form element In-Reply-To: <521C0A6D.1020504@mit.edu> References: <3D1589C6-876D-4E5D-9CAC-79FB788E2F52@apple.com> <521BDC5A.7010203@mit.edu> <24F84694-2924-4176-A12C-0883C37F23DA@apple.com> <521C026D.1060400@mit.edu> <41892703-8416-4333-B683-E87086605EEE@apple.com> <521C0A6D.1020504@mit.edu> Message-ID: <alpine.DEB.2.00.1309262238260.12199@ps20323.dreamhostps.com> On Mon, 26 Aug 2013, Ryosuke Niwa wrote: > > I propose to change the specification to remove any elements that are no > longer associated with the form from the past names map: > http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#past-names-map > > It's strange for elements to linger around forever in the past names map > after the element get associated with a new form element. Since IE > didn't support form attribute for a long time (or maybe still hasn't?), > I don't think there is any compatibility concern. > > The change makes the elements associated with the form element more > consistent and easier to reason about. We can make form[x].form === > form an invariant for every x such that form[x] is a form control > element. This was fixed in response to: On Mon, 26 Aug 2013, Boris Zbarsky wrote: > > I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=23073 Let me know if there's still something to fix here. Note that there's no need to file a bug if feedback on the spec is sent to the list; I treat them both as input to the spec. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Thu Sep 26 15:45:42 2013 From: ian at hixie.ch (Ian Hickson) Date: Thu, 26 Sep 2013 22:45:42 +0000 (UTC) Subject: [whatwg] Canonical Image and Color In-Reply-To: <CAJGQg4H8UdQvh1f5vphEAVAxzWufp5kAV-mMrOO8HLypEcweFQ@mail.gmail.com> References: <CAJGQg4EwgYOqf5y67Q_=WN=UewBZvkXzs5ZG8wQDrD2AM3GGnQ@mail.gmail.com> <CAAWBYDC_T=-GgUtpyApWUsaQ3yDuHvQiZKg0BzB8e44RZedGZw@mail.gmail.com> <CAJGQg4FY4WHvCK09dG=Fs=_w31oEuJ-CaraNH7uMhCxjYbmhyQ@mail.gmail.com> <alpine.DEB.2.00.1307121730320.15729@ps20323.dreamhostps.com> <CAJGQg4H8UdQvh1f5vphEAVAxzWufp5kAV-mMrOO8HLypEcweFQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309262243040.12199@ps20323.dreamhostps.com> On Wed, 28 Aug 2013, Brian Blakely wrote: > On Fri, Jul 12, 2013 at 1:32 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > You are welcome to register these on the wiki and convince people to > > use them, sure. > > Would you kindly link me to the wiki? http://wiki.whatwg.org/wiki/MetaExtensions -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jrburke at gmail.com Thu Sep 26 18:15:28 2013 From: jrburke at gmail.com (James Burke) Date: Thu, 26 Sep 2013 18:15:28 -0700 Subject: [whatwg] Notifications: usage feedback Message-ID: <CAHgY_ifiJ-mjci7xAAasUTqM_jLVCzL9CwQuRJOe9LO8JbS=Gg@mail.gmail.com> This Notifications feedback comes from using them in FirefoxOS for the email web app. It uses an alarm API to periodically wake up, do an email sync, and if new messages, creates some Notifications. The web app may also shut itself down if it was not already opened in a visible state. The OS may also decide to kill it to use the memory for some other app. 1) Ability to pass data with the Notification Right now, we URL-encode some args to the iconURL to pass data to the handler function that is registered via navigator.mozSetMessageHandler('notification', function(){}) [1]. It would be better if I could just pass a JSON-friendly data object to Notification instance and then have access to that data in the notification callbacks that are triggered. We cannot depend on notification.onclick to work since the app can be closed after the notification is fired. It also seemed very unreliable to depend on it, given garbage collection possibilities. So we cannot reliably capture state using a function closure. 2) General notification callback entry point We are avoiding use of notification.onclick/onclose and would prefer to have a generic entry point to receive notification events. Right now we use navigator.mozSetMessageHandler('notification', function(){}). but I would prefer to see a more official entry point in the spec. I would go so far as to want to deprecate the .onclick and .onclose as in practice they are not reliable, given that the app may be closed down after firing the Notification but before it is clicked. 3) onclick fires onclose too? It seemed a bit unclear in the spec, but right now FirefoxOS fires onclose too for onclick actions, as the onclick pathway removes the notification from the list of notifications. This seems counterintuitive to me, I would have only expected one event. Perhaps clarifying the onclick behavior would be good. I would prefer to just see one event fired in this case, if onclick/onclose are kept around. If the general notification callback entry point is established, then just firing it once with the event.clicked property set to true for the clicked route. 4) onclick does not bring web app to front This may be part of just further defining the steps for the "click" pathway in the spec, but at least in FirefoxOS right now, the notification onclick pathway does not bring the app to the visible front in all cases. The email app has to do some extra document.hidden checking and try to bring itself to the front. What I would rather see is by default the web page is brought to the visible front, and then perhaps allow the app a way to cancel that behavior perhaps via a preventDefault() type of mechanism on any notification click event. This would also reduce the need for an API that the app could call to bring itself "to the visible front". Right now, there is an app.launch() API in FirefoxOS for this, but there are concerns that giving apps the ability to launch themselves to the front could lead to an abuse of that API. 5) Ability to set notification modes. This one is a bit less defined. I would rather this one is discarded than spending too much time on it if it meant losing track of the points above: For email notifications, we did not necessarily want the phone to light up the screen on every notification and make a sound or vibrate (particularly at night), but rather just register the notification and have it show up in the notification count and listing. While ideally there is UI for the user to control notification behavior for all web apps, I can also see the case for allowing notifications the ability to opt in to the notification modes it prefers. Any user settings would override the modes specified in the notification, but for apps that did want to be nice, it would be a way to avoid a very annoying first notification behavior, in the case of email, not disturbing the user unless they did an explicit override. This may be too tricky to specify, but I started a bugzilla bug for FirefoxOS for this[2]. One suggestion was listing the preferred modes in the web app manifest, but I can see an app may have different types of notifications, so it would be more flexible to set per Notification instance. There is a dev-gaia thread[3] that prompted this feedback. [1] https://developer.mozilla.org/en-US/docs/Web/API/window.navigator.mozSetMessageHandler [2] https://bugzilla.mozilla.org/show_bug.cgi?id=912645 [3] https://groups.google.com/forum/#!topic/mozilla.dev.gaia/NVacmcxGt2Q James From robert at ocallahan.org Thu Sep 26 19:11:34 2013 From: robert at ocallahan.org (Robert O'Callahan) Date: Fri, 27 Sep 2013 14:11:34 +1200 Subject: [whatwg] Supporting scanners on the web In-Reply-To: <5244506E.3020808@smedbergs.us> References: <5244506E.3020808@smedbergs.us> Message-ID: <CAOp6jLZj7o4S-qA4g5hs0rhj6UApX-hANMbLDzZd1pfjXmktGw@mail.gmail.com> On Fri, Sep 27, 2013 at 3:19 AM, Benjamin Smedberg <benjamin at smedbergs.us>wrote: > A couple questions I've thought about but don't have answers to: > > * Do/can PNG images contain information about their resolution, so that > the site can reconstruct the actual page size? > Yes: http://www.scantips.com/basics9p.html > * Should we give the site any way to specify preferred resolution or color > depth for an image? Or should the site be prepared process any images to > the required resolution, convert to monochrome, etc. > That sounds useful. These values could be just hints. * Should the spec recommend any specific MIME types for scanner page > images? Most desktop scanners appear to default to .tiff, but that's not a > normal web format: perhaps we should recommend that UAs convert to PNG. > PNG sounds good given it's lossless and ubiqutious. Apps can transcode to JPEG (or any other format the browser supports encoding of) on the client if they want to. Is implementing a full scanning UI in a Web app in scope or out of scope? If it's in scope, then we'd need the ability to display incremental scan results, and we'd need to be able to do a preview vs full-view scan, and control the area scanned. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * From jonas at sicking.cc Thu Sep 26 20:52:15 2013 From: jonas at sicking.cc (Jonas Sicking) Date: Thu, 26 Sep 2013 20:52:15 -0700 Subject: [whatwg] [Workers] CSP and SharedWorkers In-Reply-To: <CAP045ApN_NPZEO3X=nNbL1eh4rGWJQya3AT49JwW5h2YeVbmJg@mail.gmail.com> References: <CAP045ApN_NPZEO3X=nNbL1eh4rGWJQya3AT49JwW5h2YeVbmJg@mail.gmail.com> Message-ID: <CA+c2ei81phQ4AmGP0wWgmoWSwbWtn5pFtH49NJceNQN0dsCroQ@mail.gmail.com> On Wed, Sep 25, 2013 at 8:00 PM, Kyle Huey <me at kylehuey.com> wrote: > It's unclear how SharedWorkers should interact with Content Security > Policies. This came up during code review of the SharedWorker > implementation in Gecko[0]. There was a public-webappsec thread[1] on this > back in May that didn't really reach a conclusion and I'd like to drive > towards one here. For both Shared Workers and Service Workers is seems pretty clear that we can't "inherit" the policy of the loading document. Any such constructs would feel non-sensical in too many situations. So here I think we should let the worker get its CSP from the script load itself. With Dedicated Workers we could in theory inherit the policy of loading document, but it feels like that creates a lot of inconsistency with Shared/Service Workers. So my off-the-top-of-my-head suggestion would be to always let workers get the CSP from the script load. Though one question is what to do for workers loaded from blob:, data: or filesystem:. Maybe we should disallow shared/service workers from those types of URLs, and make dedicated workers inherit the CSP when loaded from those URLs. Though I could see shared workers from filesystem: being useful. What do implementations do with regards to linking <script> to blob/data/filesystem? Are they treated like normal protocols, or are they treated like eval()? If they are treated like normal protocols then maybe we can simply not have any special rules for them and say that for now they never get a CSP. > I don't have strong feelings about whether or not we should > deny a page with a more liberal CSP from connecting to a SharedWorker with a > more strict CSP, but I suspect others might. What do we do for <iframe>s here. If nothing then I don't think we should do anything for workers either. / Jonas From jonas at sicking.cc Thu Sep 26 22:29:32 2013 From: jonas at sicking.cc (Jonas Sicking) Date: Thu, 26 Sep 2013 22:29:32 -0700 Subject: [whatwg] Supporting scanners on the web In-Reply-To: <5244506E.3020808@smedbergs.us> References: <5244506E.3020808@smedbergs.us> Message-ID: <CA+c2ei8HOxZJ-sN0NM6zxbt+4=bFwfWMTxyM0+iXsHJmgX8wQQ@mail.gmail.com> On Thu, Sep 26, 2013 at 8:19 AM, Benjamin Smedberg <benjamin at smedbergs.us> wrote: > One of the use cases that has come up for why people are still using plugins > is supporting scanning to the web, in particular multi-page scanning. It > seems to me that we could hook this up to <input type="file" multiple>, but > that we should try to provide UAs with a hint that a page expects a document > instead of images. What we've done in Firefox for Android is to treat <input type=file accept="image/*"> as a hint that the page wants an image any source. So we give the user options to use any built-in gallery or camera apps for example. We could do the same on desktop platforms and display an additional button next to the normal "select file" button if we detected that there are additional image sources like cameras or scanners available. There's also been proposals around <input type=file accept="image/*" capture>. This was supposed to mean "invoke media specific capturing methods". I think there was also something like <input type=file capture=camera> being proposed which would specifically enable camera-backed capturing. > * Should we give the site any way to specify preferred resolution or color > depth for an image? Or should the site be prepared process any images to the > required resolution, convert to monochrome, etc. The most requested ability is to resize images to a particular resolution. This is something that can be done using canvas, but not for videos or animated images. And currently you can't do it off the main thread, which is an issue for larger images. It would be nice to expose a image-resize API to the web. This way they could do things like resize images to the various sizes needed and just upload the resized images. Currently you have to upload the fullsized image, or you have to resize once to the maximum size you want and upload that, and then resize again on the server. But that results in lower image quality. Likewise it would be nice to have an API for re-encoding images without using canvas. This will likely be especially important if we decide on a jpeg successor to add support for. > * Should the spec recommend any specific MIME types for scanner page images? > Most desktop scanners appear to default to .tiff, but that's not a normal > web format: perhaps we should recommend that UAs convert to PNG. Yes, definitely. / Jonas From robert at ocallahan.org Thu Sep 26 22:45:15 2013 From: robert at ocallahan.org (Robert O'Callahan) Date: Fri, 27 Sep 2013 17:45:15 +1200 Subject: [whatwg] Supporting scanners on the web In-Reply-To: <CA+c2ei8HOxZJ-sN0NM6zxbt+4=bFwfWMTxyM0+iXsHJmgX8wQQ@mail.gmail.com> References: <5244506E.3020808@smedbergs.us> <CA+c2ei8HOxZJ-sN0NM6zxbt+4=bFwfWMTxyM0+iXsHJmgX8wQQ@mail.gmail.com> Message-ID: <CAOp6jLYOtSVZTTuY+g_u2G38jFxoq2wrix8buVbNifSfmCjz5w@mail.gmail.com> On Fri, Sep 27, 2013 at 5:29 PM, Jonas Sicking <jonas at sicking.cc> wrote: > The most requested ability is to resize images to a particular > resolution. This is something that can be done using canvas, but not > for videos or animated images. And currently you can't do it off the > main thread, which is an issue for larger images. > You can actually. You can draw the image to an offscreen <canvas>, scaling it, and then call toBlob() on the canvas, which is async. Nothing forces the image drawing and scaling part of that process to be sync. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * From atwilson at google.com Fri Sep 27 00:54:36 2013 From: atwilson at google.com (Andrew Wilson) Date: Fri, 27 Sep 2013 09:54:36 +0200 Subject: [whatwg] Notifications: usage feedback In-Reply-To: <CAHgY_ifiJ-mjci7xAAasUTqM_jLVCzL9CwQuRJOe9LO8JbS=Gg@mail.gmail.com> References: <CAHgY_ifiJ-mjci7xAAasUTqM_jLVCzL9CwQuRJOe9LO8JbS=Gg@mail.gmail.com> Message-ID: <CAArhhishhjN4TnbXLicEV2fV7O77RY-r1M5Z1M-oJcsMzDOnoA@mail.gmail.com> So, I'm not entirely sure how many lessons taken from the FirefoxOS implementation are applicable to the API for web pages in general, but I agree that "what do we do if the user clicks on a notification after the parent page has been closed" is a bit of an unsolved/unsolveable problem with the current API. I dimly recall seeing an email thread proposing adding some kind of click URL to a notification (and my search-fu is not strong enough to find a link to it, sadly), which seems like it would address some of the issues you have with the current API (encoding data that can be passed back to the app on a notification click, even if the app has been closed in the meantime). The solution I've seen implemented on the web (shutdown notifications when a web page is closed) clearly doesn't work for a platform like FirefoxOS which does memory management and app shutdown behind the scenes. On Fri, Sep 27, 2013 at 3:15 AM, James Burke <jrburke at gmail.com> wrote: > This Notifications feedback comes from using them in FirefoxOS for the > email web app. It uses an alarm API to periodically wake up, do an > email sync, and if new messages, creates some Notifications. The web > app may also shut itself down if it was not already opened in a > visible state. The OS may also decide to kill it to use the memory for > some other app. > > 1) Ability to pass data with the Notification > > Right now, we URL-encode some args to the iconURL to pass data to the > handler function that is registered via > navigator.mozSetMessageHandler('notification', function(){}) [1]. > > It would be better if I could just pass a JSON-friendly data object to > Notification instance and then have access to that data in the > notification callbacks that are triggered. > > We cannot depend on notification.onclick to work since the app can be > closed after the notification is fired. It also seemed very unreliable > to depend on it, given garbage collection possibilities. So we cannot > reliably capture state using a function closure. > > 2) General notification callback entry point > > We are avoiding use of notification.onclick/onclose and would prefer > to have a generic entry point to receive notification events. Right > now we use navigator.mozSetMessageHandler('notification', > function(){}). > > but I would prefer to see a more official entry point in the spec. I > would go so far as to want to deprecate the .onclick and .onclose as > in practice they are not reliable, given that the app may be closed > down after firing the Notification but before it is clicked. > > 3) onclick fires onclose too? > > It seemed a bit unclear in the spec, but right now FirefoxOS fires > onclose too for onclick actions, as the onclick pathway removes the > notification from the list of notifications. > > This seems counterintuitive to me, I would have only expected one > event. Perhaps clarifying the onclick behavior would be good. > > I would prefer to just see one event fired in this case, if > onclick/onclose are kept around. If the general notification callback > entry point is established, then just firing it once with the > event.clicked property set to true for the clicked route. > > 4) onclick does not bring web app to front > > This may be part of just further defining the steps for the "click" > pathway in the spec, but at least in FirefoxOS right now, the > notification onclick pathway does not bring the app to the visible > front in all cases. The email app has to do some extra document.hidden > checking and try to bring itself to the front. > > What I would rather see is by default the web page is brought to the > visible front, and then perhaps allow the app a way to cancel that > behavior perhaps via a preventDefault() type of mechanism on any > notification click event. > > This would also reduce the need for an API that the app could call to > bring itself "to the visible front". Right now, there is an > app.launch() API in FirefoxOS for this, but there are concerns that > giving apps the ability to launch themselves to the front could lead > to an abuse of that API. > > 5) Ability to set notification modes. > > This one is a bit less defined. I would rather this one is discarded > than spending too much time on it if it meant losing track of the > points above: > > For email notifications, we did not necessarily want the phone to > light up the screen on every notification and make a sound or vibrate > (particularly at night), but rather just register the notification and > have it show up in the notification count and listing. > > While ideally there is UI for the user to control notification > behavior for all web apps, I can also see the case for allowing > notifications the ability to opt in to the notification modes it > prefers. > > Any user settings would override the modes specified in the > notification, but for apps that did want to be nice, it would be a way > to avoid a very annoying first notification behavior, in the case of > email, not disturbing the user unless they did an explicit override. > > This may be too tricky to specify, but I started a bugzilla bug for > FirefoxOS for this[2]. One suggestion was listing the preferred modes > in the web app manifest, but I can see an app may have different types > of notifications, so it would be more flexible to set per Notification > instance. > > There is a dev-gaia thread[3] that prompted this feedback. > > [1] > https://developer.mozilla.org/en-US/docs/Web/API/window.navigator.mozSetMessageHandler > > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=912645 > > [3] https://groups.google.com/forum/#!topic/mozilla.dev.gaia/NVacmcxGt2Q > > James > From jmuizelaar at mozilla.com Fri Sep 27 11:13:34 2013 From: jmuizelaar at mozilla.com (Jeff Muizelaar) Date: Fri, 27 Sep 2013 14:13:34 -0400 Subject: [whatwg] Supporting scanners on the web In-Reply-To: <CA+c2ei8HOxZJ-sN0NM6zxbt+4=bFwfWMTxyM0+iXsHJmgX8wQQ@mail.gmail.com> References: <5244506E.3020808@smedbergs.us> <CA+c2ei8HOxZJ-sN0NM6zxbt+4=bFwfWMTxyM0+iXsHJmgX8wQQ@mail.gmail.com> Message-ID: <B6E1DE41-A274-425E-92A2-5AD37D503C11@mozilla.com> On 2013-09-27, at 1:29 AM, Jonas Sicking wrote: > On Thu, Sep 26, 2013 at 8:19 AM, Benjamin Smedberg > <benjamin at smedbergs.us> wrote: >> One of the use cases that has come up for why people are still using plugins >> is supporting scanning to the web, in particular multi-page scanning. It >> seems to me that we could hook this up to <input type="file" multiple>, but >> that we should try to provide UAs with a hint that a page expects a document >> instead of images. > > What we've done in Firefox for Android is to treat <input type=file > accept="image/*"> as a hint that the page wants an image any source. > So we give the user options to use any built-in gallery or camera apps > for example. > > We could do the same on desktop platforms and display an additional > button next to the normal "select file" button if we detected that > there are additional image sources like cameras or scanners available. > > There's also been proposals around <input type=file accept="image/*" > capture>. This was supposed to mean "invoke media specific capturing > methods". I think there was also something like <input type=file > capture=camera> being proposed which would specifically enable > camera-backed capturing. > >> * Should we give the site any way to specify preferred resolution or color >> depth for an image? Or should the site be prepared process any images to the >> required resolution, convert to monochrome, etc. > > The most requested ability is to resize images to a particular > resolution. This is something that can be done using canvas, but not > for videos or animated images. And currently you can't do it off the > main thread, which is an issue for larger images. > > It would be nice to expose a image-resize API to the web. This can already easily be done with javascript: http://people.mozilla.org/~jmuizelaar/image-scaling/scale.html The code above could easily run in a worker and can scale a 4288 ? 2848 image in under a second -Jeff From jonas at sicking.cc Fri Sep 27 11:37:08 2013 From: jonas at sicking.cc (Jonas Sicking) Date: Fri, 27 Sep 2013 11:37:08 -0700 Subject: [whatwg] Supporting scanners on the web In-Reply-To: <CAOp6jLYOtSVZTTuY+g_u2G38jFxoq2wrix8buVbNifSfmCjz5w@mail.gmail.com> References: <5244506E.3020808@smedbergs.us> <CA+c2ei8HOxZJ-sN0NM6zxbt+4=bFwfWMTxyM0+iXsHJmgX8wQQ@mail.gmail.com> <CAOp6jLYOtSVZTTuY+g_u2G38jFxoq2wrix8buVbNifSfmCjz5w@mail.gmail.com> Message-ID: <CA+c2ei-PSD6fWoPgwCR7EqrFE8786CqndDibN+AJ5+h5CK_MBw@mail.gmail.com> On Thu, Sep 26, 2013 at 10:45 PM, Robert O'Callahan <robert at ocallahan.org> wrote: > On Fri, Sep 27, 2013 at 5:29 PM, Jonas Sicking <jonas at sicking.cc> wrote: >> >> The most requested ability is to resize images to a particular >> resolution. This is something that can be done using canvas, but not >> for videos or animated images. And currently you can't do it off the >> main thread, which is an issue for larger images. > > You can actually. You can draw the image to an offscreen <canvas>, scaling > it, and then call toBlob() on the canvas, which is async. Nothing forces the > image drawing and scaling part of that process to be sync. Good point. Still doesn't solve the video or animated image problem though. Also, does any browser actually do implement asynchronous scaling in this case? We definitely shouldn't add an API to work around the lack of another API, but there's also a difference between something theoretically being possible to implement, and it actually being doable enough to happen. / Jonas From ian at hixie.ch Fri Sep 27 14:05:47 2013 From: ian at hixie.ch (Ian Hickson) Date: Fri, 27 Sep 2013 21:05:47 +0000 (UTC) Subject: [whatwg] 2D canvas feature proposal: text decoration In-Reply-To: <CABpaAqTWJq+-zrGj-Rnme1XLbDyp-2m5Bpnx8ubuo1QLr9SJWw@mail.gmail.com> References: <CABpaAqS79N2Xfqy+CrniQJBDSzmaYgxFmdboBK9AtMCFGrvjTg@mail.gmail.com> <CAGN7qDCpb3CWi0j9uibGfn4wKCpf+YfUHLfzj7kJr46Z=TuXew@mail.gmail.com> <CABpaAqTFpDq5HMQyDCRVx3ru_KVeUniaySb6eFocnrg7kgqXgQ@mail.gmail.com> <CAGN7qDD2Z=g11F2PXMFtFQPedmfEtzs4oKsQSsRiJ8qwGQk2pw@mail.gmail.com> <CAAWBYDCuv9gxz1utnsMQ2OsYhgo+gJH6W+_=5Gko7XmJekoSKw@mail.gmail.com> <CAGN7qDC6Dj1aoAtwiRzdm5L83=4yq2GhpXjhddyAQbF44LtwYQ@mail.gmail.com> <CAAWBYDDbpXtAs3V8vvPBWXe4aNOfy+hU-2bre3_ie-sSQ7Q=rQ@mail.gmail.com> <CAGN7qDBT1+=m_yL=RTR1M0bhY6s3gtEXwLgnfXZTAsBEOMEFdg@mail.gmail.com> <CABpaAqQ87sLn_dqHwr9ZPLeeE665_2irC+mMhDGK4j=hWd7fTw@mail.gmail.com> <51716E59.6080609@mit.edu> <alpine.DEB.2.00.1308202224320.27209@ps20323.dreamhostps.com> <CABpaAqTWJq+-zrGj-Rnme1XLbDyp-2m5Bpnx8ubuo1QLr9SJWw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309272041490.12199@ps20323.dreamhostps.com> On Wed, 21 Aug 2013, Justin Novosad wrote: > On Tue, Aug 20, 2013 at 6:32 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Thu, 18 Apr 2013, Justin Novosad wrote: > > > > > > This is a really simple proposal to add support for text decorations > > > in 2D canvas contexts. > > > > > > IDL to add to interface CanvasDrawingStyles: > > > > > > attribute DOMString textDecoration; > > > > > > It would support all the same modes as the 'text-decoration' CSS > > > property (except inherit), and default would be 'none'. > > > > That's anything but simple. :-) > > > > The CSS text-decoration model is actually quite complex. Also, there > > have been many proposals to split 'text-decoration' into > > sub-properties, so it is only going to get more complicated from > > there. > > > > What's your use case? That is, when do you need to underline text? > > Take a web app that presents a view of an arbitrarily large document (map, > spreadsheet, word processor document, drawing, etc). Well, which one? :-) A word processor document definitely doesn't belong in <canvas>, as discussed here: http://whatwg.org/html/#best-practices Maps and drawings are obviously applicable to <canvas>. Spreadsheets maybe, though probably only because we don't have a better solution. So, let's assume we're talking about maps and drawings. > Using the DOM to represent such documents for the purpose of rendering can > be quite inefficient. The two basic approaches are: > a) Put the entire document into the DOM and incur massive layout and style > recalculation penalties. > b) Put only the visible part of the document in the DOM and incur frequent > layout and style recalculation penalties, as you scroll around > > With 2D canvas, the app can manage its own document model, often in ways > that perform better by several orders of magnitude. > There is increasing pressure from app developers for us to improve the text > feature set in 2D canvas so that so that apps can be ported to 2D canvas. What maps and drawings need underlines that are more elaborate than just stroking a line under the text manually? > Text decoration can theoretically be drawn directly by the application > by using font metrics to compute decoration positions, but this is often > very complex to do correctly in a truly portable way. We could add underline metrics to TextMetrics if that would help. I definitely do not think it makes sense to add APIs to <canvas> until such time as it's possible to create a CSS-compliant text formatter in <canvas>. That way lies madness, as text formatting is ludicrously complicated. We already have CSS. If doing things with CSS and the DOM is too slow, then we should fix that, we shouldn't just tell people to rewrite their apps in <canvas>. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Fri Sep 27 14:08:07 2013 From: ian at hixie.ch (Ian Hickson) Date: Fri, 27 Sep 2013 21:08:07 +0000 (UTC) Subject: [whatwg] Blurry lines in 2D Canvas In-Reply-To: <CAGN7qDC8hBPJc+HhRjgodkBAkhFEgJX0kAe=pMp9g3AnUm49Wg@mail.gmail.com> References: <CAGN7qDAdABj2NCNcc53qDd23Twq2=999u0Sio-gEsBJURrpCcg@mail.gmail.com> <CAPeKFThd5HvtYFvokX=n7UR_Qs=wmqHy2vMFDoDs9y9Jd5jM=Q@mail.gmail.com> <CAGN7qDCOdadxurg5qp6q3UMygv0gjBNc5BoHOgtZKggD=5ppNQ@mail.gmail.com> <CABirCh_0orFzaZAUrtg3Z+Jg0LdSGMZxuapVdKZgigEdKJJVXQ@mail.gmail.com> <CAGN7qDDbS5Vy65SqiSdVtxgz8W9w+8WO3n=2H4wpSdkaQNLBCQ@mail.gmail.com> <CABirCh-NiwtSMzs5J5=cqazNYGAKufA3s1Lz1cW-6YvhGbt8pg@mail.gmail.com> <CAGN7qDBqXxY-aWmb3kWwxXh=rfD1BfHCEiESs9yHiFkpxkPFig@mail.gmail.com> <CABirCh9RSb0SEMsqy9KHEV77h7s04hgq7G6evCYLFRM10Kh+1A@mail.gmail.com> <CAGN7qDA8fe42MUR-Dt1sxtCnN=hPYLe6TcasSfjV+q+i-UmrjA@mail.gmail.com> <alpine.DEB.2.00.1309052119410.7443@ps20323.dreamhostps.com> <CAGN7qDC8hBPJc+HhRjgodkBAkhFEgJX0kAe=pMp9g3AnUm49Wg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309272106060.12199@ps20323.dreamhostps.com> On Thu, 5 Sep 2013, Rik Cabanier wrote: > On Thu, Sep 5, 2013 at 3:22 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Sat, 10 Aug 2013, Rik Cabanier wrote: > > > > > > I was wondering if this is something that happens in Flash as well. > > > It turns out that there's an option called "hinting: Keep stroke > > > anchors on full pixels to prevent blurry lines." There's a blog post > > > on what this does: > > > > > > http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html > > > http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html > > > > > > I created an example (in flash sorry) that shows the feature: > > > http://cabanier.github.io/BlendExamples/pixelsnap/pixelsnap.html 2 > > > sets of strokes move across the screen and are also scaled. > > > > > > The top strokes behave like canvas does today. They start of blurry > > > and during the animation they slowly get ticker. For some reason it > > > doesn't look very smooth. The bottom strokes have hinting turned on. > > > They are sharp at the beginning and during the animation they stay > > > the same size until the internal stroke width is large enough. At > > > that point you see a 'jump'. > > > > > > I think canvas should have a similar feature... > > > > Can you elaborate on how exactly you would want this to work? How > > would you avoid the alignment and distortion problems when applying > > this to anything less trivial than a rectangle? > > Basically, this would *just* move the control points and the width of > paths so the strokes are always aligned to the pixel grid (This would > take pixel density and transformations into account). After this, you > would draw as usual. Can you define "aligned to the pixel grid"? If I have a line from x1,y to x2,y, followed by an arc from x2,y back to x1,y with radius r, what should happen and why? What if they're draw as separate paths? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From whatwg at therealcha0s.net Fri Sep 27 14:13:19 2013 From: whatwg at therealcha0s.net (Ruben Rodriguez II) Date: Fri, 27 Sep 2013 16:13:19 -0500 Subject: [whatwg] Blurry lines in 2D Canvas (and SVG) In-Reply-To: <CAGN7qDCTSsg-CNxofmnhVCKh7xRUBjemn1XvjwyyM8x7UGeNyg@mail.gmail.com> References: <CAGN7qDAdABj2NCNcc53qDd23Twq2=999u0Sio-gEsBJURrpCcg@mail.gmail.com> <51EF205B.6060905@mozilla.com> <CAGN7qDAMLPe00Ako7nTLtSTWnKwe3yWK5ox8jV1y0OpNmxfGrw@mail.gmail.com> <51EF29DC.5090207@mozilla.com> <CAGN7qDCTSsg-CNxofmnhVCKh7xRUBjemn1XvjwyyM8x7UGeNyg@mail.gmail.com> Message-ID: <5245F4EF.5040407@therealcha0s.net> It seems like those should be two separate things instead of lumped all together in a monolithic "You can do this if you want... or whatever!" "Snapping" is definitely something different than antialiasing. It's a huge pain for anyone trying to provide a(n accurate) simple 2D primitive library. On 07/23/2013 08:16 PM, Rik Cabanier wrote: > I guess there's too many "might"s in there :-) > > I want to "adjust line positions and line widths to align edges with device > pixels" but not "the user agent might turn off anti-aliasing for all lines > and curves" > > On Tue, Jul 23, 2013 at 6:11 PM, Brian Birtles <bbirtles at mozilla.com> wrote: > >> (2013/07/24 10:07), Rik Cabanier wrote: >> >>> yeah, at first blush that seemed what was needed. >>> However, this simply turns off antialiasing completely so regular >>> artwork looks terrible. >>> >> That's a quality of implementation issue. The description of the property >> value says, >> >> "Indicates that the user agent shall attempt to emphasize the contrast >> between clean edges of artwork over rendering speed and geometric >> precision. To achieve crisp edges, the user agent might turn off >> anti-aliasing for all lines and curves or possibly just for straight lines >> which are close to vertical or horizontal. Also, the user agent might >> adjust line positions and line widths to align edges with device pixels." >> >> I'm not sure what use case you have in mind though. Perhaps it's something >> that doesn't fit that description? >> >> From ian at hixie.ch Fri Sep 27 14:21:01 2013 From: ian at hixie.ch (Ian Hickson) Date: Fri, 27 Sep 2013 21:21:01 +0000 (UTC) Subject: [whatwg] Adding 2D Canvas features In-Reply-To: <CAK-G-KUOzNXhRfZRTtmuYFHHcHDriSodcRmoORGqi4XhFevNuQ@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <51D12692.4030002@artspark.co.jp> <CAK-G-KVLsECC4cETFYdcPyoqigaaoRhUxcezhMG3jZc2fAViRg@mail.gmail.com> <alpine.DEB.2.00.1309052049070.7443@ps20323.dreamhostps.com> <CAA5isUYmMm9sHu=_Ybwmhw7GWfO+vRpP+8MdM_+OXKPCc+i4+Q@mail.gmail.com> <CAK-G-KUOzNXhRfZRTtmuYFHHcHDriSodcRmoORGqi4XhFevNuQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309272108410.12199@ps20323.dreamhostps.com> On Thu, 5 Sep 2013, Tom Wiltzius wrote: > > Meanwhile this doesn't change the other Canvas2D-related work ongoing in > the Chromium project, so we're still keen to see some new features added > to the Canvas spec. Ian if it would help to identify items in the spec > that Chromium doesn't intend to implement (at least any time soon), we > can attempt to do so. If there are specific things in the spec that you think are bad and should be removed, please do raise them on the mailing list, yes. If there are specific things not in the spec that you have implemented, then please file a bug pointing to the documentation for whatever you have implemented, using: http://whatwg.org/newbug If there's multiple implementations, and HTML is the right spec, then I'll pretty much automatically spec it. Otherwise, it'll be based on whether it makes sense and has use cases. (So far example, I haven't added canvas text decoration APIs, which have been raised as something Chrome might implement, as discussed in my last e-mail to this list. The alpha parameter, though, needs speccing, I just haven't gotten around to it yet -- it's on my list though.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From whatwg at therealcha0s.net Fri Sep 27 14:21:20 2013 From: whatwg at therealcha0s.net (Ruben Rodriguez II) Date: Fri, 27 Sep 2013 16:21:20 -0500 Subject: [whatwg] Blurry lines in 2D Canvas In-Reply-To: <alpine.DEB.2.00.1309052119410.7443@ps20323.dreamhostps.com> References: <CAGN7qDAdABj2NCNcc53qDd23Twq2=999u0Sio-gEsBJURrpCcg@mail.gmail.com> <CAPeKFThd5HvtYFvokX=n7UR_Qs=wmqHy2vMFDoDs9y9Jd5jM=Q@mail.gmail.com> <CAGN7qDCOdadxurg5qp6q3UMygv0gjBNc5BoHOgtZKggD=5ppNQ@mail.gmail.com> <CABirCh_0orFzaZAUrtg3Z+Jg0LdSGMZxuapVdKZgigEdKJJVXQ@mail.gmail.com> <CAGN7qDDbS5Vy65SqiSdVtxgz8W9w+8WO3n=2H4wpSdkaQNLBCQ@mail.gmail.com> <CABirCh-NiwtSMzs5J5=cqazNYGAKufA3s1Lz1cW-6YvhGbt8pg@mail.gmail.com> <CAGN7qDBqXxY-aWmb3kWwxXh=rfD1BfHCEiESs9yHiFkpxkPFig@mail.gmail.com> <CABirCh9RSb0SEMsqy9KHEV77h7s04hgq7G6evCYLFRM10Kh+1A@mail.gmail.com> <CAGN7qDA8fe42MUR-Dt1sxtCnN=hPYLe6TcasSfjV+q+i-UmrjA@mail.gmail.com> <alpine.DEB.2.00.1309052119410.7443@ps20323.dreamhostps.com> Message-ID: <5245F6D0.2090209@therealcha0s.net> I would just like to note that sometimes we do not WANT to draw precise shapes. :) Many people enjoy the aesthetic of 2d pixel-based graphics, and it should be a viable choice for the graphical style of a game, for instance. Canvas makes this more difficult, and it shouldn't be so! Why can't we have a global option to turn this off if we want to? I'm not trying to advocate for throwing away all antialiasing... I understand that most applications will probably want it by default, and agree with having it as the default. Basically all it is is http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#image-smoothing ... except that we're not talking about scaling. On 09/05/2013 05:22 PM, Ian Hickson wrote: > On Tue, 23 Jul 2013, Rik Cabanier wrote: >> we've noticed that if you draw lines in canvas or SVG, they always end >> up blurry. For instance see this fiddle: http://jsfiddle.net/V92Gn/128/ > Not always, only if you don't draw the line aligned with the pixel grid > (e.g. you draw a diagonal line, or a horizontal or vertical line that > isn't centered in the middle of pixels on the pixels grid, or a horizontal > or vertical line whose width isn't an integral number of pixels, etc). > > The options, on a pixel grid display, are: > > - don't honour the position precisely -- this leads to very ugly > artifacts when animating (lines jerk around), and basically means that > the graphics aren't accurate. > > - instead of describing the shapes as vectors, describe them using > programs that can adapt to the position and size they're being drawn > at, such that they automatically snap to the pixel grid in a pretty > fashion -- this is what fonts do. > > - try to trick the eye by using anti-aliasing when things don't line up > exactly on the pixel grid. > > The first two really aren't plausible options for <canvas>. > > > On Wed, 24 Jul 2013, Kornel Lesi?ski wrote: >> For 1-pixel lines it could be fixed by allowing authors to specify that >> path should be stroked with lines aligned to inside/outside of the path >> (which is a useful feature on its own). > https://www.w3.org/Bugs/Public/show_bug.cgi?id=22674 > > > On Tue, 23 Jul 2013, Rik Cabanier wrote: >> Sure, but how can we fix this? > What is there to fix? The options above are basically the only options. > You can't not do one of them -- there's no way to draw a crisp line that > isn't pixel aligned. There's no pixels there. Similarly, there's no way to > draw a line that's neither horizontal nor vertical yet is crisp and > doesn't look jaggy. The pixels are squares, they don't rotate on modern > pixel displays. > > > On Wed, 24 Jul 2013, Kornel Lesi?ski wrote: >> Should arc() and bezier curves also be snapped? What if you want a line >> that touches the curve? > That's precisely the problem with snapping -- it is far worse than > antialiasing. You can't draw precise shapes if you have snapping. > > > On Wed, 24 Jul 2013, Dirk Schulze wrote: >> Means implementations would need to take viewport, transformations of >> the document, transformations on elements in the DOM hierarchy, zoom >> level, aspect ratio of the canvas, position of the canvas in the >> document, transformations in the canvas and device pixel resolution into >> account to snap lines to the correct position on the individual device, >> right?Otherwise it sounds to be hard to guarantee that you don't see >> antialiased strokes and lines might snap more then just one device >> pixel. This would also be a problem for aligning shapes to each other in >> the canvas I guess. What happens on the next transformation after a >> drawing operation. Say you draw a line that was snapped to the grid and >> then you do scale(1.1, 1.1). Shall the implementation redraw the canvas? >> After all it is an pixel image. A vector based drawing format would be >> better suited for such a task. > Indeed. > > > On Sat, 10 Aug 2013, Rik Cabanier wrote: >> I was wondering if this is something that happens in Flash as well. It >> turns out that there's an option called "hinting: Keep stroke anchors on >> full pixels to prevent blurry lines." There's a blog post on what this >> does: >> http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html >> <http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html> >> >> I created an example (in flash sorry) that shows the feature: >> http://cabanier.github.io/BlendExamples/pixelsnap/pixelsnap.html >> 2 sets of strokes move across the screen and are also scaled. >> >> The top strokes behave like canvas does today. They start of blurry and >> during the animation they slowly get ticker. For some reason it doesn't >> look very smooth. >> The bottom strokes have hinting turned on. They are sharp at the beginning >> and during the animation they stay the same size until the internal stroke >> width is large enough. At that point you see a 'jump'. >> >> I think canvas should have a similar feature... > Can you elaborate on how exactly you would want this to work? How would > you avoid the alignment and distortion problems when applying this to > anything less trivial than a rectangle? > From jstpierre at mecheye.net Fri Sep 27 14:38:56 2013 From: jstpierre at mecheye.net (Jasper St. Pierre) Date: Fri, 27 Sep 2013 17:38:56 -0400 Subject: [whatwg] Blurry lines in 2D Canvas In-Reply-To: <5245F6D0.2090209@therealcha0s.net> References: <CAGN7qDAdABj2NCNcc53qDd23Twq2=999u0Sio-gEsBJURrpCcg@mail.gmail.com> <CAPeKFThd5HvtYFvokX=n7UR_Qs=wmqHy2vMFDoDs9y9Jd5jM=Q@mail.gmail.com> <CAGN7qDCOdadxurg5qp6q3UMygv0gjBNc5BoHOgtZKggD=5ppNQ@mail.gmail.com> <CABirCh_0orFzaZAUrtg3Z+Jg0LdSGMZxuapVdKZgigEdKJJVXQ@mail.gmail.com> <CAGN7qDDbS5Vy65SqiSdVtxgz8W9w+8WO3n=2H4wpSdkaQNLBCQ@mail.gmail.com> <CABirCh-NiwtSMzs5J5=cqazNYGAKufA3s1Lz1cW-6YvhGbt8pg@mail.gmail.com> <CAGN7qDBqXxY-aWmb3kWwxXh=rfD1BfHCEiESs9yHiFkpxkPFig@mail.gmail.com> <CABirCh9RSb0SEMsqy9KHEV77h7s04hgq7G6evCYLFRM10Kh+1A@mail.gmail.com> <CAGN7qDA8fe42MUR-Dt1sxtCnN=hPYLe6TcasSfjV+q+i-UmrjA@mail.gmail.com> <alpine.DEB.2.00.1309052119410.7443@ps20323.dreamhostps.com> <5245F6D0.2090209@therealcha0s.net> Message-ID: <CAA0H+QTBEPDr65ZJS7Y9LrHi4PZJ89+nXROp98yfA9muSjefxQ@mail.gmail.com> The issue here is that the canvas API does not specify how pixels are sited on the canvas: if you imagine pixels as enlarged squares on a grid (shush, I know), does an X coordinate of 5 name the center of the square, or the intersection between 4th and 5th squares? If we say that it names the center of the square itself, then we'll have sharp strokes but blurry fills -- filling from x=5 to x=10 will only fill half the area in the 5th square. If we say that it names the intersection between the pixels then we'll have blurry strokes but sharp fills. For perspective, old APIs that didn't have support for antialiased graphics like X11 and GDI say that it's the former, but the lack of antialiasing made it not noticeable. Modern APIs like cairo, Quartz 2D and Direct2D say it's the latter, and stick by it. The recommended solution is either to use even line widths with pixel-perfect coordinates or add 0.5 to all lines you draw so they're offset by half a pixel. [0] Neither of these are perfect solutions when you have transforms; perhaps optional support for crisp lines or otherwise turning off AA would be a good idea. But whatever we do, we should certainly pick a pixel citing system (and I'd highly suggest the latter) and make it explicit in the spec. http://cairographics.org/FAQ/#sharp_lines On Fri, Sep 27, 2013 at 5:21 PM, Ruben Rodriguez II <whatwg at therealcha0s.net > wrote: > I would just like to note that sometimes we do not WANT to draw precise > shapes. :) Many people enjoy the aesthetic of 2d pixel-based graphics, and > it should be a viable choice for the graphical style of a game, for > instance. Canvas makes this more difficult, and it shouldn't be so! > > Why can't we have a global option to turn this off if we want to? I'm not > trying to advocate for throwing away all antialiasing... I understand that > most applications will probably want it by default, and agree with having > it as the default. > > Basically all it is is http://www.whatwg.org/specs/** > web-apps/current-work/**multipage/the-canvas-element.** > html#image-smoothing<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#image-smoothing>... except that we're not talking about scaling. > > On 09/05/2013 05:22 PM, Ian Hickson wrote: > >> On Tue, 23 Jul 2013, Rik Cabanier wrote: >> >>> we've noticed that if you draw lines in canvas or SVG, they always end >>> up blurry. For instance see this fiddle: http://jsfiddle.net/V92Gn/128/ >>> >> Not always, only if you don't draw the line aligned with the pixel grid >> (e.g. you draw a diagonal line, or a horizontal or vertical line that >> isn't centered in the middle of pixels on the pixels grid, or a horizontal >> or vertical line whose width isn't an integral number of pixels, etc). >> >> The options, on a pixel grid display, are: >> >> - don't honour the position precisely -- this leads to very ugly >> artifacts when animating (lines jerk around), and basically means that >> the graphics aren't accurate. >> >> - instead of describing the shapes as vectors, describe them using >> programs that can adapt to the position and size they're being drawn >> at, such that they automatically snap to the pixel grid in a pretty >> fashion -- this is what fonts do. >> >> - try to trick the eye by using anti-aliasing when things don't line up >> exactly on the pixel grid. >> >> The first two really aren't plausible options for <canvas>. >> >> >> On Wed, 24 Jul 2013, Kornel Lesi?ski wrote: >> >>> For 1-pixel lines it could be fixed by allowing authors to specify that >>> path should be stroked with lines aligned to inside/outside of the path >>> (which is a useful feature on its own). >>> >> https://www.w3.org/Bugs/**Public/show_bug.cgi?id=22674<https://www.w3.org/Bugs/Public/show_bug.cgi?id=22674> >> >> >> On Tue, 23 Jul 2013, Rik Cabanier wrote: >> >>> Sure, but how can we fix this? >>> >> What is there to fix? The options above are basically the only options. >> You can't not do one of them -- there's no way to draw a crisp line that >> isn't pixel aligned. There's no pixels there. Similarly, there's no way to >> draw a line that's neither horizontal nor vertical yet is crisp and >> doesn't look jaggy. The pixels are squares, they don't rotate on modern >> pixel displays. >> >> >> On Wed, 24 Jul 2013, Kornel Lesi?ski wrote: >> >>> Should arc() and bezier curves also be snapped? What if you want a line >>> that touches the curve? >>> >> That's precisely the problem with snapping -- it is far worse than >> antialiasing. You can't draw precise shapes if you have snapping. >> >> >> On Wed, 24 Jul 2013, Dirk Schulze wrote: >> >>> Means implementations would need to take viewport, transformations of >>> the document, transformations on elements in the DOM hierarchy, zoom >>> level, aspect ratio of the canvas, position of the canvas in the >>> document, transformations in the canvas and device pixel resolution into >>> account to snap lines to the correct position on the individual device, >>> right?Otherwise it sounds to be hard to guarantee that you don't see >>> antialiased strokes and lines might snap more then just one device >>> pixel. This would also be a problem for aligning shapes to each other in >>> the canvas I guess. What happens on the next transformation after a >>> drawing operation. Say you draw a line that was snapped to the grid and >>> then you do scale(1.1, 1.1). Shall the implementation redraw the canvas? >>> After all it is an pixel image. A vector based drawing format would be >>> better suited for such a task. >>> >> Indeed. >> >> >> >> On Sat, 10 Aug 2013, Rik Cabanier wrote: >> >>> I was wondering if this is something that happens in Flash as well. It >>> turns out that there's an option called "hinting: Keep stroke anchors on >>> full pixels to prevent blurry lines." There's a blog post on what this >>> does: >>> http://www.kaourantin.net/**2005/08/stroke-hinting-in-** >>> flash-player-8-aka.html<http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html> >>> <http://www.kaourantin.net/**2005/08/stroke-hinting-in-** >>> flash-player-8-aka.html<http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html> >>> > >>> >>> I created an example (in flash sorry) that shows the feature: >>> http://cabanier.github.io/**BlendExamples/pixelsnap/**pixelsnap.html<http://cabanier.github.io/BlendExamples/pixelsnap/pixelsnap.html> >>> 2 sets of strokes move across the screen and are also scaled. >>> >>> The top strokes behave like canvas does today. They start of blurry and >>> during the animation they slowly get ticker. For some reason it doesn't >>> look very smooth. >>> The bottom strokes have hinting turned on. They are sharp at the >>> beginning >>> and during the animation they stay the same size until the internal >>> stroke >>> width is large enough. At that point you see a 'jump'. >>> >>> I think canvas should have a similar feature... >>> >> Can you elaborate on how exactly you would want this to work? How would >> you avoid the alignment and distortion problems when applying this to >> anything less trivial than a rectangle? >> >> > -- Jasper From ian at hixie.ch Fri Sep 27 14:51:30 2013 From: ian at hixie.ch (Ian Hickson) Date: Fri, 27 Sep 2013 21:51:30 +0000 (UTC) Subject: [whatwg] High-density canvases In-Reply-To: <CABpaAqRc1y-G_Oh1JgNDFXSZ-7nYMHKX+GJxpenJ1R1-8W9nPg@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <CAPeKFThoc4hbxYa637v1YcOb65KQC+-r2+3KCygsHA4YpZFmhg@mail.gmail.com> <alpine.DEB.2.00.1309092346190.12199@ps20323.dreamhostps.com> <CAPeKFTi1=XG+OZE08L7Z1bsoFVL5rNY3oPUPupvTJAB=uoytaQ@mail.gmail.com> <CABpaAqRc1y-G_Oh1JgNDFXSZ-7nYMHKX+GJxpenJ1R1-8W9nPg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309272132210.1460@ps20323.dreamhostps.com> On Mon, 9 Sep 2013, Rik Cabanier wrote: > On Mon, Sep 9, 2013 at 5:00 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > So my understanding is that the reason this feature failed is that > > there's existing content that assumes a 1:1 ratio, and having an > > automatic high-density mode was making some pages end up with canvases > > with four canvas pixels per CSS pixel (linearly) -- two from the > > browser making a native canvas, times two from the page scaling the > > canvas for high DPI displays. This is a factor of sixteen over a 1:1 > > canvas, a factor of four more than it should be for high DPI, and a > > big waste of resources. > > > > As much as sites do this manually, though, it's a huge pain in the > > neck to have to worry about pixel density when you're creating your > > canvas and drawing on it, especially if you're not drawing sprites on > > it. > > > > While we're talking about annoying things, there's also the annoyance > > that canvases tend to not take zoom into account (either > > density-affecting zoom like page zoom on desktop, or "transparent" > > zoom like pinch-zoom on mobile for non-mobile-optimised sites, which > > the site isn't supposed to know about): you have to remember to listen > > for onresize, and then manually blow away your canvas and recreate it > > at the right density and then squeeze it into place so that the > > coordinate space matches what your code is expecting while the > > <canvas> is actually sized for the display. > > > > There's also the issue of full-bleed canvases where every time the > > container changes, you have to remember to re-update the canvas > > coordinate space and repaint because otherwise your pretty page gets > > all warped. > > > > It would be nice to fix these all at once, and I think we can, by > > introducing a configuration option on getContext(), in the style of > > WebGL: > > > > getContext('2d', { density: 'autosize' }); > > > > This would trigger the following behaviour: When the context is > > created, and subsequently when the <canvas> changes size (e.g. due to > > being sized with CSS relative units and the element they're relative > > to changing), or when the display density changes size (e.g. due to > > page zoom), then: > > > > - the width and height of the canvas bitmaps get updated to match the > > new native size of the <canvas>, at native density. > > > > - the coordinate space of the canvas (context.width/context.height) > > gets updated to match the size of the <canvas> in CSS pixel units. > > > > - a 'resize' event gets fired at the <canvas>. > > Will this workflow introduce flickering? So long as the resize event (and thus the redrawing) is synchronous with the clearing, I don't see why it would. > I'm unsure if these calls are really needed. An author can already do > this today with a couple of lines of JS. It's a heck of a lot more than a couple of lines to do it right today. > By doing the actual resizing in the event handler, I believe flickering > is avoided. Not sure what you mean here. > I share Dean's worry that it will lead to bad redrawing if people don't > test all scenarios that causes resizing. Can you be more specific? What scenarios do you think would result in bad redrawing? > (Temporary canvases would also have to be resized manually) We'd have to provide a way to link canvases so that they maintain the same density. It's on my list of things to make sure I handle if I spec this. On Tue, 10 Sep 2013, Stephen White wrote: > > For posterity, here were our objections to the original high-DPI canvas > spec: > > - The API feels like a short-term hack to automagically do something > that the developer may or may not want done (e.g., if the game/app was > tuned for particular resolution, or for pixel-exact rendering) that we'll > be stuck with in the web platform long after its short-term usefulness has > expired This is avoided in the new proposal by making it opt-in. > - It doesn't scale well to non-integer devicePixelRatios Can you elaborate on this? I don't see why the new proposal would have this problem, but I also don't see why the old one would, so I don't know if it's because I don't understand the problem or if it's because I'm missing something from the old proposal. > - It is easy for developers to implement the above behaviour in JS if > desired I wouldn't say "easy". > I think the new proposal addresses the first point, since it's opt-in. I > don't think the second point is a problem, since [get|put]ImageData() > will be back to manipulating exact backing store pixels, so no > non-integer resizing will be required. The third point becomes moot. Agreed. > One question: now that some browsers are including browser zoom (page > zoom) in window.devicePixelRatio, will/should the new proposal > automatically cause a resize callback on page zoom, in order to preserve > 1:1 device pixels? My intent was to do so, yes. In practice I presume it'd be up to the browser to decide how often to actually do this (e.g. if page zoom is being smoothly animated, you may wish to only do it every few frames). > (Note that I think this is a problem with current JS-based > implementations of canvas auto-scale as well, although perhaps there's a > DOM event for this that you can listen to; I might just be showing my > ignorance here.) Currently page zoom should trigger a 'resize' event, but I expect few pages check. On Tue, 10 Sep 2013, Justin Novosad wrote: > > There is another closely related issue that's been discussed before: > adding a redraw callback to 2d canvas. In the past we discussed this > for solving the problem of recoverring from a gpu context loss, but it > seems there may be better reasons to consider adding a redraw callback > such as freeing memory consumed by canvas backing stores that are in > background tabs, and re-building the content when needed. This > discussion was revived in the past few days on the chromium graphics-dev > mailing list: > https://groups.google.com/a/chromium.org/forum/?fromgroups#!topic/graphics-dev/CQJXpXxO6dk > > The idea is still embryonic and we're brainstorming in this chromium > issue: crbug.com/287823 > > I think that discussion should be merged with this thread because a > resize event is another case where one may want to redraw. It would be > great to solve all of these issues together. I think it would make eminent sense to also fire the event ('resize', I guess) if the context was lost or if the canvas was about to be made visible again after the browser dropped the rendering, yes. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Fri Sep 27 15:07:40 2013 From: ian at hixie.ch (Ian Hickson) Date: Fri, 27 Sep 2013 22:07:40 +0000 (UTC) Subject: [whatwg] Challenging canvas.supportsContext In-Reply-To: <CAJTmd9q+Zyh=Fz3mRwBDBfy5q+mR5tVoNTv+rEtKJueQv2mfwg@mail.gmail.com> References: <CAJTmd9rkwsjC+WDfLr7um0=h8Pvtg9JOJCRHzH4PhdbXjgpaaA@mail.gmail.com> <CAJTmd9q-eH8fnZSP5mr3kX-quyQcNXnyXTh5o_hX+MdfuXfrGQ@mail.gmail.com> <alpine.DEB.2.00.1309032240300.7443@ps20323.dreamhostps.com> <CAJTmd9q+Zyh=Fz3mRwBDBfy5q+mR5tVoNTv+rEtKJueQv2mfwg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309272152500.1460@ps20323.dreamhostps.com> On Thu, 5 Sep 2013, Benoit Jacob wrote: > 2013/9/3 Ian Hickson <ian at hixie.ch> > > > > The long and short of this is that I renamed "supportsContext()" to > > "probablySupportsContext()". It's already implemented in WebKit > > And that's the real cost of having accepted supportsContext too early in > the HTML spec. I'm not sure I would characterise it as a cost. > > Fundamentally, it addresses a need that none of the other proposals > > addressed: how to know whether or not you can expect to be able to do > > 3D. It's not 100% reliable, but then neither would actually attempting > > to create a context, because creating a context is so expensive on > > some platforms that some UAs are going to move to doing it lazily > > The only conformant way to do lazy context creation would be to have > getContext return lost contexts, but given that only a tiny minority of > real-world code cares about that concept, that's not going to be > feasible in the foreseeable future. Maybe in a few years, > optimistically. You could implement lazy context creation by just returning optimistically and if you later find you can't actually create what was requested, pretending you lost the context. Or, the spec could be changed. But yes, that's the problem. That's why we need this feature. > > On Wed, 19 Jun 2013, Benoit Jacob wrote: > > > > > However, that only shifts the question to: what is the reason for > > > them to expose such APIs? In the end, I claim that the only thing > > > that we should recognize as a reason to add a feature to the HTML > > > spec, is *application* use cases. > > > > Oh well the use case for knowing whether or not 3D is supported on a > > particular device is straight-forward: you want to know which set of > > assets and logic to download and run. > > Application developer wants things. But these are not necessarily good > ideas, because they may not reflect how things really work. Certainly. > > > So let's look at the naive application usage pattern for supportsContext: > > > > > > if (canvas.supportsContext("webgl")) { > > > context = canvas.getContext("webgl"); > > > } > > > > > > The problem is that the same can be achieved with just the > > > getContext call, and checking whether it succeeded. > > > > Suppose you have an app that has a 3D feature, but it's not > > immediately used upon startup. For example, a preview window that is > > displayed on request. You want to preload all the code to run the > > preview window, but you need to load different code based on whether > > the device can do 3D or not. So the use case is more: > > > > if (canvas.supportsContext("webgl")) > > load3DCode(); > > else > > load2DCode(); > > > > // 3D code: > > function run() { > > context = canvas.getContext("webgl"); > > // ... > > } > > If now application developers call probablySupportsContext, it returns > true, they start downloading the WebGL assets, but getContext("webgl") > fails, their application startup experience will be wose, which will > pressure browser developers to optimize the accuracy of > probablySupportsContext, but that's going to be hard and unrewarding. This is a rare case, and it's a rare case that can happen even with using getContext() twice instead of probablySupportsContext() and getContext(). > Instead, they should do their actual getContext call --- the one > creating the context that they will actually want to use --- right at > the beginning of their application startup, and download the right > assets based on the outcome of that getContext. Sure, but we've repeatedly heard application developers say that's not going to happen, so... > The downside of course is that assets download becomes gated on getContext > returning. But in practice that's not too bad: > - Only the first getContext in a browser sessing can be really slow (say > 100 ms), subsequent ones tend to take less than 5 ms --- not that much > compared to the time to download big assets. > - If any assets are shared between the two code paths, they can be > downloaded first while getContext is running. We might not consider it too bad, but we have heard other people say it's too bad. > > You don't want to pay the cost of creating a throw-away 3D context on > > startup just to know which scripts to load. It defeats the whole point > > of not loading all the code up-front. > > I'm not talking about having any throw-away 3d contexts just for > testing. I understand that modernizr has an API that would force it to > be implemented in that way. In my view, that makes it a bad API. There > should be only one context, the one that we actually want to use. Well, as much as I agree with you, we still have to take author needs into account. Take the example I gave above, with a preview window. The <canvas> that you'll be drawing on might not exist yet. The entire fragment of the document, or indeed, the entire <iframe> containing the relevant document, might not exist yet. > > > Outside of exceptional cases (out of memory...), the slow path in > > > getContext is the *success* case, and again, in that case a real > > > application would want to actually *use* that context. > > > > Not necessarily, as noted above. The <canvas> you're going to draw to > > might not even exist at the point you need to know if it's 3D or not. > > Precisely, that's my point: don't cater to the pathological > use-a-separate-throwaway-context use case, instead assume that people > are smart and that if the first getContext succeeds, they will use that > context. Assuming that people are "smart" when they have told us explicitly that they want to do something "not smart" is not a winning strategy. Also, I don't think "smart" is the right way to think of this. Consider someone who is using a self-contained 3D library that creates the <canvas> and handles lost contexts and so on. They also have a totally separate 2D library that creates its own <canvas> and so forth. And they have a sniffing library that they use to decide which to use. Realistically, it's quite likely that these libraries have never heard of each other and do not support handing off canvas elements and contexts to each other. The person writing this code might not know anything about contexts, either. It's not that they're not "smart", it's that they don't know this stuff. > > > Keep in mind that supportsContext can't guarantee that if it returns > > > true, then a subsequent getContext will succeed. > > > > Sure. getContext() can't guarantee that if it returns a context, the > > context will work forever, either. > > Indeed, there is some non-determinism inherent to how GPUs work. > > I'm just talking about not adding more non-determinism to it. I don't think this adds more, really. If probablySupportsContext() returns true, then most of the time, so will getContext(). Just like if getContext() returned non-null, it likely will again. > > > Given such deep problems, I think that the usefulness bar for > > > accepting supportsContext into the spec should be quite high. > > > > The problem is that there's no alternative solution. > > As I've been advocating, there is a more reasonable alternative which is > not to have anything else than getContext. That is only a reasonable alternative if we ignore the feedback we're getting from Web developers. > (I want to be clear that the long delay hinders my ability to continue > this conversation. I'm just one regular Mozilla developer --- I'm not > supposed to be spending a lot of time discussing the canvas standard, > and right now, I can't really afford to. Back when I started this thread > in june, I did have some time to invest in a long conversation on this. > Right now I don't.) Feel free to wait until you have time to reply. Fundamentally, I can't reply to all incoming mail immediately; I reply to it mostly on a first-come-first-served basis, grouped by threads. Sometimes I have a few months of lag. I don't know what I could do about this. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From robert at ocallahan.org Fri Sep 27 15:17:03 2013 From: robert at ocallahan.org (Robert O'Callahan) Date: Sat, 28 Sep 2013 10:17:03 +1200 Subject: [whatwg] Supporting scanners on the web In-Reply-To: <CA+c2ei-PSD6fWoPgwCR7EqrFE8786CqndDibN+AJ5+h5CK_MBw@mail.gmail.com> References: <5244506E.3020808@smedbergs.us> <CA+c2ei8HOxZJ-sN0NM6zxbt+4=bFwfWMTxyM0+iXsHJmgX8wQQ@mail.gmail.com> <CAOp6jLYOtSVZTTuY+g_u2G38jFxoq2wrix8buVbNifSfmCjz5w@mail.gmail.com> <CA+c2ei-PSD6fWoPgwCR7EqrFE8786CqndDibN+AJ5+h5CK_MBw@mail.gmail.com> Message-ID: <CAOp6jLajd5s8gUi9rfKobSR+ibpMnwcn5RKOEmfVKo-_zA9K0A@mail.gmail.com> On Sat, Sep 28, 2013 at 6:37 AM, Jonas Sicking <jonas at sicking.cc> wrote: > Also, does any browser actually do implement asynchronous scaling in > this case? We definitely shouldn't add an API to work around the lack > of another API, but there's also a difference between something > theoretically being possible to implement, and it actually being > doable enough to happen. > I don't know. As of recently, we do the image encoding step off the main thread, but the main thread still blocks for the scaling. That is fixable. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * From ian at hixie.ch Fri Sep 27 15:35:35 2013 From: ian at hixie.ch (Ian Hickson) Date: Fri, 27 Sep 2013 22:35:35 +0000 (UTC) Subject: [whatwg] Stroking algorithm in Canvas 2d In-Reply-To: <CAGN7qDDgfZmoZvj9JEwzM764LHWivn=nh_WyGfJOX7SdW31vvg@mail.gmail.com> References: <CAGN7qDA-iib4SULW-JDf4_vpsyuxpg1m8AkXq=qgDtY1OkXahA@mail.gmail.com> <alpine.DEB.2.00.1309091626010.12210@ps20323.dreamhostps.com> <CAGN7qDDgfZmoZvj9JEwzM764LHWivn=nh_WyGfJOX7SdW31vvg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309272226380.1460@ps20323.dreamhostps.com> On Mon, 9 Sep 2013, Rik Cabanier wrote: > On Mon, Sep 9, 2013 at 9:33 AM, Ian Hickson <ian at hixie.ch> wrote: > > On Thu, 5 Sep 2013, Rik Cabanier wrote: > > > > > > we've looked over the algorithm in the Canvas spec that describes > > > how strokes are computed. [1] We think that this section is making > > > some incorrect assumptions. For instance, the dashes are calculated > > > over the total lenght of all subpaths, but each subpath should be > > > treated separately. > > > > That's intentional, otherwise if you stroke an already-dashed line, > > you get weird results. > > As Stephan said, when would this happen? Are you thinking of a case > where you did the dashing yourself and then dash/stroke it again? If so, > that is expected to give different results. Expected by whom? The idea here is that this line: ------------------------------ ...would result in this dash (assuming equally spaced on-off): --- --- --- --- --- ...while this line, dashed with the same stroke: --- --- --- --- --- ...would result in this different line, rather than result in no change: --- --- --- ...and this line, dashed with the same stroke: -- -- -- -- -- -- -- -- ...would result in something more like: -- - -- - -- - ...rather than, again, resulting in no change. > > > It's also a bit strange that the spec is trying to describe how to > > > stroke. > > > > It's trying to describe sufficient detail to get interoperable > > behaviour. > > > > > For instance, it goes in minute detail on how dashes are applied but > > > the hardest part of stroking ("inflating the paths in path > > > perpendicular to the direction") is not described at all. > > > > Is there any ambiguity in the part that's not described? > > Yes. What is "inflating"? The dictionary definition is what I intended. To grow, increase in size, get bigger in all directions. Inflate. If you have any better suggestion for how to word this, I'm all for it. > A stroked bezier curve is no longer a bezier and has to be calculated. Yes. The idea of defining it in terms of the earlier path is that there's no need to be explicit about the maths here. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jamesr at chromium.org Fri Sep 27 15:37:56 2013 From: jamesr at chromium.org (James Robinson) Date: Fri, 27 Sep 2013 15:37:56 -0700 Subject: [whatwg] Bug in 12.2.5.4.8 (The "text" insertion mode) when invoking the "spin the event loop" algorithm Message-ID: <CAD73md+UUivE3NFEM2V=S71d7LYqri+Z2VD+0ggvkNiH03YJjw@mail.gmail.com> 12.2.5.4.8 (The "text" insertion mode) defines an following algorithm for dealing with inline <script> tags that aren't ready to execute when parsed. I believe there are some subtle bugs with the way the algorithm is specified. More importantly, the invocation of the "spin the event loop" algorithm makes it harder to reason about the system as a whole. The algorithm in question runs when parsing a </script> at a script nesting level (i.e. not one generated by document.write()): 1.) Let *the script* be the pending parsing-blocking script<http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#pending-parsing-blocking-script>. There is no longer a pending parsing-blocking script<http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#pending-parsing-blocking-script> . 2.) Block the tokenizer<http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#tokenization>for this instance of the HTML parser<http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#html-parser>, such that the event loop<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-loop>will not run tasks<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#concept-task>that invoke the tokenizer<http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#tokenization> . 3.) If the parser's Document<http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#document> has a style sheet that is blocking scripts<http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#has-a-style-sheet-that-is-blocking-scripts>or *the script*'s "ready to be parser-executed"<http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#ready-to-be-parser-executed>flag is not set: spin the event loop<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#spin-the-event-loop>until the parser's Document<http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#document> has no style sheet that is blocking scripts<http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#has-no-style-sheet-that-is-blocking-scripts>and *the script*'s "ready to be parser-executed"<http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#ready-to-be-parser-executed>flag is set. 4.) Unblock the tokenizer<http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#tokenization>for this instance of the HTML parser<http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#html-parser>, such that tasks<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#concept-task>that invoke the tokenizer<http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#tokenization>can again be run. 5.) Let the insertion point<http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#insertion-point>be just before the next input character<http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#next-input-character> . 6.) Increment the parser's script nesting level<http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#script-nesting-level>by one (it should be zero before this step, so this sets it to one). 7.) Execute<http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#execute-the-script-block> *the script*. ... Step 3 spins the event loop. The issue is that while the tokenizer is blocked other tasks can run whenever the event loop is spun and cause changes that make the rest of the algorithm incorrect. For example, consider: <!DOCTYPE html> <script> window.setTimeout(function() { document.write("Goodbye"); }, 50); <link rel="stylesheet" type="text/css" href="long_loading.css"></link> <script> window.alert("Hello"); </script> The algorithm in question will run when parsing the last </script>. The second script can't execute until the stylesheet loads, so the spec spins the event loop until that happens. However, if the setTimeout fires before long_loading.css loads then the document.write() call will first perform an implicit document.open(), since there is no insertion point, and blow away the entire Document. This cancels any pending tasks but doesn't (as far as I can tell) cancel already started tasks. By my reading of the spec, the rest of the steps of the algorithm should still run and the script should execute. However, what actually happens in every browser I can test (Chrome Canary* / Firefox 22 / IE10) the alert never fires. What the Blink code actually does is simply suspend the tokenizer and then return control the the underlying (non-nested, usually) event loop. I propose that instead of spinning the event loop, we instead have step 3 enter an asynchronous section if the script isn't ready to run yet which queues a task once the script is ready to run. Since this algorithm only runs at a script nesting level of zero this is a fairly minor tweak in overall behavior, but I believe it means that invoking the tokenizer can never spin the event loop which is a nice property to have. - James * This testcase actually crashes Chrome versions other than recent canaries. Oops. From glenn at zewt.org Fri Sep 27 19:41:24 2013 From: glenn at zewt.org (Glenn Maynard) Date: Fri, 27 Sep 2013 21:41:24 -0500 Subject: [whatwg] Blurry lines in 2D Canvas In-Reply-To: <CAA0H+QTBEPDr65ZJS7Y9LrHi4PZJ89+nXROp98yfA9muSjefxQ@mail.gmail.com> References: <CAGN7qDAdABj2NCNcc53qDd23Twq2=999u0Sio-gEsBJURrpCcg@mail.gmail.com> <CAPeKFThd5HvtYFvokX=n7UR_Qs=wmqHy2vMFDoDs9y9Jd5jM=Q@mail.gmail.com> <CAGN7qDCOdadxurg5qp6q3UMygv0gjBNc5BoHOgtZKggD=5ppNQ@mail.gmail.com> <CABirCh_0orFzaZAUrtg3Z+Jg0LdSGMZxuapVdKZgigEdKJJVXQ@mail.gmail.com> <CAGN7qDDbS5Vy65SqiSdVtxgz8W9w+8WO3n=2H4wpSdkaQNLBCQ@mail.gmail.com> <CABirCh-NiwtSMzs5J5=cqazNYGAKufA3s1Lz1cW-6YvhGbt8pg@mail.gmail.com> <CAGN7qDBqXxY-aWmb3kWwxXh=rfD1BfHCEiESs9yHiFkpxkPFig@mail.gmail.com> <CABirCh9RSb0SEMsqy9KHEV77h7s04hgq7G6evCYLFRM10Kh+1A@mail.gmail.com> <CAGN7qDA8fe42MUR-Dt1sxtCnN=hPYLe6TcasSfjV+q+i-UmrjA@mail.gmail.com> <alpine.DEB.2.00.1309052119410.7443@ps20323.dreamhostps.com> <5245F6D0.2090209@therealcha0s.net> <CAA0H+QTBEPDr65ZJS7Y9LrHi4PZJ89+nXROp98yfA9muSjefxQ@mail.gmail.com> Message-ID: <CABirCh9zgFgtZiO7o=GaBhHFF+Unz1CtKsAG_sLXfdh=1VmWkw@mail.gmail.com> On Fri, Sep 27, 2013 at 4:38 PM, Jasper St. Pierre <jstpierre at mecheye.net>wrote: > The issue here is that the canvas API does not specify how pixels are sited > on the canvas: if you imagine pixels as enlarged squares on a grid (shush, > I know), does an X coordinate of 5 name the center of the square, or the > intersection between 4th and 5th squares? > That's not the issue this thread is about. I don't know if it's specified (though I suspect is is), but WebKit, Firefox and IE10's Canvas implementations all use OpenGL's coordinate system. This can be seen in the very first post in the thread, which renders consistently in all three browsers. http://jsfiddle.net/V92Gn/128/ -- Glenn Maynard From cabanier at gmail.com Fri Sep 27 20:58:49 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Fri, 27 Sep 2013 20:58:49 -0700 Subject: [whatwg] Stroking algorithm in Canvas 2d In-Reply-To: <alpine.DEB.2.00.1309272226380.1460@ps20323.dreamhostps.com> References: <CAGN7qDA-iib4SULW-JDf4_vpsyuxpg1m8AkXq=qgDtY1OkXahA@mail.gmail.com> <alpine.DEB.2.00.1309091626010.12210@ps20323.dreamhostps.com> <CAGN7qDDgfZmoZvj9JEwzM764LHWivn=nh_WyGfJOX7SdW31vvg@mail.gmail.com> <alpine.DEB.2.00.1309272226380.1460@ps20323.dreamhostps.com> Message-ID: <CAGN7qDD4vA-7N_=KX_vZAeRPHZvtQAvhSSKE2bCi9T+iOReO-g@mail.gmail.com> On Fri, Sep 27, 2013 at 3:35 PM, Ian Hickson <ian at hixie.ch> wrote: > On Mon, 9 Sep 2013, Rik Cabanier wrote: > > On Mon, Sep 9, 2013 at 9:33 AM, Ian Hickson <ian at hixie.ch> wrote: > > > On Thu, 5 Sep 2013, Rik Cabanier wrote: > > > > > > > > we've looked over the algorithm in the Canvas spec that describes > > > > how strokes are computed. [1] We think that this section is making > > > > some incorrect assumptions. For instance, the dashes are calculated > > > > over the total lenght of all subpaths, but each subpath should be > > > > treated separately. > > > > > > That's intentional, otherwise if you stroke an already-dashed line, > > > you get weird results. > > > > As Stephan said, when would this happen? Are you thinking of a case > > where you did the dashing yourself and then dash/stroke it again? If so, > > that is expected to give different results. > > Expected by whom? > > The idea here is that this line: > > ------------------------------ > > ...would result in this dash (assuming equally spaced on-off): > > --- --- --- --- --- > > ...while this line, dashed with the same stroke: > > --- --- --- --- --- > > ...would result in this different line, rather than result in no change: > > --- --- --- > > ...and this line, dashed with the same stroke: > > -- -- -- -- -- -- -- -- > > ...would result in something more like: > > -- - -- - -- - > > ...rather than, again, resulting in no change. > Yep, this is where assumptions went wrong. Dashes are calculated per subpath, not per 'line'/whole path. > > > > > > It's also a bit strange that the spec is trying to describe how to > > > > stroke. > > > > > > It's trying to describe sufficient detail to get interoperable > > > behaviour. > > > > > > > For instance, it goes in minute detail on how dashes are applied but > > > > the hardest part of stroking ("inflating the paths in path > > > > perpendicular to the direction") is not described at all. > > > > > > Is there any ambiguity in the part that's not described? > > > > Yes. What is "inflating"? > > The dictionary definition is what I intended. To grow, increase in size, > get bigger in all directions. Inflate. > > If you have any better suggestion for how to word this, I'm all for it. > I think Stephan could come up with a formula. Not sure if we should do this though. You can see a stroke as if you're drawing with a marker with a round, square or flat tip (= end caps). Maybe it's OK the say that in the spec? > > > > A stroked bezier curve is no longer a bezier and has to be calculated. > > Yes. The idea of defining it in terms of the earlier path is that there's > no need to be explicit about the maths here. How is a UA going to implement that? I can imagine many ways to "inflate" a path From cabanier at gmail.com Sat Sep 28 20:42:37 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Sat, 28 Sep 2013 20:42:37 -0700 Subject: [whatwg] Blurry lines in 2D Canvas In-Reply-To: <alpine.DEB.2.00.1309272106060.12199@ps20323.dreamhostps.com> References: <CAGN7qDAdABj2NCNcc53qDd23Twq2=999u0Sio-gEsBJURrpCcg@mail.gmail.com> <CAPeKFThd5HvtYFvokX=n7UR_Qs=wmqHy2vMFDoDs9y9Jd5jM=Q@mail.gmail.com> <CAGN7qDCOdadxurg5qp6q3UMygv0gjBNc5BoHOgtZKggD=5ppNQ@mail.gmail.com> <CABirCh_0orFzaZAUrtg3Z+Jg0LdSGMZxuapVdKZgigEdKJJVXQ@mail.gmail.com> <CAGN7qDDbS5Vy65SqiSdVtxgz8W9w+8WO3n=2H4wpSdkaQNLBCQ@mail.gmail.com> <CABirCh-NiwtSMzs5J5=cqazNYGAKufA3s1Lz1cW-6YvhGbt8pg@mail.gmail.com> <CAGN7qDBqXxY-aWmb3kWwxXh=rfD1BfHCEiESs9yHiFkpxkPFig@mail.gmail.com> <CABirCh9RSb0SEMsqy9KHEV77h7s04hgq7G6evCYLFRM10Kh+1A@mail.gmail.com> <CAGN7qDA8fe42MUR-Dt1sxtCnN=hPYLe6TcasSfjV+q+i-UmrjA@mail.gmail.com> <alpine.DEB.2.00.1309052119410.7443@ps20323.dreamhostps.com> <CAGN7qDC8hBPJc+HhRjgodkBAkhFEgJX0kAe=pMp9g3AnUm49Wg@mail.gmail.com> <alpine.DEB.2.00.1309272106060.12199@ps20323.dreamhostps.com> Message-ID: <CAGN7qDCgiSWx9GWGBp9S4gueEqBnW6NPWA1bsXOAbOmr+k9UGg@mail.gmail.com> On Fri, Sep 27, 2013 at 2:08 PM, Ian Hickson <ian at hixie.ch> wrote: > On Thu, 5 Sep 2013, Rik Cabanier wrote: > > On Thu, Sep 5, 2013 at 3:22 PM, Ian Hickson <ian at hixie.ch> wrote: > > > On Sat, 10 Aug 2013, Rik Cabanier wrote: > > > > > > > > I was wondering if this is something that happens in Flash as well. > > > > It turns out that there's an option called "hinting: Keep stroke > > > > anchors on full pixels to prevent blurry lines." There's a blog post > > > > on what this does: > > > > > > > > > http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html > > > > > http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html > > > > > > > > I created an example (in flash sorry) that shows the feature: > > > > http://cabanier.github.io/BlendExamples/pixelsnap/pixelsnap.html 2 > > > > sets of strokes move across the screen and are also scaled. > > > > > > > > The top strokes behave like canvas does today. They start of blurry > > > > and during the animation they slowly get ticker. For some reason it > > > > doesn't look very smooth. The bottom strokes have hinting turned on. > > > > They are sharp at the beginning and during the animation they stay > > > > the same size until the internal stroke width is large enough. At > > > > that point you see a 'jump'. > > > > > > > > I think canvas should have a similar feature... > > > > > > Can you elaborate on how exactly you would want this to work? How > > > would you avoid the alignment and distortion problems when applying > > > this to anything less trivial than a rectangle? > > > > Basically, this would *just* move the control points and the width of > > paths so the strokes are always aligned to the pixel grid (This would > > take pixel density and transformations into account). After this, you > > would draw as usual. > > Can you define "aligned to the pixel grid"? > > If I have a line from x1,y to x2,y, followed by an arc from x2,y back to > x1,y with radius r, what should happen and why? > Align the anchor points of all the segments. Don't change any of the anti-aliasing behavior. > > What if they're draw as separate paths? I'm unsure if I follow. That shouldn't make a different. What might be different however, is if you draw a diagonal line in 1 segment or 2 since the middle point will be aligned to the grid in the latter case. From cabanier at gmail.com Sat Sep 28 20:43:49 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Sat, 28 Sep 2013 20:43:49 -0700 Subject: [whatwg] Blurry lines in 2D Canvas In-Reply-To: <CABirCh9zgFgtZiO7o=GaBhHFF+Unz1CtKsAG_sLXfdh=1VmWkw@mail.gmail.com> References: <CAGN7qDAdABj2NCNcc53qDd23Twq2=999u0Sio-gEsBJURrpCcg@mail.gmail.com> <CAPeKFThd5HvtYFvokX=n7UR_Qs=wmqHy2vMFDoDs9y9Jd5jM=Q@mail.gmail.com> <CAGN7qDCOdadxurg5qp6q3UMygv0gjBNc5BoHOgtZKggD=5ppNQ@mail.gmail.com> <CABirCh_0orFzaZAUrtg3Z+Jg0LdSGMZxuapVdKZgigEdKJJVXQ@mail.gmail.com> <CAGN7qDDbS5Vy65SqiSdVtxgz8W9w+8WO3n=2H4wpSdkaQNLBCQ@mail.gmail.com> <CABirCh-NiwtSMzs5J5=cqazNYGAKufA3s1Lz1cW-6YvhGbt8pg@mail.gmail.com> <CAGN7qDBqXxY-aWmb3kWwxXh=rfD1BfHCEiESs9yHiFkpxkPFig@mail.gmail.com> <CABirCh9RSb0SEMsqy9KHEV77h7s04hgq7G6evCYLFRM10Kh+1A@mail.gmail.com> <CAGN7qDA8fe42MUR-Dt1sxtCnN=hPYLe6TcasSfjV+q+i-UmrjA@mail.gmail.com> <alpine.DEB.2.00.1309052119410.7443@ps20323.dreamhostps.com> <5245F6D0.2090209@therealcha0s.net> <CAA0H+QTBEPDr65ZJS7Y9LrHi4PZJ89+nXROp98yfA9muSjefxQ@mail.gmail.com> <CABirCh9zgFgtZiO7o=GaBhHFF+Unz1CtKsAG_sLXfdh=1VmWkw@mail.gmail.com> Message-ID: <CAGN7qDA9roFayg71rFRjd1Bj9AtY=a1b1f-r6A0pTkxAmsmKoQ@mail.gmail.com> Yeah, this should be specified somewhere. As you point out, luckily everyone is in agreement. On Fri, Sep 27, 2013 at 7:41 PM, Glenn Maynard <glenn at zewt.org> wrote: > On Fri, Sep 27, 2013 at 4:38 PM, Jasper St. Pierre <jstpierre at mecheye.net > >wrote: > > > The issue here is that the canvas API does not specify how pixels are > sited > > on the canvas: if you imagine pixels as enlarged squares on a grid > (shush, > > I know), does an X coordinate of 5 name the center of the square, or the > > intersection between 4th and 5th squares? > > > > That's not the issue this thread is about. I don't know if it's specified > (though I suspect is is), but WebKit, Firefox and IE10's Canvas > implementations all use OpenGL's coordinate system. This can be seen in > the very first post in the thread, which renders consistently in all three > browsers. http://jsfiddle.net/V92Gn/128/ > > -- > Glenn Maynard > From benjamin at smedbergs.us Mon Sep 30 05:59:53 2013 From: benjamin at smedbergs.us (Benjamin Smedberg) Date: Mon, 30 Sep 2013 08:59:53 -0400 Subject: [whatwg] Supporting scanners on the web In-Reply-To: <CAOp6jLZj7o4S-qA4g5hs0rhj6UApX-hANMbLDzZd1pfjXmktGw@mail.gmail.com> References: <5244506E.3020808@smedbergs.us> <CAOp6jLZj7o4S-qA4g5hs0rhj6UApX-hANMbLDzZd1pfjXmktGw@mail.gmail.com> Message-ID: <524975C9.4030209@smedbergs.us> On 9/26/2013 10:11 PM, Robert O'Callahan wrote: > Is implementing a full scanning UI in a Web app in scope or out of scope? For now I intend to focus on implementing the scanning UI in the browser and just handing the site the final product. Any thoughts of exposing a fine-grained control over previews and incremental results needs significantly more thought about how that would work on both desktop and mobile devices. --BDS From cabanier at gmail.com Mon Sep 30 10:15:25 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Mon, 30 Sep 2013 10:15:25 -0700 Subject: [whatwg] Outline style to use for drawSystemFocusRing In-Reply-To: <CAFz-FYwi6tQ7WcODc3MBC=6pM_=G5ZONe=nVSHLs5EGTiUjE=w@mail.gmail.com> References: <CAFz-FYxS-sLLOMA2=5bj-aJ1bmsBq8w_4Rminw_JLCMnYaMfPw@mail.gmail.com> <alpine.DEB.2.00.1307242308540.27623@ps20323.dreamhostps.com> <CAGN7qDCdCR1F-D9PtEKUcHkh5KdwKhum4vEAyUQ0VkLeeC+PCA@mail.gmail.com> <alpine.DEB.2.00.1307292147040.27623@ps20323.dreamhostps.com> <CAGN7qDAaq8XnX1z_BbpLVhgE5m4j--b720ZuHSEzq_iN1es0=Q@mail.gmail.com> <alpine.DEB.2.00.1307300020510.27623@ps20323.dreamhostps.com> <CAGN7qDAjRPOQ25gQT+BY+sp8Y503_9KxTa1j2aZSGYU-9BmBVA@mail.gmail.com> <CAFz-FYzzPFU3g+fM+QGbEDAJ-3DSU2qGHY9R+heZRbAWVAN2rw@mail.gmail.com> <CAGN7qDDu3PNxK9PTVr09sqUc0FrOnXgRaQDwLXQ13BhH_=85Bw@mail.gmail.com> <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> <alpine.DEB.2.00.1309120051240.12199@ps20323.dreamhostps.com> <CAFz-FYwi6tQ7WcODc3MBC=6pM_=G5ZONe=nVSHLs5EGTiUjE=w@mail.gmail.com> Message-ID: <CAGN7qDDhuCSSbBtF6gLTUy06sKoNXub3hD6EcUCvKr4ojkzhMA@mail.gmail.com> On Thu, Sep 12, 2013 at 9:32 AM, Dominic Mazzoni <dmazzoni at google.com>wrote: > On Wed, Sep 11, 2013 at 5:54 PM, Ian Hickson <ian at hixie.ch> wrote: > > > On Tue, 10 Sep 2013, Dominic Mazzoni wrote: > > > > > > We've finished implementing drawSystemFocusRing and drawCustomFocusRing > > > in Chrome. Try it in Chrome 31 or higher (either canary or dev channel > > > should work today). You'll need to go to chrome://flags and enable > > > *experimental canvas features*, then restart the browser. > > > > > > Here's a demo I built that uses drawSystemFocusRing: > > > http://dmazzoni-google.github.io/canvas-focus-ring-demo/ > > > > Looks good. Was your conclusion that the spec was ok as is, or did you > > deviate from the spec in some way that needs a spec change > > > > I think drawSystemFocusRing is good to go. If you want, you can update the > spec to reflect that an implementation is available (behind a flag). > > Only one minor issue for clarification: if the current path is a line or > unclosed polygon, should it be closed (or otherwise outlined) when drawing > the focus ring? Currently we're not doing so in Chrome, but it might help > to clarify. For example, if the path is a line, what's drawn is just an > additional stroke on that line, not a "ring". > > I'm not as sure about drawCustomFocusRing. The spec says "If the user has > requested the use of particular focus rings", but I'm not aware of any > platform API we could use to query that. To the best of my knowledge, > assistive technology that draws its own focus rings, like ZoomText, > normally draws an additional focus ring with extra padding, rather than > replacing the system one. (Example: > http://www.aisquared.com/zoomtext/tour/enhancements#focus_enhancements) > > So, I'm not sure how I'd implement that part of the spec. Chrome definitely > has no plans to give users an additional preference for focus rings as a > browser setting. > > So, what we implemented in Chrome for drawCustomFocusRing is basically just > a function that notifies assistive technology of the bounding rect of the > focused region within the canvas. It's still useful, but if that's all it > does, then drawCustomFocusRing is a poor name. Perhaps it should be called > something like notifyFocusLocation or something like that. > 'drawCustomFocusRing' returns a boolean that signals the author that he is supposed to draw the focus ring. If you want to rename it, then maybe 'needsFocusRing' is better. 'drawSystemFocusRing' could then be simplified to 'drawFocusRing' From cabanier at gmail.com Mon Sep 30 13:25:41 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Mon, 30 Sep 2013 13:25:41 -0700 Subject: [whatwg] Outline style to use for drawSystemFocusRing In-Reply-To: <CAGN7qDDhuCSSbBtF6gLTUy06sKoNXub3hD6EcUCvKr4ojkzhMA@mail.gmail.com> References: <CAFz-FYxS-sLLOMA2=5bj-aJ1bmsBq8w_4Rminw_JLCMnYaMfPw@mail.gmail.com> <alpine.DEB.2.00.1307242308540.27623@ps20323.dreamhostps.com> <CAGN7qDCdCR1F-D9PtEKUcHkh5KdwKhum4vEAyUQ0VkLeeC+PCA@mail.gmail.com> <alpine.DEB.2.00.1307292147040.27623@ps20323.dreamhostps.com> <CAGN7qDAaq8XnX1z_BbpLVhgE5m4j--b720ZuHSEzq_iN1es0=Q@mail.gmail.com> <alpine.DEB.2.00.1307300020510.27623@ps20323.dreamhostps.com> <CAGN7qDAjRPOQ25gQT+BY+sp8Y503_9KxTa1j2aZSGYU-9BmBVA@mail.gmail.com> <CAFz-FYzzPFU3g+fM+QGbEDAJ-3DSU2qGHY9R+heZRbAWVAN2rw@mail.gmail.com> <CAGN7qDDu3PNxK9PTVr09sqUc0FrOnXgRaQDwLXQ13BhH_=85Bw@mail.gmail.com> <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> <alpine.DEB.2.00.1309120051240.12199@ps20323.dreamhostps.com> <CAFz-FYwi6tQ7WcODc3MBC=6pM_=G5ZONe=nVSHLs5EGTiUjE=w@mail.gmail.com> <CAGN7qDDhuCSSbBtF6gLTUy06sKoNXub3hD6EcUCvKr4ojkzhMA@mail.gmail.com> Message-ID: <CAGN7qDASLvnt8N=CfEKKpB9YYhAtnKkWP5q_KEkLVm9cCL=-2g@mail.gmail.com> Ian pointed out on IRC that 'drawCustomFocusRing' *could* draw if the user requested high contrast rings. (Since I prototyped it in Firefox which does not have this feature, I forgot about that case) In light of that, maybe it's OK to leave the spec as-is. ' notifyFocusLocation' is just as confusing... On Mon, Sep 30, 2013 at 10:15 AM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > On Thu, Sep 12, 2013 at 9:32 AM, Dominic Mazzoni <dmazzoni at google.com>wrote: > >> On Wed, Sep 11, 2013 at 5:54 PM, Ian Hickson <ian at hixie.ch> wrote: >> >> > On Tue, 10 Sep 2013, Dominic Mazzoni wrote: >> > > >> > > We've finished implementing drawSystemFocusRing and >> drawCustomFocusRing >> > > in Chrome. Try it in Chrome 31 or higher (either canary or dev channel >> > > should work today). You'll need to go to chrome://flags and enable >> > > *experimental canvas features*, then restart the browser. >> > > >> > > Here's a demo I built that uses drawSystemFocusRing: >> > > http://dmazzoni-google.github.io/canvas-focus-ring-demo/ >> > >> > Looks good. Was your conclusion that the spec was ok as is, or did you >> > deviate from the spec in some way that needs a spec change >> > >> >> I think drawSystemFocusRing is good to go. If you want, you can update the >> spec to reflect that an implementation is available (behind a flag). >> >> Only one minor issue for clarification: if the current path is a line or >> unclosed polygon, should it be closed (or otherwise outlined) when drawing >> the focus ring? Currently we're not doing so in Chrome, but it might help >> to clarify. For example, if the path is a line, what's drawn is just an >> additional stroke on that line, not a "ring". >> >> I'm not as sure about drawCustomFocusRing. The spec says "If the user has >> requested the use of particular focus rings", but I'm not aware of any >> platform API we could use to query that. To the best of my knowledge, >> assistive technology that draws its own focus rings, like ZoomText, >> normally draws an additional focus ring with extra padding, rather than >> replacing the system one. (Example: >> http://www.aisquared.com/zoomtext/tour/enhancements#focus_enhancements) >> >> So, I'm not sure how I'd implement that part of the spec. Chrome >> definitely >> has no plans to give users an additional preference for focus rings as a >> browser setting. >> >> So, what we implemented in Chrome for drawCustomFocusRing is basically >> just >> a function that notifies assistive technology of the bounding rect of the >> focused region within the canvas. It's still useful, but if that's all it >> does, then drawCustomFocusRing is a poor name. Perhaps it should be called >> something like notifyFocusLocation or something like that. >> > > 'drawCustomFocusRing' returns a boolean that signals the author that he > is supposed to draw the focus ring. > If you want to rename it, then maybe 'needsFocusRing' is better. > > 'drawSystemFocusRing' could then be simplified to 'drawFocusRing' > From dmazzoni at google.com Mon Sep 30 13:48:19 2013 From: dmazzoni at google.com (Dominic Mazzoni) Date: Mon, 30 Sep 2013 13:48:19 -0700 Subject: [whatwg] Outline style to use for drawSystemFocusRing In-Reply-To: <CAGN7qDASLvnt8N=CfEKKpB9YYhAtnKkWP5q_KEkLVm9cCL=-2g@mail.gmail.com> References: <CAFz-FYxS-sLLOMA2=5bj-aJ1bmsBq8w_4Rminw_JLCMnYaMfPw@mail.gmail.com> <alpine.DEB.2.00.1307242308540.27623@ps20323.dreamhostps.com> <CAGN7qDCdCR1F-D9PtEKUcHkh5KdwKhum4vEAyUQ0VkLeeC+PCA@mail.gmail.com> <alpine.DEB.2.00.1307292147040.27623@ps20323.dreamhostps.com> <CAGN7qDAaq8XnX1z_BbpLVhgE5m4j--b720ZuHSEzq_iN1es0=Q@mail.gmail.com> <alpine.DEB.2.00.1307300020510.27623@ps20323.dreamhostps.com> <CAGN7qDAjRPOQ25gQT+BY+sp8Y503_9KxTa1j2aZSGYU-9BmBVA@mail.gmail.com> <CAFz-FYzzPFU3g+fM+QGbEDAJ-3DSU2qGHY9R+heZRbAWVAN2rw@mail.gmail.com> <CAGN7qDDu3PNxK9PTVr09sqUc0FrOnXgRaQDwLXQ13BhH_=85Bw@mail.gmail.com> <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> <alpine.DEB.2.00.1309120051240.12199@ps20323.dreamhostps.com> <CAFz-FYwi6tQ7WcODc3MBC=6pM_=G5ZONe=nVSHLs5EGTiUjE=w@mail.gmail.com> <CAGN7qDDhuCSSbBtF6gLTUy06sKoNXub3hD6EcUCvKr4ojkzhMA@mail.gmail.com> <CAGN7qDASLvnt8N=CfEKKpB9YYhAtnKkWP5q_KEkLVm9cCL=-2g@mail.gmail.com> Message-ID: <CAFz-FYwBdi9-t1r+2i6X_zaZAuUuLWJtyHngysB70aqhkAnOGQ@mail.gmail.com> On Mon, Sep 30, 2013 at 1:25 PM, Rik Cabanier <cabanier at gmail.com> wrote: > Ian pointed out on IRC that 'drawCustomFocusRing' *could* draw if the > user requested high contrast rings. (Since I prototyped it in Firefox which > does not have this feature, I forgot about that case) > Yes, but I'm arguing that the high contrast rings is not a good idea and we should drop that part of the spec. Once that part is gone (or once no browser has plans to implement that part), drawCustomFocusRing no longer makes sense. > In light of that, maybe it's OK to leave the spec as-is. ' > notifyFocusLocation' is just as confusing... > I don't think notifyFocusLocation is just as confusing as having a drawCustomFocusRing API that never actually draws. I do agree that most web developers might not realize who is being notified and why, but they can at least surmise that *someone* cares about the focus location and wants to be told where it is. Here's my alternative idea, though: how about calling it something like scrollFocusedObjectIntoView, and have the *primary* purpose of the API be to make the browser scroll the viewport, if needed to make sure that the bounding box of the path is visible, if that object is focused. The drawFocusRing spec would be modified to specify that scrolling the viewport is part of the spec, too. Both APIs would also have accessibility implications, of course - but the average web developer who doesn't know much about accessibility would have two useful APIs for handling focused controls in a canvas, that are easy to test if they're working in any browser. - Dominic > > > > On Mon, Sep 30, 2013 at 10:15 AM, Rik Cabanier <cabanier at gmail.com> wrote: > >> >> >> >> On Thu, Sep 12, 2013 at 9:32 AM, Dominic Mazzoni <dmazzoni at google.com>wrote: >> >>> On Wed, Sep 11, 2013 at 5:54 PM, Ian Hickson <ian at hixie.ch> wrote: >>> >>> > On Tue, 10 Sep 2013, Dominic Mazzoni wrote: >>> > > >>> > > We've finished implementing drawSystemFocusRing and >>> drawCustomFocusRing >>> > > in Chrome. Try it in Chrome 31 or higher (either canary or dev >>> channel >>> > > should work today). You'll need to go to chrome://flags and enable >>> > > *experimental canvas features*, then restart the browser. >>> > > >>> > > Here's a demo I built that uses drawSystemFocusRing: >>> > > http://dmazzoni-google.github.io/canvas-focus-ring-demo/ >>> > >>> > Looks good. Was your conclusion that the spec was ok as is, or did you >>> > deviate from the spec in some way that needs a spec change >>> > >>> >>> I think drawSystemFocusRing is good to go. If you want, you can update >>> the >>> spec to reflect that an implementation is available (behind a flag). >>> >>> Only one minor issue for clarification: if the current path is a line or >>> unclosed polygon, should it be closed (or otherwise outlined) when >>> drawing >>> the focus ring? Currently we're not doing so in Chrome, but it might help >>> to clarify. For example, if the path is a line, what's drawn is just an >>> additional stroke on that line, not a "ring". >>> >>> I'm not as sure about drawCustomFocusRing. The spec says "If the user has >>> requested the use of particular focus rings", but I'm not aware of any >>> platform API we could use to query that. To the best of my knowledge, >>> assistive technology that draws its own focus rings, like ZoomText, >>> normally draws an additional focus ring with extra padding, rather than >>> replacing the system one. (Example: >>> http://www.aisquared.com/zoomtext/tour/enhancements#focus_enhancements) >>> >>> So, I'm not sure how I'd implement that part of the spec. Chrome >>> definitely >>> has no plans to give users an additional preference for focus rings as a >>> browser setting. >>> >>> So, what we implemented in Chrome for drawCustomFocusRing is basically >>> just >>> a function that notifies assistive technology of the bounding rect of the >>> focused region within the canvas. It's still useful, but if that's all it >>> does, then drawCustomFocusRing is a poor name. Perhaps it should be >>> called >>> something like notifyFocusLocation or something like that. >>> >> >> 'drawCustomFocusRing' returns a boolean that signals the author that he >> is supposed to draw the focus ring. >> If you want to rename it, then maybe 'needsFocusRing' is better. >> >> 'drawSystemFocusRing' could then be simplified to 'drawFocusRing' >> > > From wiltzius at chromium.org Mon Sep 30 14:03:06 2013 From: wiltzius at chromium.org (Tom Wiltzius) Date: Mon, 30 Sep 2013 14:03:06 -0700 Subject: [whatwg] Adding 2D Canvas features In-Reply-To: <alpine.DEB.2.00.1309272108410.12199@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <51D12692.4030002@artspark.co.jp> <CAK-G-KVLsECC4cETFYdcPyoqigaaoRhUxcezhMG3jZc2fAViRg@mail.gmail.com> <alpine.DEB.2.00.1309052049070.7443@ps20323.dreamhostps.com> <CAA5isUYmMm9sHu=_Ybwmhw7GWfO+vRpP+8MdM_+OXKPCc+i4+Q@mail.gmail.com> <CAK-G-KUOzNXhRfZRTtmuYFHHcHDriSodcRmoORGqi4XhFevNuQ@mail.gmail.com> <alpine.DEB.2.00.1309272108410.12199@ps20323.dreamhostps.com> Message-ID: <CAK-G-KV64xnPGLfz+66bRFpgt5escPqPxZX8rR4SuT+k2xRC0g@mail.gmail.com> On Fri, Sep 27, 2013 at 2:21 PM, Ian Hickson <ian at hixie.ch> wrote: > On Thu, 5 Sep 2013, Tom Wiltzius wrote: > > > > Meanwhile this doesn't change the other Canvas2D-related work ongoing in > > the Chromium project, so we're still keen to see some new features added > > to the Canvas spec. Ian if it would help to identify items in the spec > > that Chromium doesn't intend to implement (at least any time soon), we > > can attempt to do so. > > If there are specific things in the spec that you think are bad and should > be removed, please do raise them on the mailing list, yes. > I think we're reasonably certain that *HD methods should be removed, but those are the only solid ones. > > If there are specific things not in the spec that you have implemented, > then please file a bug pointing to the documentation for whatever you have > implemented, using: http://whatwg.org/newbug > > If there's multiple implementations, and HTML is the right spec, then I'll > pretty much automatically spec it. Otherwise, it'll be based on whether it > makes sense and has use cases. (So far example, I haven't added canvas > text decoration APIs, which have been raised as something Chrome might > implement, as discussed in my last e-mail to this list. The alpha > parameter, though, needs speccing, I just haven't gotten around to it > yet -- it's on my list though.) > Great, I was wondering specifically about the status of the alpha attribute-- glad to hear it's just spec'ing that needs to happen, I wasn't clear on if this was blocked on "no new features" or not. Thanks! > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > From junov at google.com Mon Sep 30 14:17:58 2013 From: junov at google.com (Justin Novosad) Date: Mon, 30 Sep 2013 17:17:58 -0400 Subject: [whatwg] 2D canvas feature proposal: text decoration In-Reply-To: <alpine.DEB.2.00.1309272041490.12199@ps20323.dreamhostps.com> References: <CABpaAqS79N2Xfqy+CrniQJBDSzmaYgxFmdboBK9AtMCFGrvjTg@mail.gmail.com> <CAGN7qDCpb3CWi0j9uibGfn4wKCpf+YfUHLfzj7kJr46Z=TuXew@mail.gmail.com> <CABpaAqTFpDq5HMQyDCRVx3ru_KVeUniaySb6eFocnrg7kgqXgQ@mail.gmail.com> <CAGN7qDD2Z=g11F2PXMFtFQPedmfEtzs4oKsQSsRiJ8qwGQk2pw@mail.gmail.com> <CAAWBYDCuv9gxz1utnsMQ2OsYhgo+gJH6W+_=5Gko7XmJekoSKw@mail.gmail.com> <CAGN7qDC6Dj1aoAtwiRzdm5L83=4yq2GhpXjhddyAQbF44LtwYQ@mail.gmail.com> <CAAWBYDDbpXtAs3V8vvPBWXe4aNOfy+hU-2bre3_ie-sSQ7Q=rQ@mail.gmail.com> <CAGN7qDBT1+=m_yL=RTR1M0bhY6s3gtEXwLgnfXZTAsBEOMEFdg@mail.gmail.com> <CABpaAqQ87sLn_dqHwr9ZPLeeE665_2irC+mMhDGK4j=hWd7fTw@mail.gmail.com> <51716E59.6080609@mit.edu> <alpine.DEB.2.00.1308202224320.27209@ps20323.dreamhostps.com> <CABpaAqTWJq+-zrGj-Rnme1XLbDyp-2m5Bpnx8ubuo1QLr9SJWw@mail.gmail.com> <alpine.DEB.2.00.1309272041490.12199@ps20323.dreamhostps.com> Message-ID: <CABpaAqQTpMMuW_RXhp74kKqFBiP6OhngvsFnb7or5DZioYFUOQ@mail.gmail.com> On Fri, Sep 27, 2013 at 5:05 PM, Ian Hickson <ian at hixie.ch> wrote: > > > Text decoration can theoretically be drawn directly by the application > > by using font metrics to compute decoration positions, but this is often > > very complex to do correctly in a truly portable way. > > We could add underline metrics to TextMetrics if that would help. > > Perhaps that would be the right solution, but I don't know enough about metrics to authoritatively state what information is missing. The fact that most browsers do not fully support the text metrics as currently spec'ed does not help either (I know, Chrome is one of the worst offenders w.r.t. metrics support). > > If doing things with CSS and the DOM is > too slow, then we should fix that, we shouldn't just tell people to > rewrite their apps in <canvas>. > Easier said than done. In theory, it should be possible to obtain canvas-like performance when DOM usage is constrained to styles that make layout calculations trivial (as in no-op). However, this is still a more or less unsolved problem despite the best efforts of a large number of very smart people. Let's not hold our breaths. > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > From cabanier at gmail.com Mon Sep 30 15:21:01 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Mon, 30 Sep 2013 15:21:01 -0700 Subject: [whatwg] Outline style to use for drawSystemFocusRing In-Reply-To: <CAFz-FYwBdi9-t1r+2i6X_zaZAuUuLWJtyHngysB70aqhkAnOGQ@mail.gmail.com> References: <CAFz-FYxS-sLLOMA2=5bj-aJ1bmsBq8w_4Rminw_JLCMnYaMfPw@mail.gmail.com> <alpine.DEB.2.00.1307242308540.27623@ps20323.dreamhostps.com> <CAGN7qDCdCR1F-D9PtEKUcHkh5KdwKhum4vEAyUQ0VkLeeC+PCA@mail.gmail.com> <alpine.DEB.2.00.1307292147040.27623@ps20323.dreamhostps.com> <CAGN7qDAaq8XnX1z_BbpLVhgE5m4j--b720ZuHSEzq_iN1es0=Q@mail.gmail.com> <alpine.DEB.2.00.1307300020510.27623@ps20323.dreamhostps.com> <CAGN7qDAjRPOQ25gQT+BY+sp8Y503_9KxTa1j2aZSGYU-9BmBVA@mail.gmail.com> <CAFz-FYzzPFU3g+fM+QGbEDAJ-3DSU2qGHY9R+heZRbAWVAN2rw@mail.gmail.com> <CAGN7qDDu3PNxK9PTVr09sqUc0FrOnXgRaQDwLXQ13BhH_=85Bw@mail.gmail.com> <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> <alpine.DEB.2.00.1309120051240.12199@ps20323.dreamhostps.com> <CAFz-FYwi6tQ7WcODc3MBC=6pM_=G5ZONe=nVSHLs5EGTiUjE=w@mail.gmail.com> <CAGN7qDDhuCSSbBtF6gLTUy06sKoNXub3hD6EcUCvKr4ojkzhMA@mail.gmail.com> <CAGN7qDASLvnt8N=CfEKKpB9YYhAtnKkWP5q_KEkLVm9cCL=-2g@mail.gmail.com> <CAFz-FYwBdi9-t1r+2i6X_zaZAuUuLWJtyHngysB70aqhkAnOGQ@mail.gmail.com> Message-ID: <CAGN7qDCHL9g8TsBFpFNQfu3Pjgf-KTRQavzz=QBs_M4H86aL8g@mail.gmail.com> On Mon, Sep 30, 2013 at 1:48 PM, Dominic Mazzoni <dmazzoni at google.com>wrote: > On Mon, Sep 30, 2013 at 1:25 PM, Rik Cabanier <cabanier at gmail.com> wrote: > >> Ian pointed out on IRC that 'drawCustomFocusRing' *could* draw if the >> user requested high contrast rings. (Since I prototyped it in Firefox which >> does not have this feature, I forgot about that case) >> > > Yes, but I'm arguing that the high contrast rings is not a good idea and > we should drop that part of the spec. Once that part is gone (or once no > browser has plans to implement that part), drawCustomFocusRing no longer > makes sense. > I just checked Windows and they offer the option "Make the focus rectangle thicker". I checked IE and it honors that setting. It's too bad that we didn't get feedback from them but it does look like this is something IE would implement. > > >> In light of that, maybe it's OK to leave the spec as-is. ' >> notifyFocusLocation' is just as confusing... >> > > I don't think notifyFocusLocation is just as confusing as having a drawCustomFocusRing > API that never actually draws. I do agree that most web developers might > not realize who is being notified and why, but they can at least surmise > that *someone* cares about the focus location and wants to be told where it > is. > But it's not a 'notify' action though. You're basically asking the browser if the author should draw the focus area (while also telling the browser about the region) > > Here's my alternative idea, though: how about calling it something like > scrollFocusedObjectIntoView, and have the *primary* purpose of the API be > to make the browser scroll the viewport, if needed to make sure that the > bounding box of the path is visible, if that object is focused. The > drawFocusRing spec would be modified to specify that scrolling the viewport > is part of the spec, too. > That sounds very much like 'scrollPathIntoView'. I think that this is changing the API too much. > > Both APIs would also have accessibility implications, of course - but the > average web developer who doesn't know much about accessibility would have > two useful APIs for handling focused controls in a canvas, that are easy to > test if they're working in any browser. > > - Dominic > > >> >> >> >> On Mon, Sep 30, 2013 at 10:15 AM, Rik Cabanier <cabanier at gmail.com>wrote: >> >>> >>> >>> >>> On Thu, Sep 12, 2013 at 9:32 AM, Dominic Mazzoni <dmazzoni at google.com>wrote: >>> >>>> On Wed, Sep 11, 2013 at 5:54 PM, Ian Hickson <ian at hixie.ch> wrote: >>>> >>>> > On Tue, 10 Sep 2013, Dominic Mazzoni wrote: >>>> > > >>>> > > We've finished implementing drawSystemFocusRing and >>>> drawCustomFocusRing >>>> > > in Chrome. Try it in Chrome 31 or higher (either canary or dev >>>> channel >>>> > > should work today). You'll need to go to chrome://flags and enable >>>> > > *experimental canvas features*, then restart the browser. >>>> > > >>>> > > Here's a demo I built that uses drawSystemFocusRing: >>>> > > http://dmazzoni-google.github.io/canvas-focus-ring-demo/ >>>> > >>>> > Looks good. Was your conclusion that the spec was ok as is, or did you >>>> > deviate from the spec in some way that needs a spec change >>>> > >>>> >>>> I think drawSystemFocusRing is good to go. If you want, you can update >>>> the >>>> spec to reflect that an implementation is available (behind a flag). >>>> >>>> Only one minor issue for clarification: if the current path is a line or >>>> unclosed polygon, should it be closed (or otherwise outlined) when >>>> drawing >>>> the focus ring? Currently we're not doing so in Chrome, but it might >>>> help >>>> to clarify. For example, if the path is a line, what's drawn is just an >>>> additional stroke on that line, not a "ring". >>>> >>>> I'm not as sure about drawCustomFocusRing. The spec says "If the user >>>> has >>>> requested the use of particular focus rings", but I'm not aware of any >>>> platform API we could use to query that. To the best of my knowledge, >>>> assistive technology that draws its own focus rings, like ZoomText, >>>> normally draws an additional focus ring with extra padding, rather than >>>> replacing the system one. (Example: >>>> http://www.aisquared.com/zoomtext/tour/enhancements#focus_enhancements) >>>> >>>> So, I'm not sure how I'd implement that part of the spec. Chrome >>>> definitely >>>> has no plans to give users an additional preference for focus rings as a >>>> browser setting. >>>> >>>> So, what we implemented in Chrome for drawCustomFocusRing is basically >>>> just >>>> a function that notifies assistive technology of the bounding rect of >>>> the >>>> focused region within the canvas. It's still useful, but if that's all >>>> it >>>> does, then drawCustomFocusRing is a poor name. Perhaps it should be >>>> called >>>> something like notifyFocusLocation or something like that. >>>> >>> >>> 'drawCustomFocusRing' returns a boolean that signals the author that he >>> is supposed to draw the focus ring. >>> If you want to rename it, then maybe 'needsFocusRing' is better. >>> >>> 'drawSystemFocusRing' could then be simplified to 'drawFocusRing' >>> >> >> > From dmazzoni at google.com Mon Sep 30 15:31:05 2013 From: dmazzoni at google.com (Dominic Mazzoni) Date: Mon, 30 Sep 2013 15:31:05 -0700 Subject: [whatwg] Outline style to use for drawSystemFocusRing In-Reply-To: <CAGN7qDCHL9g8TsBFpFNQfu3Pjgf-KTRQavzz=QBs_M4H86aL8g@mail.gmail.com> References: <CAFz-FYxS-sLLOMA2=5bj-aJ1bmsBq8w_4Rminw_JLCMnYaMfPw@mail.gmail.com> <alpine.DEB.2.00.1307242308540.27623@ps20323.dreamhostps.com> <CAGN7qDCdCR1F-D9PtEKUcHkh5KdwKhum4vEAyUQ0VkLeeC+PCA@mail.gmail.com> <alpine.DEB.2.00.1307292147040.27623@ps20323.dreamhostps.com> <CAGN7qDAaq8XnX1z_BbpLVhgE5m4j--b720ZuHSEzq_iN1es0=Q@mail.gmail.com> <alpine.DEB.2.00.1307300020510.27623@ps20323.dreamhostps.com> <CAGN7qDAjRPOQ25gQT+BY+sp8Y503_9KxTa1j2aZSGYU-9BmBVA@mail.gmail.com> <CAFz-FYzzPFU3g+fM+QGbEDAJ-3DSU2qGHY9R+heZRbAWVAN2rw@mail.gmail.com> <CAGN7qDDu3PNxK9PTVr09sqUc0FrOnXgRaQDwLXQ13BhH_=85Bw@mail.gmail.com> <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> <alpine.DEB.2.00.1309120051240.12199@ps20323.dreamhostps.com> <CAFz-FYwi6tQ7WcODc3MBC=6pM_=G5ZONe=nVSHLs5EGTiUjE=w@mail.gmail.com> <CAGN7qDDhuCSSbBtF6gLTUy06sKoNXub3hD6EcUCvKr4ojkzhMA@mail.gmail.com> <CAGN7qDASLvnt8N=CfEKKpB9YYhAtnKkWP5q_KEkLVm9cCL=-2g@mail.gmail.com> <CAFz-FYwBdi9-t1r+2i6X_zaZAuUuLWJtyHngysB70aqhkAnOGQ@mail.gmail.com> <CAGN7qDCHL9g8TsBFpFNQfu3Pjgf-KTRQavzz=QBs_M4H86aL8g@mail.gmail.com> Message-ID: <CAFz-FYyEKYyJYvTMXDJ1f+zmZpxSMpG26xxX37Ne2tDd9tq5Yg@mail.gmail.com> On Mon, Sep 30, 2013 at 3:21 PM, Rik Cabanier <cabanier at gmail.com> wrote: > I just checked Windows and they offer the option "Make the focus rectangle > thicker". I checked IE and it honors that setting. > It's too bad that we didn't get feedback from them but it does look like > this is something IE would implement. > Yes, and drawSystemFocusRing should respect the thicker focus rectangle. I don't think that drawCustomFocusRing should switch to the system focus rectangle style just because that preference was set - it might look horrible on a particular canvas. Plus, Rich's original argument wasn't about the "make the focus rectangle thicker", it was about handling Windows high contrast mode correctly - but again, I still don't think that the system is going to do a better job at drawing a focus ring on a canvas just because high contrast mode is on. What we really need is an API for web developers to know if high contrast mode is on, and that's orthogonal to canvas. Here's my alternative idea, though: how about calling it something like >> scrollFocusedObjectIntoView, and have the *primary* purpose of the API be >> to make the browser scroll the viewport, if needed to make sure that the >> bounding box of the path is visible, if that object is focused. The >> drawFocusRing spec would be modified to specify that scrolling the viewport >> is part of the spec, too. >> > > That sounds very much like 'scrollPathIntoView'. > I think that this is changing the API too much. > I still don't understand why we're in a situation where we can't change it too much. If the choice is ship drawCustomFocusRing with flaws or delay it until the next revision so we can get it right, my vote is firmly for the latter. I do not support shipping it as-is. - Dominic From ian at hixie.ch Mon Sep 30 16:00:46 2013 From: ian at hixie.ch (Ian Hickson) Date: Mon, 30 Sep 2013 23:00:46 +0000 (UTC) Subject: [whatwg] Adding 2D Canvas features In-Reply-To: <CAK-G-KV64xnPGLfz+66bRFpgt5escPqPxZX8rR4SuT+k2xRC0g@mail.gmail.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <Pine.LNX.4.64.1306141728120.17279@ps20323.dreamhostps.com> <CAGN7qDBhOpfhsdtW0mCom8Y5TK4KdKV=36piBBvL3zLbxVKjZA@mail.gmail.com> <CAK-G-KXVBtMubJFqfkXBDJqskY0KQ=w5dTGPEy9oU90znif=7w@mail.gmail.com> <51D12692.4030002@artspark.co.jp> <CAK-G-KVLsECC4cETFYdcPyoqigaaoRhUxcezhMG3jZc2fAViRg@mail.gmail.com> <alpine.DEB.2.00.1309052049070.7443@ps20323.dreamhostps.com> <CAA5isUYmMm9sHu=_Ybwmhw7GWfO+vRpP+8MdM_+OXKPCc+i4+Q@mail.gmail.com> <CAK-G-KUOzNXhRfZRTtmuYFHHcHDriSodcRmoORGqi4XhFevNuQ@mail.gmail.com> <alpine.DEB.2.00.1309272108410.12199@ps20323.dreamhostps.com> <CAK-G-KV64xnPGLfz+66bRFpgt5escPqPxZX8rR4SuT+k2xRC0g@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309302257590.20189@ps20323.dreamhostps.com> On Mon, 30 Sep 2013, Tom Wiltzius wrote: > On Fri, Sep 27, 2013 at 2:21 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Thu, 5 Sep 2013, Tom Wiltzius wrote: > > > > > > Meanwhile this doesn't change the other Canvas2D-related work > > > ongoing in the Chromium project, so we're still keen to see some new > > > features added to the Canvas spec. Ian if it would help to identify > > > items in the spec that Chromium doesn't intend to implement (at > > > least any time soon), we can attempt to do so. > > > > If there are specific things in the spec that you think are bad and > > should be removed, please do raise them on the mailing list, yes. > > I think we're reasonably certain that *HD methods should be removed, but > those are the only solid ones. Yeah those are going to be cut, I'm just trying to figure out how to replace them. See: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Sep/thread.html#msg68 > > If there are specific things not in the spec that you have > > implemented, then please file a bug pointing to the documentation for > > whatever you have implemented, using: http://whatwg.org/newbug > > > > If there's multiple implementations, and HTML is the right spec, then > > I'll pretty much automatically spec it. Otherwise, it'll be based on > > whether it makes sense and has use cases. (So far example, I haven't > > added canvas text decoration APIs, which have been raised as something > > Chrome might implement, as discussed in my last e-mail to this list. > > The alpha parameter, though, needs speccing, I just haven't gotten > > around to it yet -- it's on my list though.) > > Great, I was wondering specifically about the status of the alpha > attribute-- glad to hear it's just spec'ing that needs to happen, I > wasn't clear on if this was blocked on "no new features" or not. Thanks! The idea of limiting the rate of spec additions is to limit the rate of new implementations. If the implementations already exist, there's no point not adding it to the spec. :-) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Mon Sep 30 16:10:25 2013 From: ian at hixie.ch (Ian Hickson) Date: Mon, 30 Sep 2013 23:10:25 +0000 (UTC) Subject: [whatwg] Outline style to use for drawSystemFocusRing In-Reply-To: <CAFz-FYwBdi9-t1r+2i6X_zaZAuUuLWJtyHngysB70aqhkAnOGQ@mail.gmail.com> References: <CAFz-FYxS-sLLOMA2=5bj-aJ1bmsBq8w_4Rminw_JLCMnYaMfPw@mail.gmail.com> <alpine.DEB.2.00.1307292147040.27623@ps20323.dreamhostps.com> <CAGN7qDAaq8XnX1z_BbpLVhgE5m4j--b720ZuHSEzq_iN1es0=Q@mail.gmail.com> <alpine.DEB.2.00.1307300020510.27623@ps20323.dreamhostps.com> <CAGN7qDAjRPOQ25gQT+BY+sp8Y503_9KxTa1j2aZSGYU-9BmBVA@mail.gmail.com> <CAFz-FYzzPFU3g+fM+QGbEDAJ-3DSU2qGHY9R+heZRbAWVAN2rw@mail.gmail.com> <CAGN7qDDu3PNxK9PTVr09sqUc0FrOnXgRaQDwLXQ13BhH_=85Bw@mail.gmail.com> <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> <alpine.DEB.2.00.1309120051240.12199@ps20323.dreamhostps.com> <CAFz-FYwi6tQ7WcODc3MBC=6pM_=G5ZONe=nVSHLs5EGTiUjE=w@mail.gmail.com> <CAGN7qDDhuCSSbBtF6gLTUy06sKoNXub3hD6EcUCvKr4ojkzhMA@mail.gmail.com> <CAGN7qDASLvnt8N=CfEKKpB9YYhAtnKkWP5q_KEkLVm9cCL=-2g@mail.gmail.com> <CAFz-FYwBdi9-t1r+2i6X_zaZAuUuLWJtyHngysB70aqhkAnOGQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309302300540.20189@ps20323.dreamhostps.com> On Mon, 30 Sep 2013, Rik Cabanier wrote: > > 'drawCustomFocusRing' returns a boolean that signals the author that he > is supposed to draw the focus ring. If you want to rename it, then maybe > 'needsFocusRing' is better. > > 'drawSystemFocusRing' could then be simplified to 'drawFocusRing' On Mon, 30 Sep 2013, Rik Cabanier wrote: > > Ian pointed out on IRC that 'drawCustomFocusRing' *could* draw if the > user requested high contrast rings. (Since I prototyped it in Firefox > which does not have this feature, I forgot about that case) > > In light of that, maybe it's OK to leave the spec as-is. ' > notifyFocusLocation' is just as confusing... Yeah... The current name isn't great, but I don't know what would be better (without making its name an essay or something). On Mon, 30 Sep 2013, Dominic Mazzoni wrote: > > Yes, but I'm arguing that the high contrast rings is not a good idea and > we should drop that part of the spec. Some users have great trouble seeing the default focus rings. > Once that part is gone (or once no browser has plans to implement that > part), drawCustomFocusRing no longer makes sense. It's certainly true that if we don't want to support users with poor vision, the API would be simpler. But I don't think that's an option. We don't get to arbitrarily ignore some users. But drawCustomFocusRing() does more than just draw high-contrast focus rings. It also moves the magnification, moves the screen-reader focus, etc. It does everything drawSystemFocusRing() does other than draw the actual focus ring. > Here's my alternative idea, though: how about calling it something like > scrollFocusedObjectIntoView, and have the *primary* purpose of the API > be to make the browser scroll the viewport, if needed to make sure that > the bounding box of the path is visible, if that object is focused. The > drawFocusRing spec would be modified to specify that scrolling the > viewport is part of the spec, too. How would this differ from scrollPathIntoView() ? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Mon Sep 30 16:12:08 2013 From: ian at hixie.ch (Ian Hickson) Date: Mon, 30 Sep 2013 23:12:08 +0000 (UTC) Subject: [whatwg] Outline style to use for drawSystemFocusRing In-Reply-To: <CAFz-FYyEKYyJYvTMXDJ1f+zmZpxSMpG26xxX37Ne2tDd9tq5Yg@mail.gmail.com> References: <CAFz-FYxS-sLLOMA2=5bj-aJ1bmsBq8w_4Rminw_JLCMnYaMfPw@mail.gmail.com> <alpine.DEB.2.00.1307300020510.27623@ps20323.dreamhostps.com> <CAGN7qDAjRPOQ25gQT+BY+sp8Y503_9KxTa1j2aZSGYU-9BmBVA@mail.gmail.com> <CAFz-FYzzPFU3g+fM+QGbEDAJ-3DSU2qGHY9R+heZRbAWVAN2rw@mail.gmail.com> <CAGN7qDDu3PNxK9PTVr09sqUc0FrOnXgRaQDwLXQ13BhH_=85Bw@mail.gmail.com> <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> <alpine.DEB.2.00.1309120051240.12199@ps20323.dreamhostps.com> <CAFz-FYwi6tQ7WcODc3MBC=6pM_=G5ZONe=nVSHLs5EGTiUjE=w@mail.gmail.com> <CAGN7qDDhuCSSbBtF6gLTUy06sKoNXub3hD6EcUCvKr4ojkzhMA@mail.gmail.com> <CAGN7qDASLvnt8N=CfEKKpB9YYhAtnKkWP5q_KEkLVm9cCL=-2g@mail.gmail.com> <CAFz-FYwBdi9-t1r+2i6X_zaZAuUuLWJtyHngysB70aqhkAnOGQ@mail.gmail.com> <CAGN7qDCHL9g8TsBFpFNQfu3Pjgf-KTRQavzz=QBs_M4H86aL8g@mail.gmail.com> <CAFz-FYyEKYyJYvTMXDJ1f+zmZpxSMpG26xxX37Ne2tDd9tq5Yg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1309302310570.20189@ps20323.dreamhostps.com> On Mon, 30 Sep 2013, Dominic Mazzoni wrote: > > I don't think that drawCustomFocusRing should switch to the system focus > rectangle style just because that preference was set - it might look > horrible on a particular canvas. It's the whole point of the feature. Draw the focus ring the way the user needs it to be drawn, if there's a special need, otherwise, let me draw it my fancy hard-to-see way. > If the choice is ship drawCustomFocusRing with flaws or delay it until > the next revision so we can get it right, my vote is firmly for the > latter. I do not support shipping it as-is. I don't understand what the problem is with the current API, but I agree that if it's broken it should be fixed. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From chaals at yandex-team.ru Mon Sep 30 16:41:17 2013 From: chaals at yandex-team.ru (Charles McCathie Nevile) Date: Tue, 01 Oct 2013 01:41:17 +0200 Subject: [whatwg] Outline style to use for drawSystemFocusRing In-Reply-To: <alpine.DEB.2.00.1309302300540.20189@ps20323.dreamhostps.com> References: <CAFz-FYxS-sLLOMA2=5bj-aJ1bmsBq8w_4Rminw_JLCMnYaMfPw@mail.gmail.com> <alpine.DEB.2.00.1307292147040.27623@ps20323.dreamhostps.com> <CAGN7qDAaq8XnX1z_BbpLVhgE5m4j--b720ZuHSEzq_iN1es0=Q@mail.gmail.com> <alpine.DEB.2.00.1307300020510.27623@ps20323.dreamhostps.com> <CAGN7qDAjRPOQ25gQT+BY+sp8Y503_9KxTa1j2aZSGYU-9BmBVA@mail.gmail.com> <CAFz-FYzzPFU3g+fM+QGbEDAJ-3DSU2qGHY9R+heZRbAWVAN2rw@mail.gmail.com> <CAGN7qDDu3PNxK9PTVr09sqUc0FrOnXgRaQDwLXQ13BhH_=85Bw@mail.gmail.com> <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> <alpine.DEB.2.00.1309120051240.12199@ps20323.dreamhostps.com> <CAFz-FYwi6tQ7WcODc3MBC=6pM_=G5ZONe=nVSHLs5EGTiUjE=w@mail.gmail.com> <CAGN7qDDhuCSSbBtF6gLTUy06sKoNXub3hD6EcUCvKr4ojkzhMA@mail.gmail.com> <CAGN7qDASLvnt8N=CfEKKpB9YYhAtnKkWP5q_KEkLVm9cCL=-2g@mail.gmail.com> <CAFz-FYwBdi9-t1r+2i6X_zaZAuUuLWJtyHngysB70aqhkAnOGQ@mail.gmail.com> <alpine.DEB.2.00.1309302300540.20189@ps20323.dreamhostps.com> Message-ID: <op.w38z23pdy3oazb@chaals.local> On Tue, 01 Oct 2013 01:10:25 +0200, Ian Hickson <ian at hixie.ch> wrote: > On Mon, 30 Sep 2013, Rik Cabanier wrote: >> >> 'drawCustomFocusRing' returns a boolean that signals the author that he >> is supposed to draw the focus ring. If you want to rename it, then maybe >> 'needsFocusRing' is better. >> >> 'drawSystemFocusRing' could then be simplified to 'drawFocusRing' > > On Mon, 30 Sep 2013, Rik Cabanier wrote: >> >> Ian pointed out on IRC that 'drawCustomFocusRing' *could* draw if the >> user requested high contrast rings. (Since I prototyped it in Firefox >> which does not have this feature, I forgot about that case) >> >> In light of that, maybe it's OK to leave the spec as-is. ' >> notifyFocusLocation' is just as confusing... > > Yeah... The current name isn't great, but I don't know what would be > better (without making its name an essay or something). Right... > On Mon, 30 Sep 2013, Dominic Mazzoni wrote: >> >> Yes, but I'm arguing that the high contrast rings is not a good idea and >> we should drop that part of the spec. > > Some users have great trouble seeing the default focus rings. yeah. >> Once that part is gone (or once no browser has plans to implement that >> part), drawCustomFocusRing no longer makes sense. > > It's certainly true that if we don't want to support users with poor > vision, the API would be simpler. But I don't think that's an option. We > don't get to arbitrarily ignore some users. Yes, I hope not :) > But drawCustomFocusRing() does more than just draw high-contrast focus > rings. It also moves the magnification, moves the screen-reader focus, > etc. It does everything drawSystemFocusRing() does other than draw the > actual focus ring. So it seems that a real question is whether browsers prefer to deal with two APIs, or allow customisation of "the" focus ring. which comes down to a question of implementation strategy - do browsers rely on a system focus style, or draw it themselves, feeding from a system default style? >> Here's my alternative idea, though: how about calling it something like >> scrollFocusedObjectIntoView, and have the *primary* purpose of the API >> be to make the browser scroll the viewport, if needed to make sure that >> the bounding box of the path is visible, if that object is focused. The >> drawFocusRing spec would be modified to specify that scrolling the >> viewport is part of the spec, too. > > How would this differ from scrollPathIntoView() ? cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex chaals at yandex-team.ru Find more at http://yandex.com From dmazzoni at google.com Mon Sep 30 16:51:36 2013 From: dmazzoni at google.com (Dominic Mazzoni) Date: Mon, 30 Sep 2013 16:51:36 -0700 Subject: [whatwg] Outline style to use for drawSystemFocusRing In-Reply-To: <alpine.DEB.2.00.1309302310570.20189@ps20323.dreamhostps.com> References: <CAFz-FYxS-sLLOMA2=5bj-aJ1bmsBq8w_4Rminw_JLCMnYaMfPw@mail.gmail.com> <alpine.DEB.2.00.1307300020510.27623@ps20323.dreamhostps.com> <CAGN7qDAjRPOQ25gQT+BY+sp8Y503_9KxTa1j2aZSGYU-9BmBVA@mail.gmail.com> <CAFz-FYzzPFU3g+fM+QGbEDAJ-3DSU2qGHY9R+heZRbAWVAN2rw@mail.gmail.com> <CAGN7qDDu3PNxK9PTVr09sqUc0FrOnXgRaQDwLXQ13BhH_=85Bw@mail.gmail.com> <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> <alpine.DEB.2.00.1309120051240.12199@ps20323.dreamhostps.com> <CAFz-FYwi6tQ7WcODc3MBC=6pM_=G5ZONe=nVSHLs5EGTiUjE=w@mail.gmail.com> <CAGN7qDDhuCSSbBtF6gLTUy06sKoNXub3hD6EcUCvKr4ojkzhMA@mail.gmail.com> <CAGN7qDASLvnt8N=CfEKKpB9YYhAtnKkWP5q_KEkLVm9cCL=-2g@mail.gmail.com> <CAFz-FYwBdi9-t1r+2i6X_zaZAuUuLWJtyHngysB70aqhkAnOGQ@mail.gmail.com> <CAGN7qDCHL9g8TsBFpFNQfu3Pjgf-KTRQavzz=QBs_M4H86aL8g@mail.gmail.com> <CAFz-FYyEKYyJYvTMXDJ1f+zmZpxSMpG26xxX37Ne2tDd9tq5Yg@mail.gmail.com> <alpine.DEB.2.00.1309302310570.20189@ps20323.dreamhostps.com> Message-ID: <CAFz-FYxuYUg9ZLWkvORKOPsGjexRtFa9C2WsvN_b4Y-NQ_yE9A@mail.gmail.com> On Mon, Sep 30, 2013 at 4:12 PM, Ian Hickson <ian at hixie.ch> wrote: > > Some users have great trouble seeing the default focus rings. > ... > It's certainly true that if we don't want to support users with poor > vision, the API would be simpler. But I don't think that's an option. We > don't get to arbitrarily ignore some users. Of course not! I'm not arguing against supporting those users. The correct thing to do for those users is to use accessibility APIs to make the operating system aware of the focused object and its bounds. If users have ZoomText or MAGic installed, or if they're using VoiceOver or Orca, their assistive technology will draw its own focus ring *in addition* to the application's focus ring. No other application hides its focus ring just because, e.g., ZoomText is drawing a focus ring. The rest of the web doesn't do it. Why do we need it for canvas? On Mon, 30 Sep 2013, Dominic Mazzoni wrote: > > > > I don't think that drawCustomFocusRing should switch to the system focus > > rectangle style just because that preference was set - it might look > > horrible on a particular canvas. > > It's the whole point of the feature. Draw the focus ring the way the user > needs it to be drawn, if there's a special need, otherwise, let me draw it > my fancy hard-to-see way. > The problem is that there aren't existing operating system or browser settings that specifies that the user wants better focus rings. There are tools that draw additional focus rings, and preferences that control the appearance of the default focus ring, but no toggle that says *applications* should or shouldn't draw focus rings. Finally, as a meta-argument, if we really want a preference for custom focus rings, then wouldn't we want that for the rest of the web? If I'm building a custom form control and I need to choose a drawing style when focused, wouldn't I want to know if the user wanted custom focus rings, too? In other words, what makes this need canvas-specific? > How would this differ from scrollPathIntoView() ? It would take an element in fallback content as an argument. That would allow assistive technology to be notified. - Dominic From jrburke at gmail.com Mon Sep 30 17:27:18 2013 From: jrburke at gmail.com (James Burke) Date: Mon, 30 Sep 2013 17:27:18 -0700 Subject: [whatwg] Notifications: usage feedback In-Reply-To: <CAArhhishhjN4TnbXLicEV2fV7O77RY-r1M5Z1M-oJcsMzDOnoA@mail.gmail.com> References: <CAHgY_ifiJ-mjci7xAAasUTqM_jLVCzL9CwQuRJOe9LO8JbS=Gg@mail.gmail.com> <CAArhhishhjN4TnbXLicEV2fV7O77RY-r1M5Z1M-oJcsMzDOnoA@mail.gmail.com> Message-ID: <CAHgY_ifxZQQSvYfoJ==Ri5ZvG9N7Uu+Xu+yiQFarmmRycaSZ4g@mail.gmail.com> On Fri, Sep 27, 2013 at 12:54 AM, Andrew Wilson <atwilson at google.com> wrote: > So, I'm not entirely sure how many lessons taken from the FirefoxOS > implementation are applicable to the API for web pages in general, but I > agree that "what do we do if the user clicks on a notification after the > parent page has been closed" is a bit of an unsolved/unsolveable problem > with the current API. Hopefully the mobile focus of FirefoxOS points to likely issues for any browser on mobile. For example, I can see where it will be common for mobile browsers to do some sort of web page quiescence, even a full close, maybe just saving a screenshot of the tab, for memory concerns, even if the user still considers the tab "open". I expect the majority of browser use over time will fit into devices that fit the "mobile space" definition vs desktop space definition. > I dimly recall seeing an email thread proposing adding some kind of click > URL to a notification (and my search-fu is not strong enough to find a link > to it, sadly), which seems like it would address some of the issues you have > with the current API (encoding data that can be passed back to the app on a > notification click, even if the app has been closed in the meantime). The > solution I've seen implemented on the web (shutdown notifications when a web > page is closed) clearly doesn't work for a platform like FirefoxOS which > does memory management and app shutdown behind the scenes. An URL could work too (our hack right now is to attach data to the imageURL for the notification and read that data), but I still I prefer using a data object for the data of the notification. The notification object could have an URL associated with it, and the browser would open the URL if it did not already have a tab/process for it, then send a data message to it, but if the URL was already open, just send a data message to it with the notification object. In that approach the URL would not have querystring args, and the browser would match the URL to the URLs of existing opened tabs/apps, but without the query string or fragment ID to find a match. This would allow an already open page to handle multiple notification clicks via an entry point message handler discussed in the first post on this thread. In the cases of memory conscious browsers, it could rehydrate the tab that was currently tracked for that URL, and it would still work without needing to maintain closure state as compared to the notification.onclick/onclose route currently specified. James From cabanier at gmail.com Mon Sep 30 17:42:40 2013 From: cabanier at gmail.com (Rik Cabanier) Date: Mon, 30 Sep 2013 17:42:40 -0700 Subject: [whatwg] Outline style to use for drawSystemFocusRing In-Reply-To: <CAFz-FYxuYUg9ZLWkvORKOPsGjexRtFa9C2WsvN_b4Y-NQ_yE9A@mail.gmail.com> References: <CAFz-FYxS-sLLOMA2=5bj-aJ1bmsBq8w_4Rminw_JLCMnYaMfPw@mail.gmail.com> <alpine.DEB.2.00.1307300020510.27623@ps20323.dreamhostps.com> <CAGN7qDAjRPOQ25gQT+BY+sp8Y503_9KxTa1j2aZSGYU-9BmBVA@mail.gmail.com> <CAFz-FYzzPFU3g+fM+QGbEDAJ-3DSU2qGHY9R+heZRbAWVAN2rw@mail.gmail.com> <CAGN7qDDu3PNxK9PTVr09sqUc0FrOnXgRaQDwLXQ13BhH_=85Bw@mail.gmail.com> <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> <alpine.DEB.2.00.1309120051240.12199@ps20323.dreamhostps.com> <CAFz-FYwi6tQ7WcODc3MBC=6pM_=G5ZONe=nVSHLs5EGTiUjE=w@mail.gmail.com> <CAGN7qDDhuCSSbBtF6gLTUy06sKoNXub3hD6EcUCvKr4ojkzhMA@mail.gmail.com> <CAGN7qDASLvnt8N=CfEKKpB9YYhAtnKkWP5q_KEkLVm9cCL=-2g@mail.gmail.com> <CAFz-FYwBdi9-t1r+2i6X_zaZAuUuLWJtyHngysB70aqhkAnOGQ@mail.gmail.com> <CAGN7qDCHL9g8TsBFpFNQfu3Pjgf-KTRQavzz=QBs_M4H86aL8g@mail.gmail.com> <CAFz-FYyEKYyJYvTMXDJ1f+zmZpxSMpG26xxX37Ne2tDd9tq5Yg@mail.gmail.com> <alpine.DEB.2.00.1309302310570.20189@ps20323.dreamhostps.com> <CAFz-FYxuYUg9ZLWkvORKOPsGjexRtFa9C2WsvN_b4Y-NQ_yE9A@mail.gmail.com> Message-ID: <CAGN7qDBewdTaAZXEDpmtwcwAPziuGQwrjg-UrmHeL4qPuhCoZg@mail.gmail.com> On Mon, Sep 30, 2013 at 4:51 PM, Dominic Mazzoni <dmazzoni at google.com>wrote: > On Mon, Sep 30, 2013 at 4:12 PM, Ian Hickson <ian at hixie.ch> wrote: > >> Some users have great trouble seeing the default focus rings. >> ... >> >> It's certainly true that if we don't want to support users with poor >> vision, the API would be simpler. But I don't think that's an option. We >> don't get to arbitrarily ignore some users. >> > > Of course not! I'm not arguing against supporting those users. The correct > thing to do for those users is to use accessibility APIs to make the > operating system aware of the focused object and its bounds. If users have > ZoomText or MAGic installed, or if they're using VoiceOver or Orca, their > assistive technology will draw its own focus ring *in addition* to the > application's focus ring. > > No other application hides its focus ring just because, e.g., ZoomText is > drawing a focus ring. The rest of the web doesn't do it. Why do we need it > for canvas? > Where does it say in the spec that if you have assistive technology enabled, focus rings should not be drawn? > > On Mon, 30 Sep 2013, Dominic Mazzoni wrote: >> > >> > I don't think that drawCustomFocusRing should switch to the system focus >> > rectangle style just because that preference was set - it might look >> > horrible on a particular canvas. >> >> It's the whole point of the feature. Draw the focus ring the way the user >> needs it to be drawn, if there's a special need, otherwise, let me draw it >> my fancy hard-to-see way. >> > > The problem is that there aren't existing operating system or browser > settings that specifies that the user wants better focus rings. There are > tools that draw additional focus rings, and preferences that control the > appearance of the default focus ring, but no toggle that says > *applications* should or shouldn't draw focus rings. > > Finally, as a meta-argument, if we really want a preference for custom > focus rings, then wouldn't we want that for the rest of the web? If I'm > building a custom form control and I need to choose a drawing style when > focused, wouldn't I want to know if the user wanted custom focus rings, > too? In other words, what makes this need canvas-specific? > > >> How would this differ from scrollPathIntoView() ? > > > It would take an element in fallback content as an argument. That would > allow assistive technology to be notified. > As Ian pointed out, the accessibility software could do that. Actually, I just tried this with my patched version of Firefox and your example: http://dmazzoni-google.github.io/canvas-focus-ring-demo/ If I tab into the hidden canvas elements, the browser automatically scrolls to the region. So, it seems that this is not needed. From dmazzoni at google.com Mon Sep 30 23:48:21 2013 From: dmazzoni at google.com (Dominic Mazzoni) Date: Mon, 30 Sep 2013 23:48:21 -0700 Subject: [whatwg] Outline style to use for drawSystemFocusRing In-Reply-To: <CAGN7qDBewdTaAZXEDpmtwcwAPziuGQwrjg-UrmHeL4qPuhCoZg@mail.gmail.com> References: <CAFz-FYxS-sLLOMA2=5bj-aJ1bmsBq8w_4Rminw_JLCMnYaMfPw@mail.gmail.com> <alpine.DEB.2.00.1307300020510.27623@ps20323.dreamhostps.com> <CAGN7qDAjRPOQ25gQT+BY+sp8Y503_9KxTa1j2aZSGYU-9BmBVA@mail.gmail.com> <CAFz-FYzzPFU3g+fM+QGbEDAJ-3DSU2qGHY9R+heZRbAWVAN2rw@mail.gmail.com> <CAGN7qDDu3PNxK9PTVr09sqUc0FrOnXgRaQDwLXQ13BhH_=85Bw@mail.gmail.com> <alpine.DEB.2.00.1307301529270.27623@ps20323.dreamhostps.com> <CAFz-FYw9=xq+MkdGBMdHiL-x0pboGNFUURh8twB3B8-KZWLC0Q@mail.gmail.com> <alpine.DEB.2.00.1309120051240.12199@ps20323.dreamhostps.com> <CAFz-FYwi6tQ7WcODc3MBC=6pM_=G5ZONe=nVSHLs5EGTiUjE=w@mail.gmail.com> <CAGN7qDDhuCSSbBtF6gLTUy06sKoNXub3hD6EcUCvKr4ojkzhMA@mail.gmail.com> <CAGN7qDASLvnt8N=CfEKKpB9YYhAtnKkWP5q_KEkLVm9cCL=-2g@mail.gmail.com> <CAFz-FYwBdi9-t1r+2i6X_zaZAuUuLWJtyHngysB70aqhkAnOGQ@mail.gmail.com> <CAGN7qDCHL9g8TsBFpFNQfu3Pjgf-KTRQavzz=QBs_M4H86aL8g@mail.gmail.com> <CAFz-FYyEKYyJYvTMXDJ1f+zmZpxSMpG26xxX37Ne2tDd9tq5Yg@mail.gmail.com> <alpine.DEB.2.00.1309302310570.20189@ps20323.dreamhostps.com> <CAFz-FYxuYUg9ZLWkvORKOPsGjexRtFa9C2WsvN_b4Y-NQ_yE9A@mail.gmail.com> <CAGN7qDBewdTaAZXEDpmtwcwAPziuGQwrjg-UrmHeL4qPuhCoZg@mail.gmail.com> Message-ID: <CAFz-FYz57tqWj=mf0dE=1jHi09SXbPKhnHwyC76-XWdPpv6F_g@mail.gmail.com> On Mon, Sep 30, 2013 at 5:42 PM, Rik Cabanier <cabanier at gmail.com> wrote: > Where does it say in the spec that if you have assistive technology > enabled, focus rings should not be drawn? > if as a web author I call drawCustomFocusRing and it returns false, I'm not supposed to draw anything according to the spec. That's what doesn't make sense to me. It would take an element in fallback content as an argument. That would >> allow assistive technology to be notified. >> > > As Ian pointed out, the accessibility software could do that. > scrollPathIntoView can't be used to notify accessibility software of the focused object location as-is because it doesn't have an element to fire on, and it doesn't know if the scrolling is because of focus or not. If we added a canvas fallback element as a parameter to scrollPathIntoView, I don't think we'd need drawCustomFocusRing.

From mnot at mnot.net Sun Sep 1 18:08:48 2013 From: mnot at mnot.net (Mark Nottingham) Date: Mon, 2 Sep 2013 11:08:48 +1000 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: References: <414B89D4-9758-4E38-80C8-7C3630EA4971@mnot.net> Message-ID: On 29/08/2013, at 9:13 PM, Anne van Kesteren wrote: > * Resources that can contain subresources (HTML, CSS, JavaScript, > workers, ...) would need to have an outer and inner location. If you > have e.g. updating the address bar to > #path=test.html&id=test is somewhat magic. For > it'd be pretty magic too. *sigh* good point. > * For origin comparison you'd have to look at the outer location. I kinda wonder if it should; if ZIP is really being used as a packaging format, the idea is to make it portable, right? So a ZIP should run just as well from the local filesystem (file://) as it should from the original Web site, or one it's copied to, or if it's just relocated to a different place. CORS should be set up properly, assumptions shouldn't be made about its context, etc. Just my .02, YMMV. Cheers, -- Mark Nottingham http://www.mnot.net/ From contact at nickshanks.com Mon Sep 2 06:04:34 2013 From: contact at nickshanks.com (Nicholas Shanks) Date: Mon, 2 Sep 2013 14:04:34 +0100 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: References: Message-ID: On 28 August 2013 14:32, Anne van Kesteren wrote: > We have thought of three approaches for zip URL design thus far: > > * Using a sub-scheme (zip) with a zip-path (after !): > zip:http://www.example.org/zip!image.gif > * Introducing a zip-path (after %!): http://www.example.org/zip%!image.gif > * Using media fragments: http://www.example.org/zip#path=image.gif Am I missing something? I assume you want to basically send a whole bunch of files down the pipe when any one of them is requested, not send the individual file's bytestream from a zip. If so, then why is this not acceptable: === Load Game GET http://website.example/game.webzip/load.html Accept: application/webzip, */*;q=0.1 # UA supports looking inside zips 200 OK Content-Type: application/webzip Content-Location: /game.webzip # server knows to send zip -- vs. -- Load Game GET http://website.example/game.webzip/load.html Accept: text/html, */*;q=0.1 # no support 200 OK Content-Type: text/html Content-Location: /game.webzip_files/load.html # server knows file resides elsewhere === HTTP server knows to send a zip file if UA supports a new content type. HTTP server also knows to send back the file from inside the zip (or an unzipped sibling directory to contain the file to serve) to clients that do not support the new mime type. This can be as simple as a mod_rewrite rule executed iff mod_webzip is not loaded. MIME type would only be requested in Accept header by supporting client if the path contained /\.webzip\// otherwise omitted. All relative URIs work as if the file was at the request URI. No multiple scheme hassles, no multiple fragment hassles. No special delimiters that might already be in use. The change in filename also means a concious action on part of the webmaster to allow access. As suggested, the file format can be a stricter form of zip that doesn't allow multiple file tables. The server would have to validate this before sending the file As suggested, the content types of resources in the zip would be determined from a list of file extensions defined by the spec. Anything else get's a default such as application/unknown. -- Nicholas. From jaffathecake at gmail.com Tue Sep 3 03:45:47 2013 From: jaffathecake at gmail.com (Jake Archibald) Date: Tue, 3 Sep 2013 11:45:47 +0100 Subject: [whatwg] Script preloading In-Reply-To: <179BF344-B282-4445-AB2B-5D467D32258D@apple.com> References:

<179BF344-B282-4445-AB2B-5D467D32258D@apple.com> Message-ID: On 31 August 2013 00:04, Ryosuke Niwa wrote: > It'll be much harder to implement a new dependency API that replies on CSS > selectors if we care about the performance at all. > Where does the performance issue come from? It would only need to be resolved once on node creation or insertion into the document (the latter of the two). It's only used for execution, downloads can still be triggered without resolving the selectors (eg, by a pre-scanner). From annevk at annevk.nl Tue Sep 3 05:49:15 2013 From: annevk at annevk.nl (Anne van Kesteren) Date: Tue, 3 Sep 2013 13:49:15 +0100 Subject: [whatwg] Zip archives as first-class citizens In-Reply-To: References: Message-ID: On Mon, Sep 2, 2013 at 2:04 PM, Nicholas Shanks wrote: > Am I missing something? I assume you want to basically send a whole > bunch of files down the pipe when any one of them is requested, not > send the individual file's bytestream from a zip. If so, then why is > this not acceptable: > > === > Load Game > > GET http://website.example/game.webzip/load.html > Accept: application/webzip, */*;q=0.1 # UA supports looking inside zips > > 200 OK > Content-Type: application/webzip > Content-Location: /game.webzip # server knows to send zip > > -- vs. -- > > Load Game > > GET http://website.example/game.webzip/load.html > Accept: text/html, */*;q=0.1 # no support > > 200 OK > Content-Type: text/html > Content-Location: /game.webzip_files/load.html # server knows file > resides elsewhere > === This is a pretty interesting suggestion, but I think the setup is too complicated. Even setting a simple header such as Access-Control-Allow-Origin: * is a problem. -- http://annevankesteren.nl/ From rniwa at apple.com Tue Sep 3 11:27:44 2013 From: rniwa at apple.com (Ryosuke Niwa) Date: Tue, 03 Sep 2013 11:27:44 -0700 Subject: [whatwg] Script preloading In-Reply-To: References:

<179BF344-B282-4445-AB2B-5D467D32258D@apple.com> Message-ID: On Sep 3, 2013, at 3:45 AM, Jake Archibald wrote: > On 31 August 2013 00:04, Ryosuke Niwa wrote: > >> It'll be much harder to implement a new dependency API that replies on CSS >> selectors if we care about the performance at all. >> > > Where does the performance issue come from? It would only need to be > resolved once on node creation or insertion into the document (the latter > of the two). It's only used for execution, downloads can still be triggered > without resolving the selectors (eg, by a pre-scanner). >From the fact selector matching is slow. I'm opposed to adding selector dependency unless there is a very important use case that can't be addressed by referring to a script by an element id or a script filename. - R. Niwa From bzbarsky at MIT.EDU Tue Sep 3 12:42:54 2013 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Tue, 03 Sep 2013 15:42:54 -0400 Subject: [whatwg] Script preloading In-Reply-To: References:

<179BF344-B282-4445-AB2B-5D467D32258D@apple.com>

Message-ID: <52263BBE.60506@mit.edu> On 9/3/13 2:27 PM, Ryosuke Niwa wrote: > From the fact selector matching is slow. Hold on. Back up. Selector matching can't be all that "slow" per se: browsers do it a _lot_. Do you mean doing the equivalent of document.querySelectorAll can be slow? -Boris From ian at hixie.ch Tue Sep 3 13:44:40 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 3 Sep 2013 20:44:40 +0000 (UTC) Subject: [whatwg] Global script clean-up jobs and "spin the event loop" In-Reply-To: References: Message-ID: On Tue, 28 May 2013, Glenn Maynard wrote: > > "Jump to a code entry-point" essentially maintains a stack of entry > scripts, to determine the "outermost" script in order to know whether to > run the global clean-up jobs. This assumes that this algorithm will > always be entered and exited as a stack: an invocation of the algorithm > must always complete after any later invocations. > > Does this hold even in the face of multiple nested invocations of "spin > the event loop" algorithm? That algorithm doesn't seem to try to > guarantee any kind of stack-like behavior. I've fixed this, but I haven't tested to see what browsers actually do in this case. (This can only happen, as far as I can tell, in nested showModalDialog() loops that happen to resume out-of-order. I suspect in reality browsers won't let you do this, which would make this moot?) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 3 13:51:56 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 3 Sep 2013 20:51:56 +0000 (UTC) Subject: [whatwg] registerProtocolHandler - allow site to specify more info and do custom handling In-Reply-To: References:

Message-ID: On Thu, 30 May 2013, chris cargile wrote: > > there seems to be a limitation that either registerProtocolHanlder() > takes GET requests but not POST requests Since you are only ever sent a URL, this seems like the appropriate kind of request, no? On Thu, 30 May 2013, chris cargile wrote: > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=22022. I don't really understand the problem here. Can you elaborate? What problem are you trying to resolve? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 3 13:57:39 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 3 Sep 2013 20:57:39 +0000 (UTC) Subject: [whatwg] inputmode feedback In-Reply-To: References: <511BE988.7070208@lamouri.fr> <5130C9A1.2020200@lamouri.fr> Message-ID: On Thu, 6 Jun 2013, Jonas Sicking wrote: > On Thu, Jun 6, 2013 at 2:08 PM, Ian Hickson wrote: > > On Fri, 15 Feb 2013, Jonas Sicking wrote: > >> > >> Using semantic names might give us the warm fuzzies, but is there > >> really any semantic use we will get out of these that we wouldn't by > >> using "lowercase", "titlecase" or "autocapitalized"? > > > > The reason I used the more "semantic" names is that the names like > > "lowercase", "titlecase" or "autocapitalized" aren't accurate. For > > example, you can hit shift in "lowercase" mode to get uppercase. You > > can have a "titlecase" mode that doesn't capitalise every word (e.g. > > it recognises the "van" in "van Kesteren"). A value that is explicitly > > for names can use a different dictionary than one that is just for > > capitalised text (e.g. derived from the user's contact list). And so > > on. > > > >> I take it verbatim and name would disable any spelling corrections, > >> and name would also titlecase? But the difference between text and > >> prose seems really hard to understand. > > > > In the spec, "verbatim" does not correction at all, e.g. passwords; > > "latin" is for human-to-computer communications, e.g. free-form text > > search fields, and would do spelling correction and automatically > > inserting spaces between words in swiping keyboards, etc; and > > "latin-prose" is intended for human-to-human communications, with > > aggressive automatic typing correction, e.g. text prediction and > > automatic capitalisation at the start of sentences. > > I think a really important question is if this is understandable to > authors. There's also a big risk that if these modes aren't noticeably > different in initial implementations, it will be hard to add such > differences later. I agree that those are concerns. I don't know how to resolve them. I'm certainly open to clearer names. I don't think "titlecase" is a better name, as it either implies that we only capitalise every first letter and forego much of the potential helpfulness that "latin-name" can provide. I don't think "autocapitalized" should imply "autocorrect" in the way that "latin-prose" should. "latin-prose" vs "latin-name" seem straight-forward enough; I agree that "latin" is confusing in that context, though once you explain that "latin" is the basis of "latin-prose" and "latin-name", I think it becomes clear. Other suggestions welcome. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 3 14:09:30 2013 From: ian at hixie.ch (Ian Hickson) Date: Tue, 3 Sep 2013 21:09:30 +0000 (UTC) Subject: [whatwg] @generator-unable-to-provide-required-alt, figure with figcaption In-Reply-To: <0525D1DC-57F5-4F4C-838E-D7D280E9D984@prlbr.com> References: <6D789473-22C6-48B1-BD55-1D375834178A@prlbr.com> <026D354F-5220-4F2B-823F-125249027E52@prlbr.com> <0525D1DC-57F5-4F4C-838E-D7D280E9D984@prlbr.com> Message-ID: On Sat, 8 Jun 2013, Jukka K. Korpela wrote: > 2013-06-08 0:13, Ian Hickson wrote: > > On Sun, 2 Jun 2013, Jukka K. Korpela wrote: > > > > > > The purpose presented is "to avoid markup generators from being > > > pressured into replacing the error of omitting the alt attribute > > > with the even more egregious error of providing phony alternative > > > text". This is rather speculative, and it seems to lead to various > > > attempts that are more or less self-contradictory. > > > > It's not that speculative, your e-mail is a response to a markup > > generator implementor who feels pressured in exactly this way! > > And who wrote that generator-unable-to-provide-required-alt is... > inadequate. Just because the solution is inadequate doesn't mean the problem isn't real. You were saying the problem wasn't real; I was pointing to a counterproof. I would be the first to agree that the spec isn't perfect. > > > Authors of generators always have the option of generating things like > > > alt="(an image)", which can hardly be worse than lack of alt attribute. > > > > It's worse because it prevents authors from being able to find images that > > are lacking good alternative text, and because it makes it less likely > > that future user agents will try to automatically figure out what the > > alternative text should be (since one is already provided). > > To a user, even ?(an image)? is better than lack of alt attribute I disagree. The lack of an alt attribute can be used by user agents to substitute the string "(an image)", in which case it is the same, or it can be used to do far more, e.g. image recognition, OCR, etc. This isn't academic, these technologies exist today. > which is what generator-unable-to-provide-required-alt really means To the non-validator user agent, that attribute means nothing. It's a non-conforming attribute with no semantics to any software outside content generators and conformance checkers. > To analyze which images lack good alternative texts, you need to look at > the images in their context. It?s just wrong to assume that they can be > identified using some simple automated analysis. If you don't write bad alternative text (like "(an image)"), but sometimes write no alternative text at all, then detecting images without good alternative text is the same as detecting images with no alternative text. Certainly, detecting images with present but bad alternative text is a much harder problem -- that's why we should discourage the use of bad alternative text such as "(an image)". > And future user agents won?t try to figure out what the alternative text > should be, any more than current browsers do such things. It is just > wishful thinking to expect such processing, and if browsers tried to do > such things, they would just mess things up. We are far closert to this than I think you realise. Try doing image searches in G+, for exmaple (assuming you have a lot of photographs in your G+ stream). Even with virtually no context, no captions, no incoming links from other pages, and so forth, G+ image search can return accurate results for searches like "house", "tree", "cat", and so forth. It's not at all a stretch to imagine the next stage of this technology is the ability to describe an image. It won't happen tomorrow, maybe not even next year, but HTML is likely to be with us for decades more. On Tue, 18 Jun 2013, Steve Faulkner wrote: > > > > >> > > > > >>

> > > > > > > > > > If you have a caption from the user (as opposed to replacement > > > > > text), then this is a perfectly valid option. It's as valid as > > > > > the